Posts by DecSoft

Hello Samuel,

As I told you via E-Mail, I made several attempts already to allows to save the app layout as we wanted. Unfortunately, I can't get it working. This means I abandond the idea? Not at all. It's just that the time is limited... I am sure that finally get can get something like that working, however, I can't promise you a date, because it's not only a question of time (even when it's important), but, work in the possible implementation.

Said that, your screen do not appear too small, as I can view in the first image. You can see the app's view designer, which is the important, and, additionally, you can see everything (all the dock panels) and ready to be used. Anyway, Samuel, I understand your point and will work in that when possible (I hope at that time I have more lucky than in my previous attempts).

Hello to all,

Here is a new DecSoft App Builder with the below changes, fixes and enhancements:

Read the entire product's history

Hello to all,

Here is a new DecSoft App Builder with the below changes, fixes and enhancements:

Read the entire product's history

Hello John,

Yes; certainly the IFrame control can be interesting. One of the sample app that you can see shown this website in particular, and, as you can see, there is no problem (or not too much problems) with it. The second sample app is maybe more interesting, because show how we can communicate between the IFrame and the website (or HTML file) which is shown in the IFrame, and, this can be interesting if we need something like that. So the IFrame control can be very good, even when probably cannot be considered something like an entire browser embedded in our app.

Hello John,

I think that what you can may use is an IFrame HTML control. Since you can change the IFrame's source / URL, you can create something similar to a browser. Of course, we can find some possible limitations, and, the most important, can be that not all the websites are allowed to be shown inside an IFrame, so, depend on the website that you want to visit, you can enter in troubles that cannot be solved, since do not depend on you nor the IFrame control, but on the website's server itself. There are a couple of IFrame sample apps included with DecSoft App Builder, so, you can take a look at it.

Hello to all,

Here is a new DecSoft App Builder with the below changes, fixes and enhancements:

Read the entire product's history

Hola Jordi,

La clave en este caso está en que si no aplicamos un estilo o damos un tamaño fijo, se aplicará el estilo de AB (escalado o fijo), y, para evitar eso, tenemos que darle un tamaño fijo a un determinado control: de este modo se respetará el tamaño que le demos nosotros mismos, es decir, no se aplicará el estilo de AB, sea este el escalado o el fijo.

Lo dicho aplica tanto a la anterior generación de AB (que es de la que tratamos en este hilo) como a la actual generación del producto.

Hola Jordi,

Tendrás que usar estilos para dar a esos botones un tamaño fijo, utilizando, si es necesario, diferentes tamaños para diferentes pantallas. Esto lo puedes hacer mediante JavaScript pero también mediante CSS, usando la propiedad "Inline CSS" de la app y algunas "CSS media queries". El código que has puesto no está pensado para esto, sino, para que los teclados de dispositivos Android o iOS no deformen las vistas, y, sólo tendrás que usarlo si dichas vistas contienen algún "input", y, si lo ves oportuno.

Hello to all,

Here is a new DecSoft App Builder with the below changes, fixes and enhancements:

Read the entire product's history

Hello John,

I think you have two possibilities, well,... three... if you count to place the function in the Show event, or the app DomReady event. You can also place the function as an app's function, using the app's Functions Manager, then you can use the function's body that you show "as is". And you can also place the function in an external JavaScript file, however, in this case you must use the function's return / result, that is, your code must be something like this:

There is another additionally possibility, John, using some app's internal methods like "app._getCurrentView()", since we have a "window.app" variable that we can use, however, probably the possibilities mentioned above are more recommended. For example, just use the external JavaScript function's return / result can be enough, so we no need to deal with app's internal methods, which maybe can change in the future, etc.

Hello to all,

Here is a new DecSoft App Builder with the below changes, fixes and enhancements:

Read the entire product's history

Hello to all,

Here is a new DecSoft App Builder with the below changes, fixes and enhancements:

Read the entire product's history

Hello John,

Let me to think about. The objective was to maintain the backward compability, so, by default the "Is Content" and "Is background" checkboxes are unchecked, means the script that we add (or we already add in the past) are used by the app context, and not by the Web Extension context.

What do you want to share between the app context and the Web Extension content context and Web Extension background context? Remember that we are talking about different contexts, so, I am not sure if we can really use the same stuff in all contexts.

In fact, I am not sure if we really can do it... let me to explain. Supose you have a script which is used by the app context. That stuff is linked in the app's HTML, in order to be available in the app context, but, this stuff is not available in the Web Extension context, and cannot be available...

At least cannot be available "as is"... supose you place a global variable in the app's script, then you cannot use that global variable in the Web Extension context... because we are talking about the same script, but, the script is not shared between the different contexts, so possible changes in the variable in one context, are not available in other context.

If what you wanted is to use some JavaScript object definition, in order to be available in all the contexts, then, a possible solution right now can be to duplicate the script, that is, you can prepare two "script1.js" and "script2.js", with the same JavaScript object definition, so you can use the app's File Manager and add the two scripts, one for the app context, and the other for the Web Extension content and / or background context.

Remember the ability to share stuff between the app and the Web Extension contexts using messages: this is the way that we must use in order to communicate some possible variables values, etc. Adding the same script in the app and the Web Extension contexts cannot avoid the requirement to use messages in order to communicate the different contexts that we are talking about.

Please, post here if you have any question or want to comment something about, John.

Hello John,

That is absolutely fantastic. Thanks for this new feature.

Glad to know that can be useful to you! ;-)

Hello John,

The problem is that the app Files Manager are only prepared to include scripts to be available in the app context, not in the background nor the content context of a Web Extension. The "WebExtMessage" app's event is running from the app context, so, certainly it's possible to use the script's stuff there. Please, upgrade your AB copy: I prepare the app Files Manager and the File Picker dialog in order to allow to check scripts to be included "as content script" and / or "as background script", so that scripts are copied and linked in the Web Extension manifest file. I hope this can help you.