Maximum number of controls in all open window for an application

Hi everyone,

I would really appreciate if anyone has any answer/suggestion to this question which is partially related to my previous post. I was not able to find any reference to this in Windev help and I don't know how to prevent users from crashing application if they open too many windows with too many controls. It is needles to say how bad it looks to the end user when they have multiple open documents and the application crashes when they try to open one more (usually it is 6 or 7 open windows). I'm not aware of any function in WD which can be used to check if we are close to breaching this kind of control number limit. We are creating 64 bit executables.

Also I was wondering does it have to do something with MDI vs Free window interface. Would it make a difference if we switch to Free windows instead of MDI.

Sorry for asking similar question again but I do not have any idea how to approach this without even knowing what is the actual limit.

Thanks in advance and best regards,
Alex

Hello Alex,

You are correct about the help. This from the help section on "Limits":

Windows opened simultaneously at runtime: Maximum number = Limit may vary according to the available memory and to the number of controls found in each window.

Maximum number of controls per window = Greater than 5,000. This limit can be less depending on the operating system used.

My main app has over 1,300 windows, all modal, and while it has issues with lack of memory filling very large memory tables, I don't think the number of open windows has ever caused an issue. With the windows being modal, they can nest fairly deeply. I can think of one process where there could be 14 windows open most of which would have a minimum of 20 controls.

Counting the open windows is straightforward with a global process called in the window init event and the window close event. I don't actually count the open windows as I have no need but I build and decrement a global string with the names of the open windows.

Regards
Al

Hi Al,

Thank you very much for your answer. I somehow missed this portion of help text although it doesn't help much. My biggest issue is that there is no good mechanism to preempt crashing. I can monitor the number of open windows but there is no way to tell if the next one will cause the memory overflow.

Thanks for your help again.
Alex

Hello Alex.

If it only happens to some users, it's probably a problem with older 32-bit computers and OSes.
And if this is the case with all users, maybe you should try dynamic tabs, or the memory fills up, perhaps, with a large number of queries that are not released by the program after execution, and maybe you have tables that you load into memory (for filtering).
Basically, no one has ever complained to me that they had a problem with the application crashing due to opening a large number of windows.

Regards !

Hi Ismir,

Thank you for your insight on this subject. Based on what I was able to gather the users mostly use Windows 10 machines but as to what configuration it is I have no info. On the other hand I can reproduce the issue on our development machines, for example intel i7 10th gen with 64 Gb of RAM and 1Tb fast SSD running Win 11. Your suggestion about dynamic tabs is something worth exploring as well as queries. We are mostly using handwritten SQL queries with HExecuteSQLQuery and we tend to release memory as soon as we load the grids but still it may cause memory leak if we missed something. I was contemplating about Free windows vs MDI (we currently use) but there is no easy way for me to test it with our current app architecture.

If I find any solution or workaround I will keep the community informed.

Thank you again for your help,
Alex

Hi everyone,

I have an update on this issue which may be interesting to the community. After some investigating I found out that Windows itself imposes a limit to the number of GDI objects for a single process - application. This limit is by default 10000 and can be changed in registry to the maximum value of 18000. I was observing the number of GDI objects for our application within Task Manager -> Details tab and I concluded that it behaves consistently, when you open window the number goes up and when you close it it goes back to the initial value. Changing tabs within the same window affects this number in such way that it increases like if some of the objects are created dynamically, however it doesn't go back when changing back the tab selection. I also came to the conclusion that each and every column of each data grid is treated as a single GDI object even if hidden. So opening of a typical document form in our case increases the number of used GDI objects by ~1500 (it seems that we were too ambitious when we were designing screens). So, opening of 7 such windows and leaving them open leads to inevitable limit breach and exception which causes application crash in MDI parent/child paradigm.

So far I was not able to find any way to dynamically control application so that only those controls which are on visible tabs are instantiated and basically delay the control creation until it gets visible. I observed some other ERP apps, written with Delphi for example, where windows with similar complexity use up far less GDI objects.

If anyone has any suggestion I would like to hear it very much.

Hope this info can be of use to someone.

Regards,
Alex

Hello Alex,

An Idea, use internal windows on tabs. Only load window as needed.

DW

Thanks DW,

This approach may be appropriate for solving the issue. I wonder how much complexity it may add to the window programming and if it would cause any other unexpected issue. I guess I have to try and see.

Best regards,
Alex