Posts by DecSoft

Hello,

No problem! Take also a look at this video Donald:

https://www.youtube.com/watch?v=TDZpVhUIxTo

Probably the video explain a little more the point. :)

Hello Donald,

Yes; basically we can access the Code tab by first select one or more controls. Once a control is selected we can click the Code tab or just press the F12 key to access the control's events code. This is about controls.

Talking about the app we can access their events code by clicking outside the app's view or any other control and then click the Code tab or just press the F12 key.

And finally, talking about the app's views we can access their events code by clicking inside the view (the white part in the designer) and then click the Code tab or just press the F12 key.

Below an image which may can help:

Hello Donald,

Thanks for that but I have lots of questions. Maybe I do not have certain tools showing.

No problem. Probably my poor english didn't allow me to describe the things like I wanted.

I cannot find either of those two pieces of code you show. I see no such thing as a show event. I see nothing called a Load Event.

First of all I commit a mistake here: there is not a "Load" event in the File Input control, but a "Read" event, as you can see below:

About the View's Show event, here is:

The above pieces of code are the only one in the Storage application sample.

The only link I can see between the label and the file input is in the property called Visual Input. What is a Visual and how does it work with the label?

The Label control is associated with the File Input control using the Label's Input property as you see. Basically, a Label can be associated with an Input control using the Label's Input property. Doing this when the Label control is clicked, the associated Input control get the focus.

But the File Input control is something special. When a File Input control are clicked they show us a dialog in order to pick a file. So, if we associated a Label with a File Input control, when the Label is clicked, the file's dialog appear. This means we can hide the Input control (like we do in the sample) in order to use only the Label control instead to pick a file.

The image src value, is that the source image in image properties? I see nothing called src.

When we deal with Image controls, normally, we use their Image property to set an image path or URL. In this scenario we do not use the "src" attribute at all. The "src" attribute exists for the HTML "img" tag and determine the path or URL of an image. But, again, normally we don't use the "src" attribute. Instead of this we simply use the "Image" property.

However, the Storage application sample shown us how to select a file and then store it into the app's local storage. But what we save in the local storage is the "Base64" codification of an image, not a file, not an URL, but the "Base64" codification of the image. So, when we want to show that "Base64" codified image into an Image control, we can't use the "Image" property.

For this reason we use the "src" attribute of the "Image" control with the "SetAttribute" action. What we set in the "src" attribute is the "Base64" codification of the image. And this is the way, because the "src" atribute is capable to store such information ("Base64") and shown the image like we wanted.

Now please, Donald, if you have any other question just post here: I want to help you in everything you wanted.

Hello Donald,

Yes; of course. May this application sample need to be explained a little. In fact they are based in a File Input control. The Label control is associated to such input, then, when the user click the label, it's the same that if the user click the File Input control. This is doing in such way in order to hide the File Input control (you can't view in the application at runtime) and use only the Label control to allow the user to look for image files.

So, when the user click the Label, in fact the File Input click behaviour starts and allow the user to choose an image file. If you take a look at the "Load" event of the File Input control, you can see how we use this event for two things: firstly shown the selected image in the Image control, using the Image's "src" attribute; and secondly store the selected image into the app's local storage:

The sample application has only another piece of code in the view "Show" event:

As you can see, what we doing here is to look into the app's local storage for a previously saved image, and, if found it, set the Image control with that saved image using the Image's "src" attribute.

And this is basically what this sample application shown us: how to use the File input control to choose a file (and how to use a Label control to receive the user click and fire the File input open file dialog) and how we can use the File input's "Load" event to store the selected file into the app's local storage.

If you have any further question jus post here Donald. :)

Hello Donald,

Thanks. Various programs I can remember uses something like that. The App Builder Welcome page is mainly based in the Delphi Welcome page. As you know App Builder is developed with Delphi and I am a Delphi user from years ago, so, I think the Welcome page is useful for App Builder so I add to it.

I am thinking to use this forum for announces, etc., so the topics can appear into the App Builder's Welcome page.

Thanks again! :)

Hello edunt,

Sorry, I say delete your application's compiled directory ("MyApp_Compiled", for example), so you can compile the application from scratch again.

Hello,

Are you sure the About dialog shown your registration data? (Take a look at de Menu - Help - About)

If so, delete your application's compiled directory manually and try it again edunt.

Hello Donald,

I think you mention above something about the Exit action and I do not answer it. So here is:

The Exit action can be used to exit the current script block, without execute any next possible actions.

That's the point! :)

Hello edunt,

The above is the action's editor dialog. Every app's action, app's function and plugin's actions who have one or more arguments have their own editor dialog. The editor dialog appear when we click an action with arguments from the action's dock panel; the editor dialog also appear if we choose an action with arguments from the code editor autocomplete list; and finally the editor dialog appear when double click an action line from the code editor.

Take a look at this video: https://www.youtube.com/watch?v=ZFWh0GBpD8o

Hello,

I think I get it now. Android actually wants it that way. The app is paused and android needs more memory it will close the least important app, usually the one not used for the longest time. Very interesting. There are a few exceptions, GPS is one.

That's the point! Furthermore an application can be killed by the system but their capture continue appearing into the application's list, so the user can change to that application again. Apparently the application is not terminated but we can only view an image capture of the application, so in fact the system can kill it and leave such capture only.

For this reason the "Pause" and "Resume" events exists: we can always save some application state in the "Pause" event (when our application enters in background) and then use the "Resume" event to restore the previously saved state. No matter if the application is killed or not after the "Pause" event.

A possible scenario can be the below one:

1º We start our application, which consists in a form to send information to our server.

2º We start to fill the form with some data, but, at that moment we receive an incomming call.

3º We go into the telephone application, so our application enters in background mode.

At this step we can use the "Pause" event in order to save the already filled form fields.

4º The phone call is not to large, so we just hangup and go back into our application.

At this point, if our application is not killed by the system, the "Resume" event is executed, so we can restore the state of our form in order to never loss the information previously provided by the user.

Now supose this other way in the same scenario:

4º We need to open others applications while we are answering the phone call.

5º The system are low of resouces, so begin to kill old applications to allow the new ones.

6º The phone call ends and we want to go back into our application to continue to fill the form.

At this point, if our application has been killed by the system before, then the "Resume" event is never executed. However, we save something previously in the "Pause" event, so, in any case, even if our application is restarted by the system or their "Resume" event is fired, we can fill our app's form with the previously saved data.

In fact this is what the user expect: they do not expect to fill the form from scratch again, and they don't understand if the applications has been paused, enters in background or killed by the system. They just expect the entered information is not loss and then no need to be provided again.

If we close our application by ourself we broke the above "circle", and, for example, no matter what the system shown in the applications' list: if we close the application, then the system always need to execute it from scratch, which is something more expensive compared to simply "resume" the application.

Hello,

Of course you can. Double click the action line and fill the appropiate action's editor edit box:

Hello,

I can't reproduce the problem. The CSS rule works for me.

Hello,

We can use the object inspector once select the application:

Also we can use the app's options dialog under the Style tab.

Hello Donald,

It's a bit confusing because we are thinking in Windows applications, and Windows applications have exit buttons, or, at least, have a "cross" in the title bar which allow us to close the applications. But the things rules in a different way in mobile operating systems.

Basically we can control the application life cycle using the "Pause" and "Resume" events. For example, if you want that the data dissapear when the applications is put in background, use the "Pause" event to clean the data you wanted.

When our application enters in background because the user just want to use other application, what the operating system does: close the application, maintain it in memory, is something out of our scope and we no need to worry about.

Take a look at this topic in the Phonegap Google Group.