perl-win32-gui-hackers Mailing List for Win32::GUI

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

> Glenn,
> 
>     I try to merge and apply your patch on 665-Fix branch this week-end.
> 
>     I quick read your patch and i see this :
> 
> ! #ifdef PERLWIN32GUI_GLBREAK
> !     printf("XS(Create): %s\n", perlcs.cs.lpszName );
> !     if ( perlcs.cs.lpszName
> !       &&  strcmp ( perlcs.cs.lpszName, "findlist.pl Main Window" ) == 0 )
> !     { __asm { int 3 };
> !     }
> ! #endif
> 
>     It's a debugger breakpoint !!!!!
>     Some time ago, i search a way to debug a XS code whitout find.   
>     It's very usefull, i test it and it's work great with Visual C++.
>     Thank for this "Tip Of The Day" ;o)
> 
> Laurent.

Yeah, I took out most (not all) of my debugging code of the nature of

#ifdef SOME_SYMBOL_MOST_PEOPLE_WONT_HAVE
    printf( "something or another\n" );
#endif

but when I got to that one, I thought it might be useful for someone 
that hadn't ever seen it done before.  I love debuggers, but they can be 
real contrary to use with dynamically created code, such as Perl and 
other interpreters... in such situations, starting from the top, one 
needs to set a number of breakpoints along the way, after code get 
created and/or loaded, just to find your way in to where you really want 
to set the breakpoint.  It can often be much easier to instrument the 
code you want to debug with the breakpoint in the manner above, but 
unless one understands the assembly language and the debugger itself to 
some extent, it can be difficult to figure that out!

Yes, it does work well with Visual C; some other debuggers, since they 
did not place the breakpoint there, may get somewhat confused about 
discovering one there... for those debuggers, often the way they express 
their confusion is to attempt to "reexecute" the "int 3" instruction. 
To sidestep their confusion, use the debugger commands to increment the 
instruction pointer  ( reg IP = IP + 1 )  although the syntax varies 
between debuggers, and sometimes might be click here or there and type 
the new number (it would be in Visual C, if Visual C didn't handle it 
reasonably).

-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.

Glenn,

    I try to merge and apply your patch on 665-Fix branch this week-end.

    I quick read your patch and i see this :

! #ifdef PERLWIN32GUI_GLBREAK
!     printf("XS(Create): %s\n", perlcs.cs.lpszName );
!     if ( perlcs.cs.lpszName
!       &&  strcmp ( perlcs.cs.lpszName, "findlist.pl Main Window" ) == 0 )
!     { __asm { int 3 };
!     }
! #endif

    It's a debugger breakpoint !!!!!
    Some time ago, i search a way to debug a XS code whitout find.   
    It's very usefull, i test it and it's work great with Visual C++.
    Thank for this "Tip Of The Day" ;o)

Laurent.


> 
> Due to my hard drive being in the process of failing, I thought I'd 
> better get this patch isolated and delivered to you, so that it won't 
> get lost.  Plus maybe Glenn Munroe might be able to use it, and others.
> 
> Here is a description of all the changes I've made, which you can use as 
> needed as comments in the change log(s).  The patch.txt was generated by 
> diff -r -c against the released version of 0.0.665 sources, not 
> including any patches you've already applied to the CVS bugfix branch. 
> I hope that works for you... if it is hard, let me know what I should 
> provide instead.
 ...
> -- 
> Glenn

Hi Laurent,

Due to my hard drive being in the process of failing, I thought I'd 
better get this patch isolated and delivered to you, so that it won't 
get lost.  Plus maybe Glenn Munroe might be able to use it, and others.

Here is a description of all the changes I've made, which you can use as 
needed as comments in the change log(s).  The patch.txt was generated by 
diff -r -c against the released version of 0.0.665 sources, not 
including any patches you've already applied to the CVS bugfix branch. 
I hope that works for you... if it is hard, let me know what I should 
provide instead.


I included a patch the change the version from 0.0.665 to 0.0.680 ... I 
really don't care what the final number is, but probably it shouldn't be 
0.0.665 ... we should use a different number, changing it for each patch 
applied, perhaps.  And maybe Aldo could bump the first or second number 
in the main branch, for anything he does there?


There is a fix for an uninitialized variable reference, maybe you've 
already picked that up, this is in the tooltip handling code.

There is a fix to add additional Windows constants for use with 
TrackPopupMenu, these are TPM_* constants.

There is a fix to add many additional possible accelerator keys.  I 
tried to include all the ones that sounded like they were not guaranteed 
to vary on other keyboards, and tried to consolidate documentation for 
all keys I could find documentation for into the code, even if some of 
them are commented out, so if someone needs one I commented out, it 
should be easy to add it in.

There is a fix to NotifyIcon destruction, to avoid warnings when the 
destruction by shutting down the process might conflict with destruction 
by hand.  Not clear which one happens first, all the time.

There are fixes to the bugs that prevented accelerator keys from working.

I left in some commented out code that shows how to trigger the MS 
Visual Studio debugger in a somewhat clean way, in case that code might 
be useful to someone, either where it is, or to paste it somewhere else.

In GUI_MessageLoops, most of the changes are to move calls to the 
DefWindowProc to a common spot, so that when you add debugging code, you 
can monitor all the calls to DefWindowProc from one spot in the code, 
rather than scattering the debugging code into over a dozen other 
places.  This also unifies the "STRONGDEBUG" code that already 
preceeding most, but not all, of the former calls to DefWindowProc. 
This is in the nature of code cleanup, and making things easier to 
debug, but don't actually change the functionality of Win32::GUI.


-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.

onKeyDown is utterly useless for a textfield without changing this in
Textfield.xs:

Line 746 case should change to:

 case WM_KEYDOWN:
  PerlResult = DoEvent_NEM(NOTXSCALL perlud, PERLWIN32GUI_NEM_KEYDOWN,
"KeyDown",
  PERLWIN32GUI_ARGTYPE_LONG, lParam,
  PERLWIN32GUI_ARGTYPE_LONG, wParam,
  -1);
        break;

This way, we get the key-code (wParam) and a load of other info in lParam
documented here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/keyboardinput/keyboardinputreference/keyboardinputmessages/wm_keydown.asp
as arguments to the handler.

Steve

hello gentlemen,
I'm currently reviewing my codebase and gradually applying all the
patches and fixes which don't depend on the NEM. GUI.pm is updated on
CVS. I've used the CVS log itself to document the changes, but I will
probably touch Changelog too sooner or later.

please note that I've also added a CVS-id line: such line should
be added to any file in the distribution, so whatever you commit next
make sure you add that line :-)

PS. Laurent, Johan, Glenn, and the others: I'm very, very happy to be
working together with a bunch of cool people like you. thank you very much!

cheers,
Aldo

__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;

At 15:15 2003-11-22, Steve Pick wrote:
>Drag & Drop support for files is already included in Win32::GUI::AdHoc and
>has been for some time.

The DnD-stuff has two components: one Perl component and one XS component 
to provide the needed event.

The XS stuff isn't in the Win32::GUI core. For TGL I compiled my own 0.0.558.

Win32::GUI::AdHoc is a work-in-progress module I created to put stuff that 
didn't fit anywhere else. It's not part of any official Win32::GUI release, 
so the DnD things should be moved from that module into the Win32::GUI core 
IMHO.


/J

-------- ------ ---- --- -- --  --  -    -     -      -         -
Johan Lindström    Sourcerer @ Boss Casinos     jo...@ba...

Latest bookmark: "Oracle Pipeline - Quest Software's Information..."
http://www.quest-pipelines.com/pipelines/dba/index.asp
dmoz: /Computers/Programming/Languages/PL-SQL/ 78

    I made a test by adding those 2 lines in loginfo file with my
sourceforge mail adress.
    It's work great.

    Aldo, can you create a specific mailling list for this.
    I read in Sourceforge documentation, if we call 'cvs' or 'commit' no
mail archive is done.

Laurent.


> Yes, the send of CVS commits to a mailing list would be useful for
> keeping developers synchronized.  I would subscribe.
>
> > In some other SourceForge project, i see a special mailing-list with all
cvs
> > commit change.
> >
> > I'm looking in Sourceforge documentation, and i found this :
> >
http://sourceforge.net/docman/display_doc.php?docid=772&group_id=1#mailsend
> >
> > It's possible to send all CVS commit to a mail adresse.
> >
> > It's two line to add CVSROOT/loginfo file :
> > CVSROOT /cvsroot/sitedocs/CVSROOT/cvstools/syncmail %{sVv}
> > use...@us...
> > DEFAULT /cvsroot/sitedocs/CVSROOT/cvstools/syncmail %{sVv}
> > pro...@li...
> >
> > It's probably better to have a specific CVS mailing list for that rather
> > Hackers mailling list.
> >

Commit in CVS (665-Fix).

Laurent.


> BOOL
> PeekMessage(handle, min=0, max=0, message=&PL_sv_undef)
>     HWND handle
>     UINT min
>     UINT max
>     SV* message
> PREINIT:
>     MSG msg;
> CODE:
>     ZeroMemory(&msg, sizeof(msg));
>     RETVAL = PeekMessage(&msg, handle, min, max, PM_NOREMOVE);
>     if(message != &PL_sv_undef) {
>         if(SvROK(message) && SvTYPE(SvRV(message)) == SVt_PVAV) {
>             av_clear((AV*) SvRV(message));
>             av_push((AV*) SvRV(message), newSViv((long) msg.hwnd));
>             av_push((AV*) SvRV(message), newSViv(msg.message));
>             av_push((AV*) SvRV(message), newSViv(msg.wParam));
>             av_push((AV*) SvRV(message), newSViv(msg.lParam));
>             av_push((AV*) SvRV(message), newSViv(msg.time));
>             av_push((AV*) SvRV(message), newSViv(msg.pt.x));
>             av_push((AV*) SvRV(message), newSViv(msg.pt.y));
>         } else {
>             if(PL_dowarn) warn("Win32::GUI: fourth parameter to
PeekMessage is not an array reference");
>         }
>     }
> OUTPUT:
>     RETVAL
>

    I have move changelog lines from ReadMe.txt to a specific CHANGELOG
file.
    Now, when commit something, we need to add a line in this file.

Laurent.

>
> changelog would be nice, just for a record of what's been done.
>

Yes, the send of CVS commits to a mailing list would be useful for 
keeping developers synchronized.  I would subscribe.

On approximately 11/22/2003 8:36 AM, came the following characters from
the keyboard of Laurent ROCHER:
> Hi,
> 
> In some other SourceForge project, i see a special mailing-list with all cvs
> commit change.
> 
> I'm looking in Sourceforge documentation, and i found this :
> http://sourceforge.net/docman/display_doc.php?docid=772&group_id=1#mailsend
> 
> It's possible to send all CVS commit to a mail adresse.
> 
> It's two line to add CVSROOT/loginfo file :
> CVSROOT /cvsroot/sitedocs/CVSROOT/cvstools/syncmail %{sVv}
> use...@us...
> DEFAULT /cvsroot/sitedocs/CVSROOT/cvstools/syncmail %{sVv}
> pro...@li...
> 
> It's probably better to have a specific CVS mailing list for that rather
> Hackers mailling list.
> 
> What do you think of this ?
> 
> Laurent.
> 
> 
> 
>>Hi,
>>
>>changelog would be nice, just for a record of what's been done.
>>
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
> 
> 

-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.

Hi,

In some other SourceForge project, i see a special mailing-list with all cvs
commit change.

I'm looking in Sourceforge documentation, and i found this :
http://sourceforge.net/docman/display_doc.php?docid=772&group_id=1#mailsend

It's possible to send all CVS commit to a mail adresse.

It's two line to add CVSROOT/loginfo file :
CVSROOT /cvsroot/sitedocs/CVSROOT/cvstools/syncmail %{sVv}
use...@us...
DEFAULT /cvsroot/sitedocs/CVSROOT/cvstools/syncmail %{sVv}
pro...@li...

It's probably better to have a specific CVS mailing list for that rather
Hackers mailling list.

What do you think of this ?

Laurent.


> Hi,
>
> changelog would be nice, just for a record of what's been done.
>

Hi,

changelog would be nice, just for a record of what's been done.

----- Original Message ----- 
From: "Laurent ROCHER" <ro...@cl...>
To: "Win32 GUI Hackers" <per...@li...>
Sent: Saturday, November 22, 2003 2:28 PM
Subject: Re: [perl-win32-gui-hackers] Changelog on commit please


> Hi,
>
> Actually, i have commit only this, in 665-Fix branch :
>
> + [Laurent Rocher] Add build with MinGW and ExtUtils-FakeConfig support.
>   You can build Win32-GUI for ActiveState Perl with Free MingW Compiler.
>   See HowTo : http://perso.club-internet.fr/rocherl/Win32GUI.html
> + [Steve Pick] GUI.pm: Fix ImageList bug
> + [Glenn Linderman] MessageLoops.cpp: Fix Window Cursor bug
>
> I try to commit one thing at a time for each file with a comment (so we
can
> see change via diff).
> And i summarize all change in Readme.txt.
> Do you prefer a specific changelog file ?
>
> PS: I have made small change on Glenn Cursor patch (detail in previous
> messag)
>
> Laurent.
>
>
>
> > Hi,
> >
> > A CVS was committed a couple of days ago by lrocher with no changelog.
Can
> > we get a log of what's changed in the latest commit so that we know what
> > fixes have been implemented? Otherwise things will get confusing.
> >
> > Steve
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>

Hi,

Actually, i have commit only this, in 665-Fix branch :

+ [Laurent Rocher] Add build with MinGW and ExtUtils-FakeConfig support.
  You can build Win32-GUI for ActiveState Perl with Free MingW Compiler.
  See HowTo : http://perso.club-internet.fr/rocherl/Win32GUI.html
+ [Steve Pick] GUI.pm: Fix ImageList bug
+ [Glenn Linderman] MessageLoops.cpp: Fix Window Cursor bug

I try to commit one thing at a time for each file with a comment (so we can
see change via diff).
And i summarize all change in Readme.txt.
Do you prefer a specific changelog file ?

PS: I have made small change on Glenn Cursor patch (detail in previous
messag)

Laurent.



> Hi,
>
> A CVS was committed a couple of days ago by lrocher with no changelog. Can
> we get a log of what's changed in the latest commit so that we know what
> fixes have been implemented? Otherwise things will get confusing.
>
> Steve

Hi,

Drag & Drop support for files is already included in Win32::GUI::AdHoc and
has been for some time.

Steve


----- Original Message ----- 
From: "Laurent ROCHER" <ro...@cl...>
To: "Win32 GUI Hackers" <per...@li...>
Sent: Friday, November 21, 2003 7:00 PM
Subject: [perl-win32-gui-hackers] Re: [perl-win32-gui-users] CVS Update ->
Drag&Drop


> It's look nice, but it's more a new feature than a Fix ;o)
>
> So, i want to know if Aldo have plan for File Drag&Drop in next release.
> And, if he want to use a separate .pm file with Win32::API dependance or
add
> it directly in GUI.xs code.
>
> I ask this only for keep compatibility with next version.
>
> Laurent.
>
>
>
> > At 21:34 2003-11-20, Laurent ROCHER wrote:
> > >I contiue to look in mail archive for more fix.
> >
> > Please add my drag-n-drop patch, both the XS code and the Perl code. No
> > need for a separate module, just integrate it into the regular source.
> >
> > This is for 0.0.558, the line numbers will probably differ from 0.0.665:
> > http://www.bahnhof.se/~johanl/perl/Win32GUI/DragDrop.pm
> >
> >
> > /J
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>

Hi,

A CVS was committed a couple of days ago by lrocher with no changelog. Can
we get a log of what's changed in the latest commit so that we know what
fixes have been implemented? Otherwise things will get confusing.

Steve

Hi,

> The only quibble I have then, is that when you said you committed my
> patch, that opens the door for confusion ... because people saw my patch
> on-line.  And then, when we coordinate other patches (like the
> accelerator keys) there would be surprises in the diffs.
>
> So, I think it would have been better if you mentioned that you had also
> made some improvements to my patch (and possibly explained them then).
>
> No lasting harm done, but it might have saved Steve some work.  And me
> some testing time (first applying and testing Steve's patch, and then
> backing that out, applying yours, and testing it).

You are right.
Now, i notify on this mailing list any patch change before apply on CVS.
It's begining so we need coordinate us ;o)

> I'll try to isolate my accelerator key bug fixes and improvements, and
> feed them to you, as that will get them into the "real" source faster
> than otherwise.
>
> I see Aldo did add me with commit privileges, and it is good to have
> several capable of that...  sometimes one might be busy like I am now...
> I'll try to get CVS set up someday, but maybe not until Jan or Feb...

If you can't commit accelerator key change before Jan, you can send me your
change and i commit it.

> But if you are willing for the role of bug-fix branch patch coordinator,
> I'll be quite content to watch, learn, provide patches to you, and be
> available as an extra testing resource re: questionable patches (come
> Jan or Feb).

I don't think only one person apply patch on CVS it's good.
I prefer work in team. We just need coordinate us and define some good
pratice.

Laurent.

It's look nice, but it's more a new feature than a Fix ;o)

So, i want to know if Aldo have plan for File Drag&Drop in next release.
And, if he want to use a separate .pm file with Win32::API dependance or add
it directly in GUI.xs code.

I ask this only for keep compatibility with next version.

Laurent.



> At 21:34 2003-11-20, Laurent ROCHER wrote:
> >I contiue to look in mail archive for more fix.
>
> Please add my drag-n-drop patch, both the XS code and the Perl code. No
> need for a separate module, just integrate it into the regular source.
>
> This is for 0.0.558, the line numbers will probably differ from 0.0.665:
> http://www.bahnhof.se/~johanl/perl/Win32GUI/DragDrop.pm
>
>
> /J

I agree

----- Original Message ----- 
From: "Laurent ROCHER" <ro...@cl...>
To: "Steve Pick" <st...@ba...>; "Win32 GUI Hackers"
<per...@li...>
Sent: Friday, November 21, 2003 6:31 PM
Subject: Re: [perl-win32-gui-hackers] Fix for PeekMessage


>
> For "A" problem, i don't think it's a else problem.
>
> You can call PeekMessage without a message parameter.
> In this case message == &PL_sv_undef, and no warming it's necessary.
>
> If you specify a message parameter, then we need a reference (SvROK) and
> must be a Array reference.
> I think it's better to move SvROK(message) in inner if, like this :
>
> BOOL
> PeekMessage(handle, min=0, max=0, message=&PL_sv_undef)
>     HWND handle
>     UINT min
>     UINT max
>     SV* message
> PREINIT:
>     MSG msg;
> CODE:
>     ZeroMemory(&msg, sizeof(msg));
>     RETVAL = PeekMessage(&msg, handle, min, max, PM_NOREMOVE);
>     if(message != &PL_sv_undef) {
>         if(SvROK(message) && SvTYPE(SvRV(message)) == SVt_PVAV) {
>             av_clear((AV*) SvRV(message));
>             av_push((AV*) SvRV(message), newSViv((long) msg.hwnd));
>             av_push((AV*) SvRV(message), newSViv(msg.message));
>             av_push((AV*) SvRV(message), newSViv(msg.wParam));
>             av_push((AV*) SvRV(message), newSViv(msg.lParam));
>             av_push((AV*) SvRV(message), newSViv(msg.time));
>             av_push((AV*) SvRV(message), newSViv(msg.pt.x));
>             av_push((AV*) SvRV(message), newSViv(msg.pt.y));
>         } else {
>             if(PL_dowarn) warn("Win32::GUI: fourth parameter to
PeekMessage
> is not an array reference");
>         }
>     }
> OUTPUT:
>     RETVAL
>
> Laurent.
>
> ----- Original Message ----- 
> From: "Steve Pick" <st...@ba...>
> To: "Win32 GUI Hackers" <per...@li...>
> Sent: Friday, November 21, 2003 2:50 AM
> Subject: [perl-win32-gui-hackers] Fix for PeekMessage
>
>
> >
> > You'll notice PeekMessage A) doesnt warn about non-references even
though
> > the warning code is there and B) Yields a ton of "attempt to free
> > unreferenced scalar" errors. The problem was an else{} in the wrong
place,
> > and making array values mortal so they got cleaned up before they ever
hit
> > your perl program, so here's it fixed.
> >
> >
>
###########################################################################
> >     # (@)METHOD:PeekMessage([MIN, MAX, MESSAGE])
> >     # Inspects the window's message queue and eventually returns data
> >     # about the message it contains; it can optionally check only for
> > message
> >     # identifiers in the range MIN..MAX; the last MESSAGE parameter, if
> >     # specified, must be an array reference.
> >     # If a message is found, the function puts in that array 7 elements
> >     # containing:
> >     #   - the handle of the window to which the message is addressed
> >     #   - the message identifier
> >     #   - the wParam argument
> >     #   - the lParam argument
> >     #   - the time when message occurs
> >     #   - the x coordinate at which message occurs
> >     #   - the y coordinate at which message occurs
> >     #
> > BOOL
> > PeekMessage(handle, min=0, max=0, message=&PL_sv_undef)
> >     HWND handle
> >     UINT min
> >     UINT max
> >     SV* message
> > PREINIT:
> >     MSG msg;
> > CODE:
> >     ZeroMemory(&msg, sizeof(msg));
> >     RETVAL = PeekMessage(&msg, handle, min, max, PM_NOREMOVE);
> >      if(message != &PL_sv_undef && SvROK(message)) {
> >         if(SvTYPE(SvRV(message)) == SVt_PVAV) {
> >             av_clear((AV*) SvRV(message));
> >             av_push((AV*) SvRV(message), newSViv((long) msg.hwnd));
> >             av_push((AV*) SvRV(message), newSViv(msg.message));
> >             av_push((AV*) SvRV(message), newSViv(msg.wParam));
> >             av_push((AV*) SvRV(message), newSViv(msg.lParam));
> >             av_push((AV*) SvRV(message), newSViv(msg.time));
> >             av_push((AV*) SvRV(message), newSViv(msg.pt.x));
> >             av_push((AV*) SvRV(message), newSViv(msg.pt.y));
> >         }
> >     }
> >     else {
> >        if(PL_dowarn) warn("Win32::GUI: fourth parameter to PeekMessage
is
> > not an array reference");
> >     }
> >  OUTPUT:
> >     RETVAL
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>

Yes, this looks better to me too.  For whatever my opinion is worth.


On approximately 11/21/2003 10:31 AM, came the following characters from
the keyboard of Laurent ROCHER:

> For "A" problem, i don't think it's a else problem.
> 
> You can call PeekMessage without a message parameter.
> In this case message == &PL_sv_undef, and no warming it's necessary.
> 
> If you specify a message parameter, then we need a reference (SvROK) and
> must be a Array reference.
> I think it's better to move SvROK(message) in inner if, like this :
> 
> BOOL
> PeekMessage(handle, min=0, max=0, message=&PL_sv_undef)
>     HWND handle
>     UINT min
>     UINT max
>     SV* message
> PREINIT:
>     MSG msg;
> CODE:
>     ZeroMemory(&msg, sizeof(msg));
>     RETVAL = PeekMessage(&msg, handle, min, max, PM_NOREMOVE);
>     if(message != &PL_sv_undef) {
>         if(SvROK(message) && SvTYPE(SvRV(message)) == SVt_PVAV) {
>             av_clear((AV*) SvRV(message));
>             av_push((AV*) SvRV(message), newSViv((long) msg.hwnd));
>             av_push((AV*) SvRV(message), newSViv(msg.message));
>             av_push((AV*) SvRV(message), newSViv(msg.wParam));
>             av_push((AV*) SvRV(message), newSViv(msg.lParam));
>             av_push((AV*) SvRV(message), newSViv(msg.time));
>             av_push((AV*) SvRV(message), newSViv(msg.pt.x));
>             av_push((AV*) SvRV(message), newSViv(msg.pt.y));
>         } else {
>             if(PL_dowarn) warn("Win32::GUI: fourth parameter to PeekMessage
> is not an array reference");
>         }
>     }
> OUTPUT:
>     RETVAL
> 
> Laurent.
> 
> ----- Original Message ----- 
> From: "Steve Pick" <st...@ba...>
> To: "Win32 GUI Hackers" <per...@li...>
> Sent: Friday, November 21, 2003 2:50 AM
> Subject: [perl-win32-gui-hackers] Fix for PeekMessage
> 
> 
> 
>>You'll notice PeekMessage A) doesnt warn about non-references even though
>>the warning code is there and B) Yields a ton of "attempt to free
>>unreferenced scalar" errors. The problem was an else{} in the wrong place,
>>and making array values mortal so they got cleaned up before they ever hit
>>your perl program, so here's it fixed.
>>
>>
> 
> ###########################################################################
> 
>>    # (@)METHOD:PeekMessage([MIN, MAX, MESSAGE])
>>    # Inspects the window's message queue and eventually returns data
>>    # about the message it contains; it can optionally check only for
>>message
>>    # identifiers in the range MIN..MAX; the last MESSAGE parameter, if
>>    # specified, must be an array reference.
>>    # If a message is found, the function puts in that array 7 elements
>>    # containing:
>>    #   - the handle of the window to which the message is addressed
>>    #   - the message identifier
>>    #   - the wParam argument
>>    #   - the lParam argument
>>    #   - the time when message occurs
>>    #   - the x coordinate at which message occurs
>>    #   - the y coordinate at which message occurs
>>    #
>>BOOL
>>PeekMessage(handle, min=0, max=0, message=&PL_sv_undef)
>>    HWND handle
>>    UINT min
>>    UINT max
>>    SV* message
>>PREINIT:
>>    MSG msg;
>>CODE:
>>    ZeroMemory(&msg, sizeof(msg));
>>    RETVAL = PeekMessage(&msg, handle, min, max, PM_NOREMOVE);
>>     if(message != &PL_sv_undef && SvROK(message)) {
>>        if(SvTYPE(SvRV(message)) == SVt_PVAV) {
>>            av_clear((AV*) SvRV(message));
>>            av_push((AV*) SvRV(message), newSViv((long) msg.hwnd));
>>            av_push((AV*) SvRV(message), newSViv(msg.message));
>>            av_push((AV*) SvRV(message), newSViv(msg.wParam));
>>            av_push((AV*) SvRV(message), newSViv(msg.lParam));
>>            av_push((AV*) SvRV(message), newSViv(msg.time));
>>            av_push((AV*) SvRV(message), newSViv(msg.pt.x));
>>            av_push((AV*) SvRV(message), newSViv(msg.pt.y));
>>        }
>>    }
>>    else {
>>       if(PL_dowarn) warn("Win32::GUI: fourth parameter to PeekMessage is
>>not an array reference");
>>    }
>> OUTPUT:
>>    RETVAL
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
> 
> 

-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.

Hi Laurent,

Indeed, your revisions to my patch are better than my original... and 
with your revision, Steve's extra line of code isn't needed (and it 
concerned me that he was picking a particular cursor shape... that 
sounded wrong, but I had no clue what would be right).  And you cleaned 
out the return FALSE path completely, which makes more sense to me.  I'm 
not really an expert in Windows GUI work, so I was just whacking around 
with my patch there, so while I improved it a little, you improved it a lot.

The only quibble I have then, is that when you said you committed my 
patch, that opens the door for confusion ... because people saw my patch 
on-line.  And then, when we coordinate other patches (like the 
accelerator keys) there would be surprises in the diffs.

So, I think it would have been better if you mentioned that you had also 
made some improvements to my patch (and possibly explained them then).

No lasting harm done, but it might have saved Steve some work.  And me 
some testing time (first applying and testing Steve's patch, and then 
backing that out, applying yours, and testing it).

I'll try to isolate my accelerator key bug fixes and improvements, and 
feed them to you, as that will get them into the "real" source faster 
than otherwise.

I see Aldo did add me with commit privileges, and it is good to have 
several capable of that...  sometimes one might be busy like I am now... 
I'll try to get CVS set up someday, but maybe not until Jan or Feb...

But if you are willing for the role of bug-fix branch patch coordinator, 
I'll be quite content to watch, learn, provide patches to you, and be 
available as an extra testing resource re: questionable patches (come 
Jan or Feb).

This particular patch is extremely beneficial to everyone, including my 
projects, so I can afford the time spent on it, even now while I am 
still busy.  It is all priorities, of course.


On approximately 11/21/2003 10:13 AM, came the following characters from
the keyboard of Laurent ROCHER:
> Hi,
> 
> I haven't commit exact Glenn patch.
> I have commmit this :
> 
>     case WM_SETCURSOR:
>         {
>             WORD nHitTest = LOWORD( lParam );
>             if( nHitTest == HTCLIENT ) {  // only diddle cursor in client
> areas
>                 LPPERLWIN32GUI_USERDATA perlud;
>                 perlud = (LPPERLWIN32GUI_USERDATA) GetWindowLong((HWND)
> wParam, GWL_USERDATA);
>                 if( ValidUserData(perlud) && perlud->hCursor != NULL ) {
>                     SetCursor( perlud->hCursor );
>                     return TRUE;
>                 }
>             }
>         break;
>         }
> 
> It's return TRUE only if window have a cursor and nHitTest == HTCLIENT.
> Otherwise, i call DefWindowProc do his job.
> I haven't any more cursor problem.
> 
> I think add perlcs.iEventModel = PERLWIN32GUI_EM_BYNAME; in Window create
> override default Class cursor.
> 
> Can you test with only above code (or CVS code), and say me if it work for
> you ?
> 
> Laurent.
> 
> ----- Original Message ----- 
> From: "Glenn Linderman" <pe...@ne...>
> To: "Steve Pick" <st...@ba...>
> Cc: "Win32 GUI Users" <per...@li...>; "Win32
> GUI Hackers" <per...@li...>
> Sent: Friday, November 21, 2003 1:50 AM
> Subject: [perl-win32-gui-users] Re: [perl-win32-gui-hackers] additional fix
> for cursors
> 
> 
> 
>>Excellant.  I had noticed the resize cursor persisted until the mouse
>>pointer got to a "real" sub object inside the main window... annoying
>>but not (to me) as annoying as not having the resize cursors at all, and
>>not a problem on windows that are filled with sub objects.  But this fix
>>does the trick.
>>
>>Thanks, Steve.  I've applied it to my version, and I'll be sure to
>>coordinate with Laurent to get all my fixes into the bug-fix branch.
>>
>>
>>On approximately 11/20/2003 4:36 PM, came the following characters from
>>the keyboard of Steve Pick:
>>
>>>In addition to Glenn Linderman's fix for resize cursors this should be
> 
> put
> 
>>>in (@)INTERNAL:Create(%OPTIONS) near the top:
>>>
>>>perlcs.hCursor = LoadCursor(NULL, IDC_ARROW);
>>>
>>>I've put it just below the line that reads
>>>perlcs.iEventModel = PERLWIN32GUI_EM_BYNAME;
>>>
>>>This will stop the cursor remaining as a resize handle, hourglass etc
> 
> when
> 
>>>moved inside the window.
>>>
>>>Steve
>>
>>-- 
>>Glenn -- http://nevcal.com/
> 
> 
> 
> 

-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.

For "A" problem, i don't think it's a else problem.

You can call PeekMessage without a message parameter.
In this case message == &PL_sv_undef, and no warming it's necessary.

If you specify a message parameter, then we need a reference (SvROK) and
must be a Array reference.
I think it's better to move SvROK(message) in inner if, like this :

BOOL
PeekMessage(handle, min=0, max=0, message=&PL_sv_undef)
    HWND handle
    UINT min
    UINT max
    SV* message
PREINIT:
    MSG msg;
CODE:
    ZeroMemory(&msg, sizeof(msg));
    RETVAL = PeekMessage(&msg, handle, min, max, PM_NOREMOVE);
    if(message != &PL_sv_undef) {
        if(SvROK(message) && SvTYPE(SvRV(message)) == SVt_PVAV) {
            av_clear((AV*) SvRV(message));
            av_push((AV*) SvRV(message), newSViv((long) msg.hwnd));
            av_push((AV*) SvRV(message), newSViv(msg.message));
            av_push((AV*) SvRV(message), newSViv(msg.wParam));
            av_push((AV*) SvRV(message), newSViv(msg.lParam));
            av_push((AV*) SvRV(message), newSViv(msg.time));
            av_push((AV*) SvRV(message), newSViv(msg.pt.x));
            av_push((AV*) SvRV(message), newSViv(msg.pt.y));
        } else {
            if(PL_dowarn) warn("Win32::GUI: fourth parameter to PeekMessage
is not an array reference");
        }
    }
OUTPUT:
    RETVAL

Laurent.

----- Original Message ----- 
From: "Steve Pick" <st...@ba...>
To: "Win32 GUI Hackers" <per...@li...>
Sent: Friday, November 21, 2003 2:50 AM
Subject: [perl-win32-gui-hackers] Fix for PeekMessage


>
> You'll notice PeekMessage A) doesnt warn about non-references even though
> the warning code is there and B) Yields a ton of "attempt to free
> unreferenced scalar" errors. The problem was an else{} in the wrong place,
> and making array values mortal so they got cleaned up before they ever hit
> your perl program, so here's it fixed.
>
>
###########################################################################
>     # (@)METHOD:PeekMessage([MIN, MAX, MESSAGE])
>     # Inspects the window's message queue and eventually returns data
>     # about the message it contains; it can optionally check only for
> message
>     # identifiers in the range MIN..MAX; the last MESSAGE parameter, if
>     # specified, must be an array reference.
>     # If a message is found, the function puts in that array 7 elements
>     # containing:
>     #   - the handle of the window to which the message is addressed
>     #   - the message identifier
>     #   - the wParam argument
>     #   - the lParam argument
>     #   - the time when message occurs
>     #   - the x coordinate at which message occurs
>     #   - the y coordinate at which message occurs
>     #
> BOOL
> PeekMessage(handle, min=0, max=0, message=&PL_sv_undef)
>     HWND handle
>     UINT min
>     UINT max
>     SV* message
> PREINIT:
>     MSG msg;
> CODE:
>     ZeroMemory(&msg, sizeof(msg));
>     RETVAL = PeekMessage(&msg, handle, min, max, PM_NOREMOVE);
>      if(message != &PL_sv_undef && SvROK(message)) {
>         if(SvTYPE(SvRV(message)) == SVt_PVAV) {
>             av_clear((AV*) SvRV(message));
>             av_push((AV*) SvRV(message), newSViv((long) msg.hwnd));
>             av_push((AV*) SvRV(message), newSViv(msg.message));
>             av_push((AV*) SvRV(message), newSViv(msg.wParam));
>             av_push((AV*) SvRV(message), newSViv(msg.lParam));
>             av_push((AV*) SvRV(message), newSViv(msg.time));
>             av_push((AV*) SvRV(message), newSViv(msg.pt.x));
>             av_push((AV*) SvRV(message), newSViv(msg.pt.y));
>         }
>     }
>     else {
>        if(PL_dowarn) warn("Win32::GUI: fourth parameter to PeekMessage is
> not an array reference");
>     }
>  OUTPUT:
>     RETVAL

Hi,

I haven't commit exact Glenn patch.
I have commmit this :

    case WM_SETCURSOR:
        {
            WORD nHitTest = LOWORD( lParam );
            if( nHitTest == HTCLIENT ) {  // only diddle cursor in client
areas
                LPPERLWIN32GUI_USERDATA perlud;
                perlud = (LPPERLWIN32GUI_USERDATA) GetWindowLong((HWND)
wParam, GWL_USERDATA);
                if( ValidUserData(perlud) && perlud->hCursor != NULL ) {
                    SetCursor( perlud->hCursor );
                    return TRUE;
                }
            }
        break;
        }

It's return TRUE only if window have a cursor and nHitTest == HTCLIENT.
Otherwise, i call DefWindowProc do his job.
I haven't any more cursor problem.

I think add perlcs.iEventModel = PERLWIN32GUI_EM_BYNAME; in Window create
override default Class cursor.

Can you test with only above code (or CVS code), and say me if it work for
you ?

Laurent.

----- Original Message ----- 
From: "Glenn Linderman" <pe...@ne...>
To: "Steve Pick" <st...@ba...>
Cc: "Win32 GUI Users" <per...@li...>; "Win32
GUI Hackers" <per...@li...>
Sent: Friday, November 21, 2003 1:50 AM
Subject: [perl-win32-gui-users] Re: [perl-win32-gui-hackers] additional fix
for cursors


> Excellant.  I had noticed the resize cursor persisted until the mouse
> pointer got to a "real" sub object inside the main window... annoying
> but not (to me) as annoying as not having the resize cursors at all, and
> not a problem on windows that are filled with sub objects.  But this fix
> does the trick.
>
> Thanks, Steve.  I've applied it to my version, and I'll be sure to
> coordinate with Laurent to get all my fixes into the bug-fix branch.
>
>
> On approximately 11/20/2003 4:36 PM, came the following characters from
> the keyboard of Steve Pick:
> > In addition to Glenn Linderman's fix for resize cursors this should be
put
> > in (@)INTERNAL:Create(%OPTIONS) near the top:
> >
> > perlcs.hCursor = LoadCursor(NULL, IDC_ARROW);
> >
> > I've put it just below the line that reads
> > perlcs.iEventModel = PERLWIN32GUI_EM_BYNAME;
> >
> > This will stop the cursor remaining as a resize handle, hourglass etc
when
> > moved inside the window.
> >
> > Steve
>
> -- 
> Glenn -- http://nevcal.com/

You'll notice PeekMessage A) doesnt warn about non-references even though
the warning code is there and B) Yields a ton of "attempt to free
unreferenced scalar" errors. The problem was an else{} in the wrong place,
and making array values mortal so they got cleaned up before they ever hit
your perl program, so here's it fixed.

###########################################################################
    # (@)METHOD:PeekMessage([MIN, MAX, MESSAGE])
    # Inspects the window's message queue and eventually returns data
    # about the message it contains; it can optionally check only for
message
    # identifiers in the range MIN..MAX; the last MESSAGE parameter, if
    # specified, must be an array reference.
    # If a message is found, the function puts in that array 7 elements
    # containing:
    #   - the handle of the window to which the message is addressed
    #   - the message identifier
    #   - the wParam argument
    #   - the lParam argument
    #   - the time when message occurs
    #   - the x coordinate at which message occurs
    #   - the y coordinate at which message occurs
    #
BOOL
PeekMessage(handle, min=0, max=0, message=&PL_sv_undef)
    HWND handle
    UINT min
    UINT max
    SV* message
PREINIT:
    MSG msg;
CODE:
    ZeroMemory(&msg, sizeof(msg));
    RETVAL = PeekMessage(&msg, handle, min, max, PM_NOREMOVE);
     if(message != &PL_sv_undef && SvROK(message)) {
        if(SvTYPE(SvRV(message)) == SVt_PVAV) {
            av_clear((AV*) SvRV(message));
            av_push((AV*) SvRV(message), newSViv((long) msg.hwnd));
            av_push((AV*) SvRV(message), newSViv(msg.message));
            av_push((AV*) SvRV(message), newSViv(msg.wParam));
            av_push((AV*) SvRV(message), newSViv(msg.lParam));
            av_push((AV*) SvRV(message), newSViv(msg.time));
            av_push((AV*) SvRV(message), newSViv(msg.pt.x));
            av_push((AV*) SvRV(message), newSViv(msg.pt.y));
        }
    }
    else {
       if(PL_dowarn) warn("Win32::GUI: fourth parameter to PeekMessage is
not an array reference");
    }
 OUTPUT:
    RETVAL

Excellant.  I had noticed the resize cursor persisted until the mouse 
pointer got to a "real" sub object inside the main window... annoying 
but not (to me) as annoying as not having the resize cursors at all, and 
not a problem on windows that are filled with sub objects.  But this fix 
does the trick.

Thanks, Steve.  I've applied it to my version, and I'll be sure to 
coordinate with Laurent to get all my fixes into the bug-fix branch.


On approximately 11/20/2003 4:36 PM, came the following characters from
the keyboard of Steve Pick:
> In addition to Glenn Linderman's fix for resize cursors this should be put
> in (@)INTERNAL:Create(%OPTIONS) near the top:
> 
> perlcs.hCursor = LoadCursor(NULL, IDC_ARROW);
> 
> I've put it just below the line that reads
> perlcs.iEventModel = PERLWIN32GUI_EM_BYNAME;
> 
> This will stop the cursor remaining as a resize handle, hourglass etc when
> moved inside the window.
> 
> Steve

-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.

In addition to Glenn Linderman's fix for resize cursors this should be put
in (@)INTERNAL:Create(%OPTIONS) near the top:

perlcs.hCursor = LoadCursor(NULL, IDC_ARROW);

I've put it just below the line that reads
perlcs.iEventModel = PERLWIN32GUI_EM_BYNAME;

This will stop the cursor remaining as a resize handle, hourglass etc when
moved inside the window.

Steve