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.
