Posts by DecSoft

Hello Donald,

Yes; the "SetAttribute" action allow us to set any arbitrary attribute for a control / HTML element. But probably this action is required only in certain specific scenarios like the Storage sample application. Yes; we can set the text color of an Input control with "SetAttribute" like below:

But we have a shortcut for that by using the "SetStyle" action:

And, we can also play with CSS classes, which is probably a better decision. For example, supose we have a CSS file to be added into our application or just use the app's "Inline CSS" option to prepare this CSS class:

Then we can use the "AddClass" action to set the color of the Input control:

So as you can view we have different options and approach in order to set the text color of a control, if the control have a text and they are allowed to be changed.

The SetAttribute dialog shows 3 inputs but when clicking the second one it does not give a drop down of choices so I am assuming any attribute could be changed if it applies to the object?

Yes; any attribute is any attribute: for example, we can add our own attributes or "data" attributes in order to be checked and retrieved later using the "GetAttribute" action. Anyway may it's a good idea for the second input in such action's editor to have a list with the most used attributes. The next App Builder release must include something like that.

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.