Werner F. Bruhin wrote:
I don't know *why* Windows should have this limitation. As far as I know,
Unix/Linux machines don't have this limit. *Weird*.
Mostly it is because of how Windows was originally designed for a 16-bit processor and associated memory constraints, and that MS didn't start breaking away from those design limitations until the NT family. Essentially 16-bit Windows were built around a bunch of fixed size structures, tables, etc. and there was no way for them to be grown dynamically.
Did a bit more testing/looking around and found the "Resource Meter" tool on Windows 98 (Start/Programs/Accessories/System Tools) when I run this and then start my application I get an warning at some point that more then 90% of resources are used up. At that point the Resource Meter shows GDI of about 50% free, but the System and User usages are down to about 5% (five) free!
IIRC, "GDI resources" is a table of handles for pens, brushes, fonts, bitmaps, etc. The User and System resources are handles for everything else: windows, timers, global memory allocations, etc. Also, IIRC, each of these tables is limited to 64K of RAM in win98.
So, I reinstalled the older version of the app (Python 2.3, wxPython 2.4) and I see more or less the same numbers, but NO PyAssertionError.
After that warning is shown things keep on working, the application starts up and works normally from then onwards.
What about the combobox? Did it get created or not? BTW, You can turn off the raising of PyAssertionErrors by calling
app.SetAssertMode(wx.PYAPP_ASSERT_SUPPRESS)
NOTE that resources get somehow released and go up to around 70% free.
I wonder if one could force this freeing of resources earlier on in the process?
I don't remember how win9x does it, but on NT/2K/XP minimizing the app is one of the triggers that the OS makes a sweep through the blocks that have been allocated and released and finally returns them to the OS pool.
ยทยทยท
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!