Repeatable Win32Lib 'Resource' Problem
- Posted by Al Getz <Xaxo at aol.com> Aug 03, 2003
- 488 views
Hello, Ive mananged to stumble upon a way to get the Win32Lib problem to reoccur. I was testing something else resource related when this happened. Ive taken example5 (two buttons) and changed the position of the window to something like 10,10,200,200 so that when you open several exw's of that example at the same time, the windows pile on top of each other neatly. That's the only change. Here's when the problem occurs: Open at least one instance of Explorer (i'll explain this later) and have it visible in a part of the window (all panes and cb's). Open 20 to 30 of the .exw seeing two buttons in each window. Once all are open, move the windows around by moving them one by one to a different part of the screen, again stacking them one on top of the other (makes later work easier). While doing this, note that NO font has been set for BOLD in either of the two buttons, nor in Explorer. In other words, verify that nothing is wrong with the screen fonts, Explorer fonts, nor in the (possibly 60) buttons created with the exw files. Now begin closing out the exw examples (that are stacked) by clicking on the upper right 'x' and keeping an eye on the font of the buttons. Eventually, one exw example will be closed out and the window underneath it will have what looks like 'bold' font, when it didnt have that before any windows were closed out. After all windows are closed, check the fonts in all the child windows of Explorer to see if any have changed to 'bold'. Also check the screen icons to see if any of their fonts have changed to bold (text like 'Shortcut to...'). In all cases tested so far, there has been at least one button font changed to 'bold' upon closing an example exw window, but usually two or three change. In some cases tested, one window of Explorer changes it's font to bold also (Listview, Combo box, status bar). In cases where it affects a window, that window can be closed and the problem seems to disappear when reopened (for that app). When the problem occurs such that the desktop icons text changes, the only way to correct the problem is to reboot. The GDI resource meter is at 80% or greater at the time this occurs. The only guesses i have so far is that maybe there is something wrong with the way a DC is destroyed, a font is selected into a DC, or a font is destroyed, or the order of destruction is not correct between fonts and DC's, or something else like that. If i remember right, this also occurs if you keep selecting a font into a DC without destroying the old one? I'd have to look at this again though. Also, it's not that the font is really getting it's attrib set to 'bold', what is actually happening is the default system font is being selected into the device contexts somehow, which looks bold. How it gets to device contexts that arent gotten from the exw program i dont know yet. It doesnt seem to be a resource depletion problem because it only happens AFTER a control is destroyed. Of course if you open many more instances of the exw this isnt true however, and strange errors really begin to crop up, like missing icons, an error that reads "the compiler has run out of memory". (I've never seen that error before, but it's probably a resource depletion error and not Win32Lib). At least this is one way to reproduce the problem. Take care for now, Al