> 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:
>> I think "problem" it's linked with change i made in Win32::GUI for
>> automaticly destroy window when it's perl variable reference count be
>> In you samples your main window go out of scope, then it's window be
>> But, because it's a parent windows all it's child windows it's
>> too (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
>> Your perl variable was free but not your hide window. And, your
>> perl 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:)
>>>At 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
>>>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
>>>>>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
>>>>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
>>>>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 us
>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
>> Perl-Win32-GUI-Hackers mailing list
> 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 us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> Perl-Win32-GUI-Hackers mailing list