Thanks, Laurent for the explanation. I think you got your point across. I was unaware of the implications of your new window destruction.
I would put money on that your bug is related to what Laurent suggested, I've been bitten twice by similar things.
So I don't know if there's any "good" solution... in some sense, it would be nice if the destruction of the windows didn't happen until all the references to the windows or subwindows or subelements went away, not just the top one. So maybe that is why they didn't get destroyed before. On the other hand, it is nice to be able to have them destroyed somehow. If the scopes of all the variables for related windows were similar, and generally they should be, then everything would work fine, and things would get destroyed.
Typically, most applications wont notice the 'auto' destruction feature since the life of the windows object (window or control) is related to the life of the Perl SV. When the latter is destroyed, the window object is destroyed too. The "problem" is when the two environments become out of sync, which typically happens when windows destroys objects but Perl doesn't 'know' to destroy the corresponding variable (even if it did know, there is very little that could be done anyway) - I don't think there is a way around this and the problem would occur in any development environment where windows handles are stored.
It's probably worth mentioning that this 'auto' destruction feature is extremely powerful and useful concept. It took me a while to break out of the mould of creating all windows/controls during initialisation. I'm now creating and destroying really complex dynamic windows with no memory leaks. The only minus point is that menu's don't work this way and the 'odd bug' such as you've highlighted.
It would be nice to be able to create dynamic auto destroying menus too:) You could then create menus based upon dynamic contexts, without worrying about memory leaks. I had a look at implementing this, but it is a big job with the whole menu system needing a redesign (beyond my skills!).
Perhaps the only useful thing to do now would be to find where someone suggested the technique that I was using, and point out that it is a bad idea now.The idea was only useful in the first place, if thinking that the window is destroyed, otherwise there is little benefit to it over setting that top window as hidden and disabled. But if destroying that top window, destroys the child windows (per a Windows feature, and Windows linkages), then the technique clearly isn't a good idea.
Yep - I do something similar myself - I just bury the window reference away and forget about it:)
On approximately 10/1/2004 11:12 AM, came the following characters from the keyboard of Laurent ROCHER:Hi, I think "problem" it's linked with change i made in Win32::GUI forautomaticly destroy window when it's perl variable reference count be null.In you samples your main window go out of scope, then it's window be destroyed.But, because it's a parent windows all it's child windows it's destroyedtoo (Windows manage like this). You keep reference of subchild window in your perl variable, but it's linked with a destroyed window and Text do nothing because don't have a valid window handler.Before, perl reference count wasn't linked to windows life so no problemhere.Your perl variable was free but not your hide window. And, your subchildperl variable continue to be linked to a valid windows handle. I don't know if you understand what i mean (it's difficult for me to explain this in english:) LaurentAt long last, some progress on the bug in Text(). As a reminder, this failure occurs with the latest development version of Win32::GUI (0.0.682) but works with one I labeled 0.0.680. I believe the major difference is Laurent's reworking of the GUI models. Which is a big chunk. But other things may also have happened. By stripping the failing program down from 4851 lines to 286 lines, I was finally able to focus on many fewer activities that could possibly be relevent. And one surprised me. I knew for a long time that immediately prior to returning from the function that created a Label object in a window (it also created the window) that the label object returned its initial value via Text(). However, immediately after the return from the function, the label object begins returning a zero length string, instead of its initial value. And from then on, attempts to set/retrieve other Text values for that label also fail, with only a zero length string being returned. So, what is the key difference? Well, the test code, available at http://nevcal.com/temporary/bug.pl , calls a function which does the following meta-steps: 1) Creates a window, storing the handle in a sub scoped my variable, and Hide()s it. 2) Creates another window, using the previous window as its -parent. The intention is to avoid a task bar entry, even when the window is visible and enabled. 3) Creates the label, as a widget in the 2nd window, and Hide()s it. So when the function returns, the first window handle goes out of scope, and should be destroyed. And apparently is. But with the new version of GUI, it takes away the functionality of the label->Text(), as well. With the old version of GUI, the label->Text() continues to function, even though the first window handle goes out of scope. Any clues why there is a difference? Any good reasons that there should be a difference? At this point I have a workaround... keep the first window handle around, in a more global variable, and hide and disable that window to avoid the taskbar entry. But why should I have to? On approximately 6/28/2004 10:04 PM, came the following characters from the keyboard of Glenn Linderman:On approximately 6/26/2004 1:30 PM, came the following characters from the keyboard of Glenn Linderman:It seems like the development version of GUI has a bug. The released versions of ->Text() without a parameter return the current value from the object, without resetting it first. The development version of ->Text() without a parameter seems to reset the object, before returning the value. This eliminates the ability to "read" values. This problem manifested itself to me when attempting to use ->Text() on a Label, I haven't yet investigated to see how many objects might be affected, or looked at the source to see how complex the fix might be... I just happened to use an old program that hadn't been "ported" to the new GUI, with the new GUI, and this symptom cropped up. Using the old GUI "cured" the problem.This is somewhat a false alarm... but not completely. I can't reproduce it in the "obvious" test case, and the source code for the gui.xs Text function, which is the only place Text is defined in either version of GUI, is identical. On the other hand, I do have an application that works fine with the old GUI and fails with the new one... same application, and same Perl. And the symptom is that data returned from Text() is different. So I'm presently quite confused, but I'll be working on figuring it out. This is an application that uses 2 threads, via the Win32 Perl fork emulation. In adding a bunch of print statements, I see that with the older Win32::GUI, both the parent and child report the same HASH(address) for the Label object of concern, whereas the current development version reports different HASH(address) values for the Label object of concern. Yet with the new GUI, the parent starts reporting the different value prior to the child thread being created! One would think that it might be a different sort of scoping or different rules for closures, if I weren't using the same version of Perl, and just switching GUI versions. Sort of makes me wonder if there is something about the compilation of Win32::GUI that affects the scoping of variables defined later, which isn't supposed to happen, of course. But I'm really grasping at straws here. I've tried to make a small test case, but the small test cases so far work identically under the old and new GUI versions.-- Glenn -- http://nevcal.com/ =========================== The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing.------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give usYour Opinions, Get Free ThinkGeek Gift Certificates! Click to find out morehttp://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Perl-Win32-GUI-Hackers mailing list Perl-Win32-GUI-Hackers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers-- Glenn -- http://nevcal.com/ =========================== The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing. ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give usYour Opinions, Get Free ThinkGeek Gift Certificates! Click to find out morehttp://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Perl-Win32-GUI-Hackers mailing list Perl-Win32-GUI-Hackers@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
