I have tried the popup with the noresize, even thou you cannot resize the popup size, you can still force the popup to fullscreen by clicking on the button in the upper right hand corner of the popup window.
I am trying to put a 3 tiered menu in the popup so the user can move it around, possibly to a second monitor. It is based on the size of the menus. Using the window.open, the popup is resizable and can be open fullscreen. Using the noresize option in the HE popups, you cannot resize the popup but you can still force the fullscreen mode by clicking on the button in the upper right hand corner of the screen. I would consider this an oversight of the programmer if I seen this in an application.
I can understand the some of the limitations after compiling the code. One of my frustrations, is the differences in the defaults between the browser and the compiled code, with the example below.
In the browser, the noresize, is off by default and can be changed, if needed. You cannot resize, or toggle with the right hand corner button, with the above example.
After compiled, the noresize is on by default and cannot be changed.
Change the code to a HE popup, with the noresize, you cannot resize the window but it doesn’t disable the button in the upper right hand corrner like the option in #1. I would prefer that the user would not have the option to open a window fullscreen with a only a menu displayed.
If the above cannot be achieved, a couple of possible workarounds, include.
A. Since you cannot use the resizeTo() in a compiled app, possibly use the “Const SW_RESTORE = 9;” from a HE function, when the resize has been detected. I have already included all five options when adding the code for the maximize on startup.
B. Use a div to hold the menu and display on a click or mouseover. The down fall, is it cannot be moved to a second monitor. Since I use frames and iframes, this could be a major problem. Worst case, it could be in the banner page where the testing was done.
My goals, is the user experience and making sure the application looks as professional as possible, both in looks and functionality. Also, after release, provide a link in the User Showcase, to show some of the benefits of the HE compiler to your new potential buyers and more exposure for my application.
Some examples of what is included so far.
The 3 tiered menu is color coded for new, locked and a combination between version updates. It retains it settings from a page refresh and can retain it’s settings between sessions. At some point, after release, I hope to have the capability of the menus automatically being rebuilt between versions to update the above codes for both the existing and new entries.
A session history of the last 10 viewed articles. Cleared between sessions. This is different of the current forward and backward buttons.
A persitent history of the last, upto the last 30 viewed articles. These are saved and evaluated with CRC checking between sessions. Based on corruption and/or changes, some could be ignored on load if changed or altered. Both histories are based around arrays.
More items to come.
I will test the workarounds, above and let you know the results.