Posts by DecSoft

Hello Paolo,

Glad to know that you got it, sir, and, always thank you for your trust. Have a nice weekend too!

Hello Paolo,

Something that give my attention is when you say "I tried to use the iframe but the login does not finalize the access, it reloads the page." Certainly, I try to put this website (decsoftutils.com) in an IFrame control and then try to login it: to my surprise I get the same result that you refers, however, this is related with the debugger browser used in DecSoft App Builder: maybe I can do something about, however, if you try the app in another browser (Firefox, for example) or compile it with Apache Cordova and run the app in Android (for example), you can see that you can login to this website as expected.

The Login sample app is quite simply, and, it's not intended to login to "any website", to say like that: what the sample try to show is how we can certainly connect to a server script (PHP in the sample) providing a login and a password: only if we provide the correct login and password, we get the right server's response, and in other case we never can see the expected response, but a login error. So we can use this kind or similar login to perform login and password protected operations in our app server, but, not to login to a website.

On the other hand, in my knowledge, the only way in which we can send something to the IFrame source content is by using the URL: certainly we can set the IFrame's source property to an URL like: https://www.mydomain.com/?myvar=myvalue, so, certainly we are sending some information to the website which is intended to be show in the IFrame: what the website do with the data that we send is something that is a duty of the website: if that website is of our property, may we can perform a login with the sended data, for example.

About the possible usage of an IFrame to show controls similar than AB, you can take in consideration that AB uses the Boostrap CSS framework, so certainly it's possible to have something inside an IFrame that looks similar than the AB controls, since we use the Bootstrap CSS framework in our IFrame content, for example, a button in AB is a button of the referred framework, so we can use the right framework's CSS classes in order to get a button similar than the buttons which AB provided:

I hope this information can help you in some way. If I am not wrong, probably the scenario that you are looking for is the ability to login in your website using the provided website's login form, and, what you get is the "reload iframe problem": as I say in my first paragraph, this is apparently a problem with the debugger browser used in DecSoft App Builder: once your app be compiled with Apache Cordova, for example, or just run in an external browser, you can login in your website as expected, and, in fact, the user session is not loss if your app is stopped and started again: I try this in Android with this website and works like a charm.

Please, post here if you have any further related questions, Paolo.

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,

No problem! One thing what I try the local storage, so for that my surprise. But the point is that you got it!

Hello John,

Are you sure that there is not the same local storage? I made some tests and apparently we have the same local storage, John! Can you mention here what exactly method are you using to opened in another tab?

Hello John,

Before I suggest you to use the app's MaxWidth and MaxHeight properties to avoid the possible "scale problem" in your app's view opened in a new tab. This can be certainly a possible way, however, there is another one: it's also possible to use the "app.setAppFixedStyle()" method in the app's view Show event, so, we change to the fixed style, avoiding the possible "scale problem". You can try with all of these possible approaches and take the best for your specific case.

Hello John,

Before I leave you as a task how to create a tab from a content script (in case you need that, that is, if you did not want to use a context menu item created in a background script). Here is a way to create a new tab from content scripts. The point is to send a mesage to the background script in order to create the new tab. Look at the below code:

Hello John,

It's a bit frustrating, because this works like a charm in Firefox:

The point is that "chrome.browserAction.openPopup();" only works in what the documentation named "user action", like a context menu item click, for example. However, the above code don't work as expected in Chrome nor Edge, for example... :-(

However, there is also another possible approach. Take a look at the below code:

The above code can certainly show our app's desired view (note that we can avoid the local storage usage, that is, we can directly open the app's main view) as expected, that is, in another tab, and, that code works in Firefox, Chrome and Edge (and probably other modern browsers like Opera, etc.).

To my surprise, I try to place the "chrome.tabs.create" in a content script, for example, attaching a "dblclick" event to the body and try it, but, this don't work as expected: maybe because to use "chrome.tabs.create" we must use an "user action" like a context menu item click. I leave you as a task to try this (and search a bit around), if you don't want to use a context menu item. Maybe it's another way to create / open a new tab...

Another possible collateral issue can be the size of the popup. Suppose we have a WebExtension that at designtime is 300x300: we expect to have this size for the popup, but, when we open it (as above) in a new tab, the new tab size can be (probably it is) greater than 300x300. Here I propose to you a couple of possible solution: establish the app's MaxWidth and MaxHeight properties to 300 and 300, so the app openned in the new tab respect that size, because that's the maximum width and height.

The other possible solution can be to avoid the usage of AB controls, but use an HTML control, in which you can place the inputs (and other stuff) that you need: since these controls are not AB controlled (to say like that), they are not scaled. You must take a look in your own app, however, and see what of these options can be acceptable for your specific app case, John.

Since we can now open the app in a new tab, I am also thinking that maybe another possible approach is to open a window... a new window (with window.open) and then use the window.document.write() to prepare our HTML stuff: why? Because in this new window we don't have the "problem" related with the content pages, that is, this window do not have the styles, for example, of the content pages, so, maybe can be good for your purposes.

However, probably a new window can be a bit more tricky. I mention it because may you want to try it. I mean in order to control, for example, what the user type in the input controls... how to send that information to our app from the new window... maybe we don't share here the local storage, etc. Maybe this approach can be good, for example, if the new window present a form to the user to be submited to some app's server. Anyway, probably use an app's view... show one of our app's views in the new tab (as described above) can be the best... or better than the new window approach, at least if I am not wrong: I expect that, for example, some local storage saved in the app from the new tab, can be also available from the app shown in the popup...

Please, play a bit with the above code / **instructions**. I hope some of them can be useful for your specific app case, John.

Hello John,

I am not sure if we can go ahead with what you wanted... or it's a wrong approach. Please, let me to explain. The first in that I think is to use some lightbox Javascript library, and, certainly I can see someone that may can help: basiclightbox. This vanilla Javascript lightbox library consists on two files, one CSS and one JS, which we can add to our WebExtensions as content script and content style, respectively.

Additionally, we can add another content CSS file for our WebExtension with the below code:

Once we do the above, we can add this below Javascript code in our app's WebExtContent event, or, maybe in another Javascript file which we include as another content script for our WebExtension:

Note the usage of the "window.myEventDelegationFunction": I include this function to avoid the usage of the jQuery library, that is, to avoid to include it as another content script in our WebExtension. If you do all the above, you can see that, when you double click the content pages body, a modal dialog appear, with some input inside, and a button, which show you what you type in the input, and, additionaly, closes the modal dialog. The double click event can be replaced with the message that you receive from the background script, that is, the above is just a sample: in principle you can show the modal dialog when receive the message from the background script.

So, everything appear fine, right? Not completely. The problem can be, for example, to properly set a style for the input(s) and buttons of the dialog. Why? Because we are inside a content page, and, this content page have his own style... and this style can affect (and in fact do it) to our own style. The same can be said for all the Javascript stuff that we include in the content pages. We must carefully look at what Javascript we include, because the same problem: the content page Javascript can enter in conflicts with our own Javascript.

I start by including the jQuery library (to use event delegation, just to attach an event to the modal close dialog button), and, apparently works fine, even in my website, for example, which already uses jQuery. However, I am not sure about this approach... maybe jQuery don't enter in conflicts with my website, but, maybe can enter in conflicts with some other website. So you can play with the above code / stuff, follow my instructions, John, however, I am not sure if this can be the best approach... modify the content pages in this way... can cause some conflicts, difficult to handler in all the possible situations / content pages.

Maybe I go ahead to quickly to thinking in use some kind of modal dialog. Maybe the HTML form / controls can be appended to the content page's body, in order to appear at the top, for example, and, even in this case, probably we can see some unexpected behaviour in terms of the style that we apply to our inputs, because certainly we can't forget that the content pages have their own CSS style, that we can't control at all. Supose a content page have some CSS style which affects to "inputs", then our inputs become affected with that CSS style... and probably can be difficult to avoid that. Maybe by initialize the input CSS rules... (look for the "initial" values of the CSS rules), maybe we can finally get something working, but, I am not sure if after lot of work we can get something working exactly as we expected in all the content pages.

Please, play a bit with the above code / instructions, and, think maybe in another possible approach. For example, if we have the form / controls / inputs inside our WebExtension popup (in the main view or in other view), then the content page's scripts nor styles can affect to that controls, so, if that is possible, maybe is desirable to take an approach like that, instead to try to modify / append the content pages.

Hello John,

If I am not wrong, the background scripts can't show anything to the user, so, maybe what you can do is to send a message from the background script to the content script, and therefore, use something similar than the "right click menu" that we see here in this forum some days ago: I think you already know how to send a message from the background script to the content script: if you need some help in order to prepare the dialog HTML markup I can try to help you.

Hello John,

If you refers to the app's dialogs, it's possible to use some CSS code in the dialog's Show event, however, this can cause some scale problems with the controls inside the dialog: if we use pure HTML markup in the dialog (using an HTML control) then the scale problems don't appears. On the other hand, I am talking to reduce the height of the dialog, Jhon, no more, no less: the dialogs are designed to fit the app's views width and height, better said, we use the Boostrap CSS dialogs "as is", and, what we can do is to use the "Size" property of the dialogs, again, no more, no less.

Maybe you can prepare something different using a thirdparty Javascript / CSS library...

Hello John,

I have no experience with that, however, in the Google Chrome / chrome-extensions-samples at repository at Github, we can see this "simple" sample of context menu. If you pick the raw "sample.js" of the referred sample and copy it in the WebExtBackground app's event (or if you place it as a background script), certainly we can see a context menu of our WebExtension. You must study that "sample.js" code, John, as well the related API documentation.

Hello Amin,

About the minimize: when you use the minimize tool of AB1, the Incline CSS is also minimized, so, you no need to manually do it. About the possible bug, certainly, if we can find a way to reproduce it, then we can try to do something about!

Hello Amin,

This is quite rare... I mean, if I am not wrong, the duplicates CSS issue (which has been fixed in the past) are related with the CSS code generated by AB1, but, not the Inline CSS option! Talking about this Inline CSS option I simply can't reproduce the problem here... at least in the current release of AB1 I can't reproduce the problem... Please, Amin, try to reproduce the problem in a sample app... try to add some CSS code, compile the app, save it, repeat this operations, and, tell me if you can see the duplicates issue...

In fact its quite rare that you see a code like the below in the Inside CSS option:

... why? Because the Inline CSS code is not autogenerated by AB1... it's your CSS code... AB don't touch that CSS code... I just mention it because it's rare (double rare) that that comments appear in the Inline CSS option...

Hello Amin,

Sorry, but, I am not completely sure if can understand the problem, so I have some questions: 1º Are you tried to delete the "_Cache" folder? That solve the problem? 2º Can you describe a bit more the problem, please? 3º Can you prepare a sample app in which I can see the problem reproduced?

I am trying here to modify the Inline CSS option (we are talking of the previous generation of App Builder, not the current one), save the app, close it, reopen it, compile it various times, etc., and can't see nothing rare around...

I am not sure if this issue is related with a more or less "old" AB1 release... I can remember some "duplicates CSS" solved in newer releases... Note this from the product's history file:

But I am not sure if the above is the case... because, if I am not wrong, above I am not talking about the Inline CSS option... I am talking about the generated CSS files by AB, but not specifically (and I cannot remember) related with the Inline CSS option...