Hi,
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 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 destroyed
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 problem
here.
Your perl variable was free but not your hide window. And, your subchild
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:)
Laurent
> 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
> 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.
>
