perl-win32-gui-hackers — Hacking and developing the Win32::GUI Perl extension

Re: [perl-win32-gui-hackers] bug in Text()

[Glenn L. <pe...@ne...>]

Thanks, Laurent for the explanation.  I think you got your point across. 
  I was unaware of the implications of your new window destruction.

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.

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.


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 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.
>>
> 
> 
> 
> 
> -------------------------------------------------------
> 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 more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> 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.

Re: [perl-win32-gui-hackers] Main Commit

[Laurent R. <ro...@cl...>]

Hi,

    I commit some change in TreeView made by Glenn W Munroe.

Changelog
    - TreeView.xs :
        + Add more events and new style flag.

Laurent.

Re: [perl-win32-gui-hackers] bug in Text()

[Laurent R. <ro...@cl...>]

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.
>

Re: [perl-win32-gui-hackers] bug in Text()

[Glenn L. <pe...@ne...>]

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.

Re: [perl-win32-gui-hackers] Main Commit

[Glenn L. <pe...@ne...>]

Well, I hope it is released properly.  I accidentally clicked on 
something "sticky" and it confused me a bit.  So samples/BitmapScroll.pl 
may have gotten more rearranged than necessary, but I think it is back 
in order now.  It seems to work, anyway.

On approximately 9/30/2004 6:25 PM, came the following characters from 
the keyboard of Glenn Linderman:

> Hmm.  One could argue that it is purely the responsibility of the user 
> code that calls Win32::Scroll from the -onScroll handler, to adjust the 
> position as appropriate.
> 
> It seems (confirm this if you can Jez) that the "issues" probably only 
> occur for SB_THUMBPOSITION and SB_THUMBTRACK operations, as these are 
> the only that use the position value which is potentially from the 
> WM_HSCROLL or WM_VSCROLL message.
> 
> To allow easier "plumbing", and for the sake of efficiency, I'm adding a 
> special value to the "position" parameter, of -1, which means "use the 
> value from GetScrollInfo  nTrackPos  instead of the passed in value.  So 
>  user code that directly calls Scroll($hv,SB_THUMBPOSITION,$pos) without 
> receiving a message will still work, but user code that says
> 
>   -onScroll => sub { my ( $wh, $sb, $op, $pos ) = @_;
>                      $win->Scroll( $sb, $op, $pos, 1 );
>                      $win->InvalidateRect( 0 );
>                    ),
> 
> need only be recoded as
> 
>   -onScroll => sub { my ( $wh, $sb, $op, $pos ) = @_;
>                      $win->Scroll( $sb, $op, -1, 1 );
>                      $win->InvalidateRect( 0 );
>                    ),
> 
> to cause the -onScroll to use the value retrieved by the internal call 
> to GetScrollInfo that it has to make anyway... thus avoiding doing two 
> calls.  The GetScrollInfo does have to have a different flag setting to 
> retrieve the number.  I haven't tested this with numbers that exceed 16 
> bits, but it seems to not break anything for smaller numbers.
> 
> I guess I've found the "off-by-one" error.... the SCROLLINFO struct is 
> defined to have the "min and max" values for scrolling.  This 
> inconsistency with the graphics ops, which use "min and max+1" for all 
> their bounds, is apparently another idoit-syncracy of the Windows API.
> 
> So I'm updating the sample/BitmapScroll.pl as follows:
> 
> Alter Scroll to be simpler, and use Win32::GUI::Scroll internally, and 
> to return 1, as appropriate for use as an event sub.
> 
> Alter OpenBitmap to use bitmap size-1 for the ScrollRange maximums.
> 
> Alter Paint to pass $win->GetClientRect as the 1st 4 parameters, rather 
> than invoking GetWindowRect twice, and after all, it is the ClientRect 
> we want to fill, not the WindowRect...
> 
> Alter Resize to call AdjScroll, which does more complex adjustments to 
> sizes and positions based on the presence or absence of scrollbars. 
> AdjScroll is also needed to set up the scrollbars in OpenBitmap, to get 
> it done accurately.  The +20 technique works, to a degree, but this is 
> more precise (I've been using this change for quite a while, and it 
> works great... but is probably what made me aware of the off-by-one error).
> 
> I've also extracted a more generic OpenBitmap functionality, because 
> there are other ways one might obtain the bitmap than asking the user... 
> so I've renamed the "user interface" part FindAndOpenBitmap, and the 
> generic code OpenBitmap.  The more generic OpenBitmap also permits 
> substitution of a different bitmap of the same size without altering the 
>  scroll positions, which is a function I find handy.
> 
> I'm about to release all this.... of course it can be rolled back if it 
> is anathema.  But it all seems better, and seems to work for me, both in 
> the sample program, and in my two applications that both use the same 
> technology -- derived from the sample originally (thanks Jez) and then 
> refined -- and now put back into the sample.
> 
> 
> On approximately 9/30/2004 10:11 AM, came the following characters from 
> the keyboard of Glenn Linderman:
> 
>> TADA!
>>
>> As I mentioned to Jez off-list, the WM_HSCROLL and WM_VSCROLL messages 
>> come with parameters that are 16-bit... but the definition of 
>> scrollbars allows 32-bit numbers, if Get/SetScrollInfo APIs are used.  
>> Jez was noticing these issues when scroll ranges got into the 100,000+ 
>> range, he mentioned off-list.
>>
>> So I perused the code for scrolling, and it seems that the incoming 
>> scroll message parameters are preserved and passed to the default 
>> Scroll event, with uses them.
>>
>> There are two possible solutions.  I prefer the 2nd.
>>
>> 1) In all the places where WM_HSCROLL and WM_VSCROLL events are 
>> received (several .xs modules) the message parameter could be replaced 
>> by the real 32-bit value from a GetScrollInfo call, before calling the 
>> Scroll event.
>>
>> 2) In all the places where the Scroll event is processed, it should be 
>> the user responsibility to use Get/SetScrollInfo instead.  For 
>> Win32::GUI, this means that the default Scroll event in GUI.xs should 
>> be updated.
>>
>> The reason I prefer the second is that it preserves the Windows 
>> idoit-syncracies, which are (reasonably well) documented in MSDN; that 
>> it is less GUI code to change, and in a more central place; and that 
>> users should be used to using Get/SetScrollInfo in their own code 
>> anyway, due to MSDN documentation.
>>
>> Comments?
>>
>> I'll start working on a patch to GUI.xs Scroll function.... along the 
>> way, I'm looking for the off-by-one error... gotta be in there 
>> somewhere...
>>
>>
>> On approximately 9/30/2004 8:09 AM, came the following characters from 
>> the keyboard of Jez White:
>>
>>> As a quick reply, I have noticed other 'issues' with scrolling, 
>>> typically when large values are used for the scroll range, I'm not 
>>> sure if it's a win32::gui thing, a windows thing or a bug- it might 
>>> or might not be related to issue you've highlighted.
>>>
>>> Cheers,
>>>
>>> jez.
>>> ----- Original Message ----- From: "Glenn Linderman" <pe...@ne...>
>>> To: "Jez White" <je...@je...>
>>> Cc: "Laurent ROCHER" <ro...@cl...>; 
>>> <per...@li...>
>>> Sent: Thursday, September 30, 2004 3:57 PM
>>> Subject: Re: [perl-win32-gui-hackers] Main Commit
>>>
>>>
>>>> Now you know I'm not really a Windows GUI expert.    I'm going to 
>>>> look now at updating my applications in the same manner as Laurent 
>>>> updated the sample code.
>>>>
>>>> But I've recently noticed something in the sample bitmap scrolling 
>>>> code, which I am gratefully using in a couple of my applications, 
>>>> which is more obvious when displaying Black & White line art that 
>>>> extends to the very edge of the BMP, rather than full-color images, 
>>>> although once you know to look for it, it can be seen with 
>>>> full-color images also.
>>>>
>>>> When scrolling to the complete right/bottom of a bitmap in a smaller 
>>>> window, especially when scrolling via "pages" by clicking on the 
>>>> empty area of the scroll bar, it becomes clear that the 
>>>> right-/bottom-most column/row of pixels in the window does not get 
>>>> redrawn at the very end. It is like there is an off-by-one error 
>>>> somewhere in the code.
>>>>
>>>> Now I notice the scrolling limits are based on Win32::GUI::Width, 
>>>> and that Win32::GUI::Width calculates width as Right-Left.  Now I 
>>>> don't know the Windows spec well enough to know if it should be 
>>>> Right-Left+1 -- in other words, in Right the last drawable pixel, or 
>>>> the first non-drawable pixel? Of course, maybe the off-by-one error 
>>>> is somewhere else instead; this possible source of the off-by-one is 
>>>> just speculation on my part that I haven't yet confirmed or 
>>>> discarded by reading the Windows documentation. But the scrolling 
>>>> bug exists, regardless of where the off-by-one error creeps in.
>>>>
>>>>
>>>> On approximately 9/30/2004 12:01 AM, came the following characters 
>>>> from the keyboard of Jez White:
>>>>
>>>>> Hi,
>>>>>  I've just tested the changes to the -onpaint event and it looks 
>>>>> good:)
>>>>>  Cheers,
>>>>>  jez.
>>>>>
>>>>>     ----- Original Message -----
>>>>>     *From:* Laurent ROCHER <mailto:ro...@cl...>
>>>>>     *To:* per...@li...
>>>>>     <mailto:per...@li...>
>>>>>     *Sent:* Wednesday, September 29, 2004 10:22 PM
>>>>>     *Subject:* [perl-win32-gui-hackers] Main Commit
>>>>>
>>>>>     Hi,
>>>>>      Changelog
>>>>>      - MakeFile.pl, MakeFile_m.pl
>>>>>             + Use tab as space in rule for use with dmake
>>>>>         - GUI.pm, GUI.xs
>>>>>             + Add -brush option for Win32::GUI::Class.
>>>>>         - GUI_Helper.cpp
>>>>>             + classname_From and handle_From : Replace strlen as 
>>>>> static
>>>>>     string length.
>>>>>         - Window.xs, GUI_MessageLoops.cpp, Samples\BitmpaScroll.pl :
>>>>>             + Move Paint event in Window_onEvent.
>>>>>             + Use DoEvent_Paint function like Graphic
>>>>>         - ToolTip.xs :
>>>>>             + Add -balloon option
>>>>>      Laurent.
>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> 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 more
>>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>>> _______________________________________________
>>>> Perl-Win32-GUI-Hackers mailing list
>>>> Per...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers 
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> 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 more
>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>> _______________________________________________
>>> Perl-Win32-GUI-Hackers mailing list
>>> Per...@li...
>>> 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.

Re: [perl-win32-gui-hackers] Main Commit

[Glenn L. <pe...@ne...>]

Hmm.  One could argue that it is purely the responsibility of the user 
code that calls Win32::Scroll from the -onScroll handler, to adjust the 
position as appropriate.

It seems (confirm this if you can Jez) that the "issues" probably only 
occur for SB_THUMBPOSITION and SB_THUMBTRACK operations, as these are 
the only that use the position value which is potentially from the 
WM_HSCROLL or WM_VSCROLL message.

To allow easier "plumbing", and for the sake of efficiency, I'm adding a 
special value to the "position" parameter, of -1, which means "use the 
value from GetScrollInfo  nTrackPos  instead of the passed in value.  So 
  user code that directly calls Scroll($hv,SB_THUMBPOSITION,$pos) 
without receiving a message will still work, but user code that says

   -onScroll => sub { my ( $wh, $sb, $op, $pos ) = @_;
                      $win->Scroll( $sb, $op, $pos, 1 );
                      $win->InvalidateRect( 0 );
                    ),

need only be recoded as

   -onScroll => sub { my ( $wh, $sb, $op, $pos ) = @_;
                      $win->Scroll( $sb, $op, -1, 1 );
                      $win->InvalidateRect( 0 );
                    ),

to cause the -onScroll to use the value retrieved by the internal call 
to GetScrollInfo that it has to make anyway... thus avoiding doing two 
calls.  The GetScrollInfo does have to have a different flag setting to 
retrieve the number.  I haven't tested this with numbers that exceed 16 
bits, but it seems to not break anything for smaller numbers.

I guess I've found the "off-by-one" error.... the SCROLLINFO struct is 
defined to have the "min and max" values for scrolling.  This 
inconsistency with the graphics ops, which use "min and max+1" for all 
their bounds, is apparently another idoit-syncracy of the Windows API.

So I'm updating the sample/BitmapScroll.pl as follows:

Alter Scroll to be simpler, and use Win32::GUI::Scroll internally, and 
to return 1, as appropriate for use as an event sub.

Alter OpenBitmap to use bitmap size-1 for the ScrollRange maximums.

Alter Paint to pass $win->GetClientRect as the 1st 4 parameters, rather 
than invoking GetWindowRect twice, and after all, it is the ClientRect 
we want to fill, not the WindowRect...

Alter Resize to call AdjScroll, which does more complex adjustments to 
sizes and positions based on the presence or absence of scrollbars. 
AdjScroll is also needed to set up the scrollbars in OpenBitmap, to get 
it done accurately.  The +20 technique works, to a degree, but this is 
more precise (I've been using this change for quite a while, and it 
works great... but is probably what made me aware of the off-by-one error).

I've also extracted a more generic OpenBitmap functionality, because 
there are other ways one might obtain the bitmap than asking the user... 
so I've renamed the "user interface" part FindAndOpenBitmap, and the 
generic code OpenBitmap.  The more generic OpenBitmap also permits 
substitution of a different bitmap of the same size without altering the 
  scroll positions, which is a function I find handy.

I'm about to release all this.... of course it can be rolled back if it 
is anathema.  But it all seems better, and seems to work for me, both in 
the sample program, and in my two applications that both use the same 
technology -- derived from the sample originally (thanks Jez) and then 
refined -- and now put back into the sample.


On approximately 9/30/2004 10:11 AM, came the following characters from 
the keyboard of Glenn Linderman:

> TADA!
> 
> As I mentioned to Jez off-list, the WM_HSCROLL and WM_VSCROLL messages 
> come with parameters that are 16-bit... but the definition of scrollbars 
> allows 32-bit numbers, if Get/SetScrollInfo APIs are used.  Jez was 
> noticing these issues when scroll ranges got into the 100,000+ range, he 
> mentioned off-list.
> 
> So I perused the code for scrolling, and it seems that the incoming 
> scroll message parameters are preserved and passed to the default Scroll 
> event, with uses them.
> 
> There are two possible solutions.  I prefer the 2nd.
> 
> 1) In all the places where WM_HSCROLL and WM_VSCROLL events are received 
> (several .xs modules) the message parameter could be replaced by the 
> real 32-bit value from a GetScrollInfo call, before calling the Scroll 
> event.
> 
> 2) In all the places where the Scroll event is processed, it should be 
> the user responsibility to use Get/SetScrollInfo instead.  For 
> Win32::GUI, this means that the default Scroll event in GUI.xs should be 
> updated.
> 
> The reason I prefer the second is that it preserves the Windows 
> idoit-syncracies, which are (reasonably well) documented in MSDN; that 
> it is less GUI code to change, and in a more central place; and that 
> users should be used to using Get/SetScrollInfo in their own code 
> anyway, due to MSDN documentation.
> 
> Comments?
> 
> I'll start working on a patch to GUI.xs Scroll function.... along the 
> way, I'm looking for the off-by-one error... gotta be in there somewhere...
> 
> 
> On approximately 9/30/2004 8:09 AM, came the following characters from 
> the keyboard of Jez White:
> 
>> As a quick reply, I have noticed other 'issues' with scrolling, 
>> typically when large values are used for the scroll range, I'm not 
>> sure if it's a win32::gui thing, a windows thing or a bug- it might or 
>> might not be related to issue you've highlighted.
>>
>> Cheers,
>>
>> jez.
>> ----- Original Message ----- From: "Glenn Linderman" <pe...@ne...>
>> To: "Jez White" <je...@je...>
>> Cc: "Laurent ROCHER" <ro...@cl...>; 
>> <per...@li...>
>> Sent: Thursday, September 30, 2004 3:57 PM
>> Subject: Re: [perl-win32-gui-hackers] Main Commit
>>
>>
>>> Now you know I'm not really a Windows GUI expert.    I'm going to 
>>> look now at updating my applications in the same manner as Laurent 
>>> updated the sample code.
>>>
>>> But I've recently noticed something in the sample bitmap scrolling 
>>> code, which I am gratefully using in a couple of my applications, 
>>> which is more obvious when displaying Black & White line art that 
>>> extends to the very edge of the BMP, rather than full-color images, 
>>> although once you know to look for it, it can be seen with full-color 
>>> images also.
>>>
>>> When scrolling to the complete right/bottom of a bitmap in a smaller 
>>> window, especially when scrolling via "pages" by clicking on the 
>>> empty area of the scroll bar, it becomes clear that the 
>>> right-/bottom-most column/row of pixels in the window does not get 
>>> redrawn at the very end. It is like there is an off-by-one error 
>>> somewhere in the code.
>>>
>>> Now I notice the scrolling limits are based on Win32::GUI::Width, and 
>>> that Win32::GUI::Width calculates width as Right-Left.  Now I don't 
>>> know the Windows spec well enough to know if it should be 
>>> Right-Left+1 -- in other words, in Right the last drawable pixel, or 
>>> the first non-drawable pixel? Of course, maybe the off-by-one error 
>>> is somewhere else instead; this possible source of the off-by-one is 
>>> just speculation on my part that I haven't yet confirmed or discarded 
>>> by reading the Windows documentation. But the scrolling bug exists, 
>>> regardless of where the off-by-one error creeps in.
>>>
>>>
>>> On approximately 9/30/2004 12:01 AM, came the following characters 
>>> from the keyboard of Jez White:
>>>
>>>> Hi,
>>>>  I've just tested the changes to the -onpaint event and it looks good:)
>>>>  Cheers,
>>>>  jez.
>>>>
>>>>     ----- Original Message -----
>>>>     *From:* Laurent ROCHER <mailto:ro...@cl...>
>>>>     *To:* per...@li...
>>>>     <mailto:per...@li...>
>>>>     *Sent:* Wednesday, September 29, 2004 10:22 PM
>>>>     *Subject:* [perl-win32-gui-hackers] Main Commit
>>>>
>>>>     Hi,
>>>>      Changelog
>>>>      - MakeFile.pl, MakeFile_m.pl
>>>>             + Use tab as space in rule for use with dmake
>>>>         - GUI.pm, GUI.xs
>>>>             + Add -brush option for Win32::GUI::Class.
>>>>         - GUI_Helper.cpp
>>>>             + classname_From and handle_From : Replace strlen as static
>>>>     string length.
>>>>         - Window.xs, GUI_MessageLoops.cpp, Samples\BitmpaScroll.pl :
>>>>             + Move Paint event in Window_onEvent.
>>>>             + Use DoEvent_Paint function like Graphic
>>>>         - ToolTip.xs :
>>>>             + Add -balloon option
>>>>      Laurent.
>>>
>>>
>>>
>>> -- 
>>> 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 more
>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>> _______________________________________________
>>> Perl-Win32-GUI-Hackers mailing list
>>> Per...@li...
>>> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers 
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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 
>> more
>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>> _______________________________________________
>> Perl-Win32-GUI-Hackers mailing list
>> Per...@li...
>> 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.

Re: [perl-win32-gui-hackers] Main Commit

[Glenn L. <pe...@ne...>]

TADA!

As I mentioned to Jez off-list, the WM_HSCROLL and WM_VSCROLL messages 
come with parameters that are 16-bit... but the definition of scrollbars 
allows 32-bit numbers, if Get/SetScrollInfo APIs are used.  Jez was 
noticing these issues when scroll ranges got into the 100,000+ range, he 
mentioned off-list.

So I perused the code for scrolling, and it seems that the incoming 
scroll message parameters are preserved and passed to the default Scroll 
event, with uses them.

There are two possible solutions.  I prefer the 2nd.

1) In all the places where WM_HSCROLL and WM_VSCROLL events are received 
(several .xs modules) the message parameter could be replaced by the 
real 32-bit value from a GetScrollInfo call, before calling the Scroll 
event.

2) In all the places where the Scroll event is processed, it should be 
the user responsibility to use Get/SetScrollInfo instead.  For 
Win32::GUI, this means that the default Scroll event in GUI.xs should be 
updated.

The reason I prefer the second is that it preserves the Windows 
idoit-syncracies, which are (reasonably well) documented in MSDN; that 
it is less GUI code to change, and in a more central place; and that 
users should be used to using Get/SetScrollInfo in their own code 
anyway, due to MSDN documentation.

Comments?

I'll start working on a patch to GUI.xs Scroll function.... along the 
way, I'm looking for the off-by-one error... gotta be in there somewhere...


On approximately 9/30/2004 8:09 AM, came the following characters from 
the keyboard of Jez White:

> As a quick reply, I have noticed other 'issues' with scrolling, 
> typically when large values are used for the scroll range, I'm not sure 
> if it's a win32::gui thing, a windows thing or a bug- it might or might 
> not be related to issue you've highlighted.
> 
> Cheers,
> 
> jez.
> ----- Original Message ----- From: "Glenn Linderman" <pe...@ne...>
> To: "Jez White" <je...@je...>
> Cc: "Laurent ROCHER" <ro...@cl...>; 
> <per...@li...>
> Sent: Thursday, September 30, 2004 3:57 PM
> Subject: Re: [perl-win32-gui-hackers] Main Commit
> 
> 
>> Now you know I'm not really a Windows GUI expert.    I'm going to look 
>> now at updating my applications in the same manner as Laurent updated 
>> the sample code.
>>
>> But I've recently noticed something in the sample bitmap scrolling 
>> code, which I am gratefully using in a couple of my applications, 
>> which is more obvious when displaying Black & White line art that 
>> extends to the very edge of the BMP, rather than full-color images, 
>> although once you know to look for it, it can be seen with full-color 
>> images also.
>>
>> When scrolling to the complete right/bottom of a bitmap in a smaller 
>> window, especially when scrolling via "pages" by clicking on the empty 
>> area of the scroll bar, it becomes clear that the right-/bottom-most 
>> column/row of pixels in the window does not get redrawn at the very 
>> end. It is like there is an off-by-one error somewhere in the code.
>>
>> Now I notice the scrolling limits are based on Win32::GUI::Width, and 
>> that Win32::GUI::Width calculates width as Right-Left.  Now I don't 
>> know the Windows spec well enough to know if it should be Right-Left+1 
>> -- in other words, in Right the last drawable pixel, or the first 
>> non-drawable pixel? Of course, maybe the off-by-one error is somewhere 
>> else instead; this possible source of the off-by-one is just 
>> speculation on my part that I haven't yet confirmed or discarded by 
>> reading the Windows documentation. But the scrolling bug exists, 
>> regardless of where the off-by-one error creeps in.
>>
>>
>> On approximately 9/30/2004 12:01 AM, came the following characters 
>> from the keyboard of Jez White:
>>
>>> Hi,
>>>  I've just tested the changes to the -onpaint event and it looks good:)
>>>  Cheers,
>>>  jez.
>>>
>>>     ----- Original Message -----
>>>     *From:* Laurent ROCHER <mailto:ro...@cl...>
>>>     *To:* per...@li...
>>>     <mailto:per...@li...>
>>>     *Sent:* Wednesday, September 29, 2004 10:22 PM
>>>     *Subject:* [perl-win32-gui-hackers] Main Commit
>>>
>>>     Hi,
>>>      Changelog
>>>      - MakeFile.pl, MakeFile_m.pl
>>>             + Use tab as space in rule for use with dmake
>>>         - GUI.pm, GUI.xs
>>>             + Add -brush option for Win32::GUI::Class.
>>>         - GUI_Helper.cpp
>>>             + classname_From and handle_From : Replace strlen as static
>>>     string length.
>>>         - Window.xs, GUI_MessageLoops.cpp, Samples\BitmpaScroll.pl :
>>>             + Move Paint event in Window_onEvent.
>>>             + Use DoEvent_Paint function like Graphic
>>>         - ToolTip.xs :
>>>             + Add -balloon option
>>>      Laurent.
>>
>>
>> -- 
>> 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 
>> more
>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>> _______________________________________________
>> Perl-Win32-GUI-Hackers mailing list
>> Per...@li...
>> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers 
> 
> 
> 
> 
> -------------------------------------------------------
> 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 more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> 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.

Re: [perl-win32-gui-hackers] Main Commit

[Glenn L. <pe...@ne...>]

Well, I've just found some MSDN that declares:

> The coordinates returned by GetClientRect() are not inclusive. For example,
 > to draw a border around the edge of the client area, draw it from the
 > coordinates (Rectangle.left, Rectangle.top) to (Rectangle.right-1,
 > Rectangle.bottom-1).

So it would appear, that whereever the off-by-one error is, it is not in 
sub Win32::GUI::Width.


On approximately 9/30/2004 8:09 AM, came the following characters from 
the keyboard of Jez White:

> As a quick reply, I have noticed other 'issues' with scrolling, 
> typically when large values are used for the scroll range, I'm not sure 
> if it's a win32::gui thing, a windows thing or a bug- it might or might 
> not be related to issue you've highlighted.
> 
> Cheers,
> 
> jez.
> ----- Original Message ----- From: "Glenn Linderman" <pe...@ne...>
> To: "Jez White" <je...@je...>
> Cc: "Laurent ROCHER" <ro...@cl...>; 
> <per...@li...>
> Sent: Thursday, September 30, 2004 3:57 PM
> Subject: Re: [perl-win32-gui-hackers] Main Commit
> 
> 
>> Now you know I'm not really a Windows GUI expert.    I'm going to look 
>> now at updating my applications in the same manner as Laurent updated 
>> the sample code.
>>
>> But I've recently noticed something in the sample bitmap scrolling 
>> code, which I am gratefully using in a couple of my applications, 
>> which is more obvious when displaying Black & White line art that 
>> extends to the very edge of the BMP, rather than full-color images, 
>> although once you know to look for it, it can be seen with full-color 
>> images also.
>>
>> When scrolling to the complete right/bottom of a bitmap in a smaller 
>> window, especially when scrolling via "pages" by clicking on the empty 
>> area of the scroll bar, it becomes clear that the right-/bottom-most 
>> column/row of pixels in the window does not get redrawn at the very 
>> end. It is like there is an off-by-one error somewhere in the code.
>>
>> Now I notice the scrolling limits are based on Win32::GUI::Width, and 
>> that Win32::GUI::Width calculates width as Right-Left.  Now I don't 
>> know the Windows spec well enough to know if it should be Right-Left+1 
>> -- in other words, in Right the last drawable pixel, or the first 
>> non-drawable pixel? Of course, maybe the off-by-one error is somewhere 
>> else instead; this possible source of the off-by-one is just 
>> speculation on my part that I haven't yet confirmed or discarded by 
>> reading the Windows documentation. But the scrolling bug exists, 
>> regardless of where the off-by-one error creeps in.
>>
>>
>> On approximately 9/30/2004 12:01 AM, came the following characters 
>> from the keyboard of Jez White:
>>
>>> Hi,
>>>  I've just tested the changes to the -onpaint event and it looks good:)
>>>  Cheers,
>>>  jez.
>>>
>>>     ----- Original Message -----
>>>     *From:* Laurent ROCHER <mailto:ro...@cl...>
>>>     *To:* per...@li...
>>>     <mailto:per...@li...>
>>>     *Sent:* Wednesday, September 29, 2004 10:22 PM
>>>     *Subject:* [perl-win32-gui-hackers] Main Commit
>>>
>>>     Hi,
>>>      Changelog
>>>      - MakeFile.pl, MakeFile_m.pl
>>>             + Use tab as space in rule for use with dmake
>>>         - GUI.pm, GUI.xs
>>>             + Add -brush option for Win32::GUI::Class.
>>>         - GUI_Helper.cpp
>>>             + classname_From and handle_From : Replace strlen as static
>>>     string length.
>>>         - Window.xs, GUI_MessageLoops.cpp, Samples\BitmpaScroll.pl :
>>>             + Move Paint event in Window_onEvent.
>>>             + Use DoEvent_Paint function like Graphic
>>>         - ToolTip.xs :
>>>             + Add -balloon option
>>>      Laurent.
>>
>>
>> -- 
>> 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 
>> more
>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>> _______________________________________________
>> Perl-Win32-GUI-Hackers mailing list
>> Per...@li...
>> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers 
> 
> 
> 
> 
> -------------------------------------------------------
> 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 more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> 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.

Re: [perl-win32-gui-hackers] Main Commit

[Glenn L. <pe...@ne...>]

Is that with the bitmap scrolling, or other scrolling?  I've used the 
bitmap scrolling with values up to about 4000 vertical and 2400 
horizontal so far, and except for the off-by-one issue I noted, have had 
no problems.  I'm not sure if 4000 qualifies as one of your "large 
values",  nor what the "issues" look like :)

On approximately 9/30/2004 8:09 AM, came the following characters from 
the keyboard of Jez White:
> As a quick reply, I have noticed other 'issues' with scrolling, 
> typically when large values are used for the scroll range, I'm not sure 
> if it's a win32::gui thing, a windows thing or a bug- it might or might 
> not be related to issue you've highlighted.
> 
> Cheers,
> 
> jez.
> ----- Original Message ----- From: "Glenn Linderman" <pe...@ne...>
> To: "Jez White" <je...@je...>
> Cc: "Laurent ROCHER" <ro...@cl...>; 
> <per...@li...>
> Sent: Thursday, September 30, 2004 3:57 PM
> Subject: Re: [perl-win32-gui-hackers] Main Commit
> 
> 
>> Now you know I'm not really a Windows GUI expert.    I'm going to look 
>> now at updating my applications in the same manner as Laurent updated 
>> the sample code.
>>
>> But I've recently noticed something in the sample bitmap scrolling 
>> code, which I am gratefully using in a couple of my applications, 
>> which is more obvious when displaying Black & White line art that 
>> extends to the very edge of the BMP, rather than full-color images, 
>> although once you know to look for it, it can be seen with full-color 
>> images also.
>>
>> When scrolling to the complete right/bottom of a bitmap in a smaller 
>> window, especially when scrolling via "pages" by clicking on the empty 
>> area of the scroll bar, it becomes clear that the right-/bottom-most 
>> column/row of pixels in the window does not get redrawn at the very 
>> end. It is like there is an off-by-one error somewhere in the code.
>>
>> Now I notice the scrolling limits are based on Win32::GUI::Width, and 
>> that Win32::GUI::Width calculates width as Right-Left.  Now I don't 
>> know the Windows spec well enough to know if it should be Right-Left+1 
>> -- in other words, in Right the last drawable pixel, or the first 
>> non-drawable pixel? Of course, maybe the off-by-one error is somewhere 
>> else instead; this possible source of the off-by-one is just 
>> speculation on my part that I haven't yet confirmed or discarded by 
>> reading the Windows documentation. But the scrolling bug exists, 
>> regardless of where the off-by-one error creeps in.
>>
>>
>> On approximately 9/30/2004 12:01 AM, came the following characters 
>> from the keyboard of Jez White:
>>
>>> Hi,
>>>  I've just tested the changes to the -onpaint event and it looks good:)
>>>  Cheers,
>>>  jez.
>>>
>>>     ----- Original Message -----
>>>     *From:* Laurent ROCHER <mailto:ro...@cl...>
>>>     *To:* per...@li...
>>>     <mailto:per...@li...>
>>>     *Sent:* Wednesday, September 29, 2004 10:22 PM
>>>     *Subject:* [perl-win32-gui-hackers] Main Commit
>>>
>>>     Hi,
>>>      Changelog
>>>      - MakeFile.pl, MakeFile_m.pl
>>>             + Use tab as space in rule for use with dmake
>>>         - GUI.pm, GUI.xs
>>>             + Add -brush option for Win32::GUI::Class.
>>>         - GUI_Helper.cpp
>>>             + classname_From and handle_From : Replace strlen as static
>>>     string length.
>>>         - Window.xs, GUI_MessageLoops.cpp, Samples\BitmpaScroll.pl :
>>>             + Move Paint event in Window_onEvent.
>>>             + Use DoEvent_Paint function like Graphic
>>>         - ToolTip.xs :
>>>             + Add -balloon option
>>>      Laurent.
>>
>>
>> -- 
>> 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 
>> more
>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>> _______________________________________________
>> Perl-Win32-GUI-Hackers mailing list
>> Per...@li...
>> 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.

Re: [perl-win32-gui-hackers] Main Commit

[Jez W. <je...@je...>]

As a quick reply, I have noticed other 'issues' with scrolling, typically 
when large values are used for the scroll range, I'm not sure if it's a 
win32::gui thing, a windows thing or a bug- it might or might not be related 
to issue you've highlighted.

Cheers,

jez.
----- Original Message ----- 
From: "Glenn Linderman" <pe...@ne...>
To: "Jez White" <je...@je...>
Cc: "Laurent ROCHER" <ro...@cl...>; 
<per...@li...>
Sent: Thursday, September 30, 2004 3:57 PM
Subject: Re: [perl-win32-gui-hackers] Main Commit


> Now you know I'm not really a Windows GUI expert.    I'm going to look now 
> at updating my applications in the same manner as Laurent updated the 
> sample code.
>
> But I've recently noticed something in the sample bitmap scrolling code, 
> which I am gratefully using in a couple of my applications, which is more 
> obvious when displaying Black & White line art that extends to the very 
> edge of the BMP, rather than full-color images, although once you know to 
> look for it, it can be seen with full-color images also.
>
> When scrolling to the complete right/bottom of a bitmap in a smaller 
> window, especially when scrolling via "pages" by clicking on the empty 
> area of the scroll bar, it becomes clear that the right-/bottom-most 
> column/row of pixels in the window does not get redrawn at the very end. 
> It is like there is an off-by-one error somewhere in the code.
>
> Now I notice the scrolling limits are based on Win32::GUI::Width, and that 
> Win32::GUI::Width calculates width as Right-Left.  Now I don't know the 
> Windows spec well enough to know if it should be Right-Left+1 -- in other 
> words, in Right the last drawable pixel, or the first non-drawable pixel? 
> Of course, maybe the off-by-one error is somewhere else instead; this 
> possible source of the off-by-one is just speculation on my part that I 
> haven't yet confirmed or discarded by reading the Windows documentation. 
> But the scrolling bug exists, regardless of where the off-by-one error 
> creeps in.
>
>
> On approximately 9/30/2004 12:01 AM, came the following characters from 
> the keyboard of Jez White:
>> Hi,
>>  I've just tested the changes to the -onpaint event and it looks good:)
>>  Cheers,
>>  jez.
>>
>>     ----- Original Message -----
>>     *From:* Laurent ROCHER <mailto:ro...@cl...>
>>     *To:* per...@li...
>>     <mailto:per...@li...>
>>     *Sent:* Wednesday, September 29, 2004 10:22 PM
>>     *Subject:* [perl-win32-gui-hackers] Main Commit
>>
>>     Hi,
>>      Changelog
>>      - MakeFile.pl, MakeFile_m.pl
>>             + Use tab as space in rule for use with dmake
>>         - GUI.pm, GUI.xs
>>             + Add -brush option for Win32::GUI::Class.
>>         - GUI_Helper.cpp
>>             + classname_From and handle_From : Replace strlen as static
>>     string length.
>>         - Window.xs, GUI_MessageLoops.cpp, Samples\BitmpaScroll.pl :
>>             + Move Paint event in Window_onEvent.
>>             + Use DoEvent_Paint function like Graphic
>>         - ToolTip.xs :
>>             + Add -balloon option
>>      Laurent.
>
> -- 
> 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 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers 

Re: [perl-win32-gui-hackers] Main Commit

[Glenn L. <pe...@ne...>]

Now you know I'm not really a Windows GUI expert.    I'm going to look 
now at updating my applications in the same manner as Laurent updated 
the sample code.

But I've recently noticed something in the sample bitmap scrolling code, 
which I am gratefully using in a couple of my applications, which is 
more obvious when displaying Black & White line art that extends to the 
very edge of the BMP, rather than full-color images, although once you 
know to look for it, it can be seen with full-color images also.

When scrolling to the complete right/bottom of a bitmap in a smaller 
window, especially when scrolling via "pages" by clicking on the empty 
area of the scroll bar, it becomes clear that the right-/bottom-most 
column/row of pixels in the window does not get redrawn at the very end. 
  It is like there is an off-by-one error somewhere in the code.

Now I notice the scrolling limits are based on Win32::GUI::Width, and 
that Win32::GUI::Width calculates width as Right-Left.  Now I don't know 
the Windows spec well enough to know if it should be Right-Left+1 -- in 
other words, in Right the last drawable pixel, or the first non-drawable 
pixel?  Of course, maybe the off-by-one error is somewhere else instead; 
this possible source of the off-by-one is just speculation on my part 
that I haven't yet confirmed or discarded by reading the Windows 
documentation.  But the scrolling bug exists, regardless of where the 
off-by-one error creeps in.


On approximately 9/30/2004 12:01 AM, came the following characters from 
the keyboard of Jez White:
> Hi,
>  
> I've just tested the changes to the -onpaint event and it looks good:)
>  
> Cheers,
>  
> jez.
> 
>     ----- Original Message -----
>     *From:* Laurent ROCHER <mailto:ro...@cl...>
>     *To:* per...@li...
>     <mailto:per...@li...>
>     *Sent:* Wednesday, September 29, 2004 10:22 PM
>     *Subject:* [perl-win32-gui-hackers] Main Commit
> 
>     Hi,
>      
>     Changelog
>      
>         - MakeFile.pl, MakeFile_m.pl
>             + Use tab as space in rule for use with dmake
>         - GUI.pm, GUI.xs
>             + Add -brush option for Win32::GUI::Class.
>         - GUI_Helper.cpp
>             + classname_From and handle_From : Replace strlen as static
>     string length.
>         - Window.xs, GUI_MessageLoops.cpp, Samples\BitmpaScroll.pl :
>             + Move Paint event in Window_onEvent.
>             + Use DoEvent_Paint function like Graphic
>         - ToolTip.xs :
>             + Add -balloon option
>      
>     Laurent.

-- 
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.

Re: [perl-win32-gui-hackers] Main Commit

[Jez W. <je...@je...>]

Hi,

I've just tested the changes to the -onpaint event and it looks good:)

Cheers,

jez.
  ----- Original Message -----=20
  From: Laurent ROCHER=20
  To: per...@li...=20
  Sent: Wednesday, September 29, 2004 10:22 PM
  Subject: [perl-win32-gui-hackers] Main Commit


  Hi,

  Changelog

      - MakeFile.pl, MakeFile_m.pl
          + Use tab as space in rule for use with dmake
      - GUI.pm, GUI.xs
          + Add -brush option for Win32::GUI::Class.
      - GUI_Helper.cpp
          + classname_From and handle_From : Replace strlen as static =
string length.
      - Window.xs, GUI_MessageLoops.cpp, Samples\BitmpaScroll.pl :
          + Move Paint event in Window_onEvent.
          + Use DoEvent_Paint function like Graphic
      - ToolTip.xs :
          + Add -balloon option

  Laurent.

[perl-win32-gui-hackers] Main Commit

[Laurent R. <ro...@cl...>]

Hi,

Changelog

    - MakeFile.pl, MakeFile_m.pl
        + Use tab as space in rule for use with dmake
    - GUI.pm, GUI.xs
        + Add -brush option for Win32::GUI::Class.
    - GUI_Helper.cpp
        + classname_From and handle_From : Replace strlen as static =
string length.
    - Window.xs, GUI_MessageLoops.cpp, Samples\BitmpaScroll.pl :
        + Move Paint event in Window_onEvent.
        + Use DoEvent_Paint function like Graphic
    - ToolTip.xs :
        + Add -balloon option

Laurent.

Re: [perl-win32-gui-hackers] Color broken?

[Laurent R. <ro...@cl...>]

Hi,

This an old bug report :o)

  -color for Win32::GUI::Class only handle system color as background brush.
  I add a new option -brush for use a Win32::GUI::BRUSH.

Common -background option take a color, but it's work only for some control
(Label, Edit, Button, ListBox).

Laurent.

> [Everything below relates 0.0.670]
>
> Re: this post over at PerlMonks:
> http://www.perlmonks.org/index.pl?node_id=370447
>
> Is the -color of Win32::GUI::Class broken for anything other than system
> colors?
>
> According to the code, this should work:
> my $clsColor = Win32::GUI::Class->new(
>      -name => "classColor",
>      -color => [23, 12, 32],
>      ) or die("Could not create Class\n");
>
> (it dies)
>
> Also, a color like "#FFCCFF" should work, but doesn't. The -color also
> can't take a Brush object as the docs indicate would be supported (but the
> code doesn't (the SvCOLORREF function)). None of this works for me.
>
> Actually, the -background option of a Window seems to behave the same, but
> it also uses SvCOLORREF.
>
>
> Or is it just me? :)

Re: [perl-win32-gui-hackers] About time for a release?

[Laurent R. <ro...@cl...>]

>
> Laurent, you can also submit the new release to CPAN and proclaim
> yourself the current Win32::GUI maintainer, I don't mind. I, for myself,
> would call the release 0.99_01, but feel free to change it as you see fit.
>

Hi Aldo,

    Happy to read you :o)

    I have a CPAN directory as LROCHER.
    I look at PAUSE but i don't see how to proclaim me currrent maintainer
of Win32::GUI.
    I can change permissions only for my upload.

    It's possible to do that only after i upload a Win32::GUI distrib file ?

Laurent.

Re: [perl-win32-gui-hackers] About time for a release?

[Aldo C. <da...@pe...>]

Glenn Linderman wrote:
> Maybe you know the answer to whether anyone with developer/commit access 
> can make a new release, or if it takes an extra permission?  I'd be 
> willing to learn the process.

I'm monitoring as well, but unfortunately I have 0 (zero) time to do 
anything useful. let me know if you need any special permission on 
SourceForge, I can setup things easily enough.

Laurent, you can also submit the new release to CPAN and proclaim 
yourself the current Win32::GUI maintainer, I don't mind. I, for myself, 
would call the release 0.99_01, but feel free to change it as you see fit.

I will keep an eye on the project and, when time will come, I'll try to 
implement (or explain in detail to someone who can implement :-) the 
ideas that I still have in my drawer.

oh, while I'm here: a big thank you to everybody who's involved in 
keeping this project alive :-)

cheers,
Aldo

[perl-win32-gui-hackers] Fwd: About time for a release?

[Blair S. <bs...@nu...>]

It seems we all agree that a new release should be made available. I believe 
it's important to release the module on CPAN where it get's the most 
exposure. I feel Laurent's idea of a pre 1 release of 0.9 is an idea. I 
believe underscores "_" are used to represent developer releases on CPAN. So 
we could use versions like "0.9_01" if we wish. 

Blair 

 ----------Forwarded message ----------
From: "Blair Sutton" <bs...@nu...>
To: "perl Win32::GUI Users" <per...@li...>,
 "perl Win32::GUI Hackers" <per...@li...>
Subject: About time for a release?
Date: Sat, 18 Sep 2004 15:02:23 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit 

Hi all, 

Just wondering when we might get a new release of Win32::GUI. I notice the 
files on the Sourceforge homepage are v671 and CPAN still has v558 but i've 
been using v681 from CVS quite sucessfully now with Win32::GUI::XMLBuilder 
0.36 with no problems. I would like to make this release (WGX 0.36) public 
to CPAN but the accessibility of Win32::GUI is causing some problems for 
users. 

Any thoughts?
Blair 

Re: [perl-win32-gui-hackers] About time for a release?

[Jez W. <je...@je...>]

> Likely we could test as a developer build, by just making a PPM for 
> people to test with, and then go straight to a 1.0 release.

Good idea - I don't mind testing direct from sources.

Cheers,

jez.

Re: [perl-win32-gui-hackers] About time for a release?

[Glenn L. <pe...@ne...>]

On approximately 9/28/2004 11:29 AM, came the following characters from 
the keyboard of Laurent ROCHER:

> Hi all,
> 
>     Sorry, i read mailling list, but have less time for work on Win32::GUI
> now.
>     But, i can take time for make a new release and publish it on
> sourceforge.

Hi Laurent,  Glad to hear you are still monitoring things here, even if 
you haven't time for working on it.  If we get too far off base, you can 
  warn us anyway!

Maybe you know the answer to whether anyone with developer/commit access 
can make a new release, or if it takes an extra permission?  I'd be 
willing to learn the process.

>     I see two bug report in hacker list :
>       - Color problem
>       - Text problem

I'll work on the Text problem as soon as I can, but if someone has some 
time to look at it, I'm willing to share my code.  I haven't been 
successful to create a small test case from scratch, and I haven't yet 
tried the other direction, of removing code from my application to 
reduce it to a smaller test case.

I don't know what is the Color problem, have to look back in the list, I 
guess, if no one else fixes it, after I get the Text problem fixed (if I 
  even can).

>     It's probably good to correct it before.
> 
>     Now how call next release ?
>     Directly 1.0 or made a 0.9 version as testing version before release
> 1.0.

Likely we could test as a developer build, by just making a PPM for 
people to test with, and then go straight to a 1.0 release.


> Laurent
> 
> 
>>On approximately 9/27/2004 4:02 AM, came the following characters from
>>the keyboard of Glenn W Munroe:
>>
>>
>>>Incidentally, has anybody heard from Laurent recently? Aldo seems to
> 
> have
> 
>>>moved on to bigger and better things, Steve Pick disappeared a few
> 
> months
> 
>>>ago and now Laurent has gone quiet. Of course, nobody has any obligation
>>>here, but it would be tragic to lose the "keys" to the repository.
> 
> Although
> 
>>>a lot of other people have made contributions, those three appeared to
> 
> be
> 
>>>the main "hackers". Do all the SourceForge developers have full access
> 
> to
> 
>>>the project site? There are a number of names on there, but we don't
> 
> hear
> 
>>>much from most of them.
>>
>>I think that Aldo is the only one that can grant write access to the
>>repository.
>>
>>I'm not sure who all has write access to the repository, although I know
>>that Laurent did, and I do.  I think Steve also did.  I surely
>>appreciate all the work that Steve and Laurent have done to improve
>>Win32::GUI, and am sorry they have not participated here recently.
>>
> 
> 
> 
> 
> -------------------------------------------------------
> 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 more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> 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.

Re: [perl-win32-gui-hackers] About time for a release?

[Laurent R. <ro...@cl...>]

Hi all,

    Sorry, i read mailling list, but have less time for work on Win32::GUI
now.
    But, i can take time for make a new release and publish it on
sourceforge.

    I see two bug report in hacker list :
      - Color problem
      - Text problem

    It's probably good to correct it before.

    Now how call next release ?
    Directly 1.0 or made a 0.9 version as testing version before release
1.0.

Laurent

> On approximately 9/27/2004 4:02 AM, came the following characters from
> the keyboard of Glenn W Munroe:
>
> > Incidentally, has anybody heard from Laurent recently? Aldo seems to
have
> > moved on to bigger and better things, Steve Pick disappeared a few
months
> > ago and now Laurent has gone quiet. Of course, nobody has any obligation
> > here, but it would be tragic to lose the "keys" to the repository.
Although
> > a lot of other people have made contributions, those three appeared to
be
> > the main "hackers". Do all the SourceForge developers have full access
to
> > the project site? There are a number of names on there, but we don't
hear
> > much from most of them.
>
> I think that Aldo is the only one that can grant write access to the
> repository.
>
> I'm not sure who all has write access to the repository, although I know
> that Laurent did, and I do.  I think Steve also did.  I surely
> appreciate all the work that Steve and Laurent have done to improve
> Win32::GUI, and am sorry they have not participated here recently.
>

Re: [perl-win32-gui-hackers] Re: [perl-win32-gui-users] About time for a release?

[Glenn L. <pe...@ne...>]

On approximately 9/27/2004 4:02 AM, came the following characters from 
the keyboard of Glenn W Munroe:

> Incidentally, has anybody heard from Laurent recently? Aldo seems to have
> moved on to bigger and better things, Steve Pick disappeared a few months
> ago and now Laurent has gone quiet. Of course, nobody has any obligation
> here, but it would be tragic to lose the "keys" to the repository. Although
> a lot of other people have made contributions, those three appeared to be
> the main "hackers". Do all the SourceForge developers have full access to
> the project site? There are a number of names on there, but we don't hear
> much from most of them.

I think that Aldo is the only one that can grant write access to the 
repository.

I'm not sure who all has write access to the repository, although I know 
that Laurent did, and I do.  I think Steve also did.  I surely 
appreciate all the work that Steve and Laurent have done to improve 
Win32::GUI, and am sorry they have not participated here recently.

-- 
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.

[perl-win32-gui-hackers] Re: [perl-win32-gui-users] About time for a release?

[Glenn L. <pe...@ne...>]

I have one known bug in the development version, but haven't had time 
yet to track it down.

There is some weirdness, probably due to the restructuring of the GUI 
code that has happened, perhaps related to threads.

I have a Perl program that uses simulated fork() that works great with 
versions of Win32::GUI before the code restructuring, but fails with 
subsequent versions.

The symptom is that obtaining Text() from a hidden text field begins 
returning undef instead of the appropriate value.  I'm not sure if the 
problem is in getting or setting the Text() value, but the actual code 
for the Text() function is unchanged between GUI versions... and that is 
as far as I got in my debugging efforts.

In general, I would agree that it would be good to put out a new 
release, and I think that it would be good to call it 1.0.  I haven't 
been pushing for that to happen right now, though, because of this known 
bug.

The problem is definitely in the Win32::GUI code, though, because 
changing versions of Win32::GUI is sufficient to make/break my program. 
  Of course, perhaps there is subtle thing in my code that causes it to 
be exercised that only accidentally worked with old versions of 
Win32::GUI, and I'd be glad to fix it if it could figure out that it was 
something like that.


On approximately 9/27/2004 12:00 AM, came the following characters from 
the keyboard of Jez White:
> Hi,
> 
> I too think there should be a new release. I've been using the latest dev
> version for several months with no problems. For those who don't know this
> version contains many new events and methods as well more/better
> documentation.
> 
> There was talk of bumping the version number up to release 1.0 - something
> to do with the activestate repository?
> 
> Cheers,
> 
> jez.
> 
> 
> ----- Original Message ----- 
> From: "Blair Sutton" <bs...@nu...>
> To: "perl Win32::GUI Users" <per...@li...>;
> "perl Win32::GUI Hackers" <per...@li...>
> Sent: Saturday, September 18, 2004 8:02 PM
> Subject: [perl-win32-gui-users] About time for a release?
> 
> 
> 
>>Hi all,
>>
>>Just wondering when we might get a new release of Win32::GUI. I notice the
>>files on the Sourceforge homepage are v671 and CPAN still has v558 but
> 
> i've
> 
>>been using v681 from CVS quite sucessfully now with Win32::GUI::XMLBuilder
>>0.36 with no problems. I would like to make this release (WGX 0.36) public
>>to CPAN but the accessibility of Win32::GUI is causing some problems for
>>users.
>>
>>Any thoughts?
>>Blair
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>>who ports your project to Linux PPC the best. Sponsored by IBM.
>>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>>_______________________________________________
>>Perl-Win32-GUI-Users mailing list
>>Per...@li...
>>https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> 
> 
> 

-- 
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.

Re: [perl-win32-gui-hackers] Re: [perl-win32-gui-users] About time for a release?

[Jez W. <je...@je...>]

Hi,

I've got write access to the repository so I can commit your changed to
Listview.xs if you want. I don't think I've got the permissions to actually
create a new version though - even if I did, I wouldn't know how too:)

I've got Aldo's email address somewhere, so it may be worth emailing him
direct if you want to be added as a developer?

Cheers,

jez.


----- Original Message ----- 
From: "Glenn W Munroe" <gw...@se...>
To: "'Jez White'" <je...@je...>; "'Blair Sutton'"
<bs...@nu...>; "'perl Win32::GUI Users'"
<per...@li...>; "'perl Win32::GUI Hackers'"
<per...@li...>
Sent: Monday, September 27, 2004 12:02 PM
Subject: RE: [perl-win32-gui-hackers] Re: [perl-win32-gui-users] About time
for a release?


> All,
>
> I also agree. You'll probably have noticed a number of questions recently
on
> the user list where the answer relied on the development code. If anybody
> does get around to building a new release, I have added some code to
> Listview.xs that I would like to get included.
>
> Incidentally, has anybody heard from Laurent recently? Aldo seems to have
> moved on to bigger and better things, Steve Pick disappeared a few months
> ago and now Laurent has gone quiet. Of course, nobody has any obligation
> here, but it would be tragic to lose the "keys" to the repository.
Although
> a lot of other people have made contributions, those three appeared to be
> the main "hackers". Do all the SourceForge developers have full access to
> the project site? There are a number of names on there, but we don't hear
> much from most of them.
>
> Glenn Munroe
>
> -----Original Message-----
> From: per...@li...
> [mailto:per...@li...] On Behalf Of
Jez
> White
> Sent: Monday, 27 September, 2004 04:01
> To: Blair Sutton; perl Win32::GUI Users; perl Win32::GUI Hackers
> Subject: [perl-win32-gui-hackers] Re: [perl-win32-gui-users] About time
for
> a release?
>
> Hi,
>
> I too think there should be a new release. I've been using the latest dev
> version for several months with no problems. For those who don't know this
> version contains many new events and methods as well more/better
> documentation.
>
> There was talk of bumping the version number up to release 1.0 - something
> to do with the activestate repository?
>
> Cheers,
>
> jez.
>
>
> ----- Original Message ----- 
> From: "Blair Sutton" <bs...@nu...>
> To: "perl Win32::GUI Users" <per...@li...>;
> "perl Win32::GUI Hackers" <per...@li...>
> Sent: Saturday, September 18, 2004 8:02 PM
> Subject: [perl-win32-gui-users] About time for a release?
>
>
> > Hi all,
> >
> > Just wondering when we might get a new release of Win32::GUI. I notice
the
> > files on the Sourceforge homepage are v671 and CPAN still has v558 but
> i've
> > been using v681 from CVS quite sucessfully now with
Win32::GUI::XMLBuilder
> > 0.36 with no problems. I would like to make this release (WGX 0.36)
public
> > to CPAN but the accessibility of Win32::GUI is causing some problems for
> > users.
> >
> > Any thoughts?
> > Blair
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> > Project Admins to receive an Apple iPod Mini FREE for your judgement on
> > who ports your project to Linux PPC the best. Sponsored by IBM.
> > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> > _______________________________________________
> > Perl-Win32-GUI-Users mailing list
> > Per...@li...
> > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>
>
>

RE: [perl-win32-gui-hackers] Re: [perl-win32-gui-users] About time for a release?

[Glenn W M. <gw...@se...>]

All,

I also agree. You'll probably have noticed a number of questions recently on
the user list where the answer relied on the development code. If anybody
does get around to building a new release, I have added some code to
Listview.xs that I would like to get included.

Incidentally, has anybody heard from Laurent recently? Aldo seems to have
moved on to bigger and better things, Steve Pick disappeared a few months
ago and now Laurent has gone quiet. Of course, nobody has any obligation
here, but it would be tragic to lose the "keys" to the repository. Although
a lot of other people have made contributions, those three appeared to be
the main "hackers". Do all the SourceForge developers have full access to
the project site? There are a number of names on there, but we don't hear
much from most of them.

Glenn Munroe

-----Original Message-----
From: per...@li...
[mailto:per...@li...] On Behalf Of Jez
White
Sent: Monday, 27 September, 2004 04:01
To: Blair Sutton; perl Win32::GUI Users; perl Win32::GUI Hackers
Subject: [perl-win32-gui-hackers] Re: [perl-win32-gui-users] About time for
a release?

Hi,

I too think there should be a new release. I've been using the latest dev
version for several months with no problems. For those who don't know this
version contains many new events and methods as well more/better
documentation.

There was talk of bumping the version number up to release 1.0 - something
to do with the activestate repository?

Cheers,

jez.


----- Original Message ----- 
From: "Blair Sutton" <bs...@nu...>
To: "perl Win32::GUI Users" <per...@li...>;
"perl Win32::GUI Hackers" <per...@li...>
Sent: Saturday, September 18, 2004 8:02 PM
Subject: [perl-win32-gui-users] About time for a release?


> Hi all,
>
> Just wondering when we might get a new release of Win32::GUI. I notice the
> files on the Sourceforge homepage are v671 and CPAN still has v558 but
i've
> been using v681 from CVS quite sucessfully now with Win32::GUI::XMLBuilder
> 0.36 with no problems. I would like to make this release (WGX 0.36) public
> to CPAN but the accessibility of Win32::GUI is causing some problems for
> users.
>
> Any thoughts?
> Blair
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Perl-Win32-GUI-Hackers mailing list
Per...@li...
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers

[perl-win32-gui-hackers] Re: [perl-win32-gui-users] About time for a release?

[Jez W. <je...@je...>]

Hi,

I too think there should be a new release. I've been using the latest dev
version for several months with no problems. For those who don't know this
version contains many new events and methods as well more/better
documentation.

There was talk of bumping the version number up to release 1.0 - something
to do with the activestate repository?

Cheers,

jez.


----- Original Message ----- 
From: "Blair Sutton" <bs...@nu...>
To: "perl Win32::GUI Users" <per...@li...>;
"perl Win32::GUI Hackers" <per...@li...>
Sent: Saturday, September 18, 2004 8:02 PM
Subject: [perl-win32-gui-users] About time for a release?


> Hi all,
>
> Just wondering when we might get a new release of Win32::GUI. I notice the
> files on the Sourceforge homepage are v671 and CPAN still has v558 but
i've
> been using v681 from CVS quite sucessfully now with Win32::GUI::XMLBuilder
> 0.36 with no problems. I would like to make this release (WGX 0.36) public
> to CPAN but the accessibility of Win32::GUI is causing some problems for
> users.
>
> Any thoughts?
> Blair
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users