next »

[Reuben B.]

I recently had a customer who was experiencing a pause every time a certain form opened.  When we looked into the form in question was using a FOLDER WITH 12 PAGES, and these 12 PAGES included 9 TEXTEDIT widgets. 

Looking at the GDC log everytime this window was opened, the AUI tree information for every folder page was sent to the GDC when the window was first rendered.  The question I had was why can't we do something similar to TABLES where only the visible rows data is sent to the GDC, so that when a user clicks on a PAGE tab, only then do we transmit the data from the application server to the front-end for that page.  The answer is that all the pages information is needed to size the FOLDER widget correctly.  If we only sent the data to render the first page, then we would only be able to size the FOLDER widget as big as the first page, if subsequent clicked pages were wider or taller than the first page then the window would need to be resized.

Has anyone come up with a way to alleviate this potential bottleneck.  I can put ON ACTION on each PAGE so that the contents are only calculated when the page is clicked on, but is there a simple technique to avoid sending all the static data for ALL pages when the FOLDER is first rendered?


Reuben

PS When I first looked into this, the profiler didn't indicate that this form opening was slow.  As well as excluding the time spent waiting for the user to input data, the profiler also excludes the time spent by the GDC rendering.

[Leo S.]

Hi Reuben,
we could imagine the following:
if the Folder gets minimumWidth/minimumHeight attributes, then this could be the
 indicator for the VM to not send initially all pages (or another explicit flag).But the GDC needs at least an idea how large the biggest page of the folder is,otherwise clicking on several pages will lead to a resize of the form.
We really see a need of this technique because some customers blow the whole client with "monster forms"..In good ol' 4GL days one could open a sub window in the same current window and hence display the information only when needed.
I believe we need something similar for genero, this could be done in the overhaul of the multiple dialogs in direction master/detail forms (the ability to merge a separate detail .per form into a master form at run time via place holders in the master form, this would also prevent 1 big all in one monster form). However nothing has been decided yet.
Having the flag for the VM to prevent sending all pages including minimumWidth/
minimumHeight seems faster doable but also has not been discussed in detail here.
Kind Regards, Leo

[Reuben B.]

Hi Reuben,
we could imagine the following:
if the Folder gets minimumWidth/minimumHeight attributes, then this could be the
 indicator for the VM to not send initially all pages (or another explicit flag).But the GDC needs at least an idea how large the biggest page of the folder is,otherwise clicking on several pages will lead to a resize of the form.
We really see a need of this technique because some customers blow the whole client with "monster forms"..In good ol' 4GL days one could open a sub window in the same current window and hence display the information only when needed.
I believe we need something similar for genero, this could be done in the overhaul of the multiple dialogs in direction master/detail forms (the ability to merge a separate detail .per form into a master form at run time via place holders in the master form, this would also prevent 1 big all in one monster form). However nothing has been decided yet.
Having the flag for the VM to prevent sending all pages including minimumWidth/
minimumHeight seems faster doable but also has not been discussed in detail here.
Kind Regards, Leo

Leo,

Thanks, I was thinking along the lines of specifying HEIGHT,WIDTH for a FOLDER, and if the page contents exceed specified height, width then the contents of a page are displayed inside scrollbars.  Similar to how a form can be rendered if it is bigger than the screen.  I suppose it depends upon which is the lesser evil, scrollbars inside a folder page versus form resizing.

The other place I have seen for potential performance improvement is if something is hidden.  In that case I would've thought most of the info would not need to be sent to the GDC.  I tried to improve the folder/page performance by hiding the parent VBOX layout container of each page, and unhiding it when the page was selected but still the data of each page was sent to the GDC.

Reuben

[.]

Hi Reuben,
we could imagine the following:
if the Folder gets minimumWidth/minimumHeight attributes, then this could be the
 indicator for the VM to not send initially all pages (or another explicit flag).But the GDC needs at least an idea how large the biggest page of the folder is,otherwise clicking on several pages will lead to a resize of the form.
We really see a need of this technique because some customers blow the whole client with "monster forms"..In good ol' 4GL days one could open a sub window in the same current window and hence display the information only when needed.
I believe we need something similar for genero, this could be done in the overhaul of the multiple dialogs in direction master/detail forms (the ability to merge a separate detail .per form into a master form at run time via place holders in the master form, this would also prevent 1 big all in one monster form). However nothing has been decided yet.
Having the flag for the VM to prevent sending all pages including minimumWidth/
minimumHeight seems faster doable but also has not been discussed in detail here.
Kind Regards, Leo

As someone who has monster forms (to put it mildly) I would love for this option, thus allowing me to break up some very complex forms and improve re-use of elements throughout the system. Unfortunately the nature of our application currently requires these monster forms but I would be glad to see the back of them, and the resising issues that they have.

[Bryce S.]

...
I believe we need something similar for genero, this could be done in the overhaul of the multiple dialogs in direction master/detail forms (the ability to merge a separate detail .per form into a master form at run time via place holders in the master form ....

I just wanted to add I like the idea of place holders and merging forms at run time - will you consider making it work outside of multiple dialogs, like just in standard forms?    (relates back to an earlier thread: https://4js.com/fjs_forum/index.php?topic=62.0  "Is it possible to open a group from one form inside another form?") Opening another modules form within the current form could be handy when combined with a place holder.

Regards,
  Bryce Stenberg.