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

Re: [perl-win32-gui-hackers] DoEvents() bug.

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

On approximately 12/9/2003 2:59 AM, came the following characters from
the keyboard of Stephen Pick:

> Hi all.
> 
> When I do this:
> 
> Win32::GUI::Dialog()
> 
> I receive all my events like WM_LBUTTONDOWN (-onMouseDown) once, as
> should happen.
> 
> When I do this:
> 
> while(1) {
> 	Win32::GUI::DoEvents()
> 	print "Loop!\n";
> }
> 
> I get endless calls to my event handler so long as the mouse button is
> down. I have NO idea why. Must be some kind of windows internal thing.

Certain Windows messages are "queued and combined" if you are not 
looking, but the more often you look, the more often you get them....  I 
could say if MouseDown is one of those, off hand.

I have noticed that a difference between Dialog() and DoEvents() is that 
if used to process a dialog box containing a text box, that the former 
responds normally, but the latter generally doubles the characters 
received by the text box.  One difference in my situation is that I was 
  calling DoEvents() from an event, and that might cause some sort of 
reentrancy problem, but I couldn't understand what it would be if it is 
such.  I gave up and restructured my code to use Dialog() only.

> Additionally, since the code for DoEvents() and Dialog() is practically
> identical except that DoEvents uses PeekMessage and Dialog uses
> GetMessage, I copied both into seperate files and took a look at them in
> WinMerge. Interesting. Dialog does ENTER; SAVETMPS; before doing
> GetMessage and FREETMPS; LEAVE; at the end of it's while() loop.
> DoEvents() doesn't do this. 

This is because Dialog is "long-running" and needs to be sure to do Perl 
temporary variable management, and DoEvents returns to Perl more often, 
so can let Perl do the temporary variable management.  I think.

> Also, DoEvents has the line "acc =
> perlud->hAcc;", and Dialog() DOESNT have that. Dialog() does a
> comparison on acc (acc != NULL) in the next few lines just like DoEvents
> does, but this comparison will always yield false in Dialog().

I think that was one of the lines I "fixed" in making accelerator keys 
work.  If not, it should have been.  What version of source are you 
looking at?

> So. I don't have a compiler here but this is weird. Surely these
> functions should be identical but for the change from GetMessage to
> PeekMessage. Moreover, if these functions should be identical then why
> write the same code for both when a simple function that does either
> PeekMessage or GetMessage depending on an argument would remove a lot of
> redundant code, for example the new function checkEvents(hwnd,
> peekmessage) would do the current Dialog() code with PeekMessage if
> peekmessage was set to 1, otherwise it'd do GetMessage, and the Dialog()
> and DoEvents() methods could be truncated to:

Well, the exit condition is different too, not just the call to 
GetMessage vs PeekMessage.  But that also could be based on the 
"argument".  I agree there is much redundant code there, also see DoModal.

> 
> DWORD
> Dialog(hwnd=NULL)
> 	HWND hwnd
> CODE:
> 	RETVAL = checkEvents(hwnd,0);
> OUTPUT:
> 	RETVAL
> 
> DWORD
> DoEvents(hwnd=NULL)
> 	HWND hwnd
> CODE:
> 	RETVAL = checkEvents(hwnd,1);
> OUTPUT:
> 	RETVAL
> 
> 
> 
> 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
> 
> 

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

[perl-win32-gui-hackers] DoEvents() bug.

[Stephen P. <Ste...@uc...>]

Hi all.

When I do this:

Win32::GUI::Dialog()

I receive all my events like WM_LBUTTONDOWN (-onMouseDown) once, as
should happen.

When I do this:

while(1) {
	Win32::GUI::DoEvents()
	print "Loop!\n";
}

I get endless calls to my event handler so long as the mouse button is
down. I have NO idea why. Must be some kind of windows internal thing.

Additionally, since the code for DoEvents() and Dialog() is practically
identical except that DoEvents uses PeekMessage and Dialog uses
GetMessage, I copied both into seperate files and took a look at them in
WinMerge. Interesting. Dialog does ENTER; SAVETMPS; before doing
GetMessage and FREETMPS; LEAVE; at the end of it's while() loop.
DoEvents() doesn't do this. Also, DoEvents has the line "acc =3D
perlud->hAcc;", and Dialog() DOESNT have that. Dialog() does a
comparison on acc (acc !=3D NULL) in the next few lines just like =
DoEvents
does, but this comparison will always yield false in Dialog().

So. I don't have a compiler here but this is weird. Surely these
functions should be identical but for the change from GetMessage to
PeekMessage. Moreover, if these functions should be identical then why
write the same code for both when a simple function that does either
PeekMessage or GetMessage depending on an argument would remove a lot of
redundant code, for example the new function checkEvents(hwnd,
peekmessage) would do the current Dialog() code with PeekMessage if
peekmessage was set to 1, otherwise it'd do GetMessage, and the Dialog()
and DoEvents() methods could be truncated to:

DWORD
Dialog(hwnd=3DNULL)
	HWND hwnd
CODE:
	RETVAL =3D checkEvents(hwnd,0);
OUTPUT:
	RETVAL

DWORD
DoEvents(hwnd=3DNULL)
	HWND hwnd
CODE:
	RETVAL =3D checkEvents(hwnd,1);
OUTPUT:
	RETVAL



Steve

Re: [perl-win32-gui-hackers] Proposition for NEM

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

On approximately 12/5/2003 10:19 AM, came the following characters from
the keyboard of Steve Pick:
> Hi,
> 
>>Is there any reason HEM cannot be used in conjunction with the old event
>>model?
> 
> Not that I can think of. I just forgot to add it to that bit. 

I'd find it more likely useful to me in the short term, if it were added 
to the old event model ("OEM" ??? Horrible acronym, but we need something).

> My hooks arent
> real Win32 hooks at all, as you know, and I put the processing of them after
> the NEM stuff so as to make it more difficult to screw up normal
> functionality. If you want to handle something already handled by NEM, I
> recommend you use NEM. If you must use "HEM" then things will probably still
> work as expected, since it's likely you will override changes made by the
> NEM handlers.

Yes, this makes more sense the longer I think about it, and the more you 
explain it!  Thanks.

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

Re: [perl-win32-gui-hackers] Proposition for NEM

[Steve P. <st...@ba...>]

Hi,

> Is there any reason HEM cannot be used in conjunction with the old event
> model?

Not that I can think of. I just forgot to add it to that bit. My hooks arent
real Win32 hooks at all, as you know, and I put the processing of them after
the NEM stuff so as to make it more difficult to screw up normal
functionality. If you want to handle something already handled by NEM, I
recommend you use NEM. If you must use "HEM" then things will probably still
work as expected, since it's likely you will override changes made by the
NEM handlers.

Steve

----- Original Message ----- 
From: "Glenn Linderman" <pe...@ne...>
To: "Aldo Calpini" <da...@pe...>
Cc: <per...@li...>; "Stephen Pick"
<Ste...@uc...>
Sent: Friday, December 05, 2003 4:42 PM
Subject: Re: [perl-win32-gui-hackers] Proposition for NEM


> On approximately 12/5/2003 7:00 AM, came the following characters from
> the keyboard of Aldo Calpini:
>
> > Stephen Pick wrote:
> >
> >>Does typing "$win->Hook(132,\&hello)" class as an "*explicit* request"?
> >>:)
> >
> >
> > Steve, you have good points. I agree wholeheartedly with you, so what
> > more can I say? go for it :-)
> >
> > just a quick note: the NEM, in its present state, is not really
> > useable. I have different plans for the future (I already coded
> > something in my codebase, but as I said it's not fully functional
> > yet); that said, just be prepared for something completely different
> > once I've ironed out all the design stuff and I will disclose my
> > new codebase (which will probably be Win32::GUI 1.00 (at least! :-)).
> >
> > if I find the time, I would like to write a (very) technical article
> > about all this Event Model stuff on Win32::GUI, so that you can see
> > where we are (supposedly) going. keep on working on the current
> > release (.665-Fix) for now, and we'll sort out how to re-integrate
> > all the good things in the upcoming 1.00.
>
> All this sounds good.  I was a little surprised your hooks are done
> after regular Win32::GUI processing, but I guess they are still done
> before/instead of DefWindowProc, so that makes sense to me.
>
> Is there any reason HEM cannot be used in conjunction with the old event
> model?
>
> -- 
> 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.
>
>
>
> -------------------------------------------------------
> 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
>

Re: [perl-win32-gui-hackers] Proposition for NEM

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

On approximately 12/5/2003 7:00 AM, came the following characters from
the keyboard of Aldo Calpini:

> Stephen Pick wrote:
> 
>>Does typing "$win->Hook(132,\&hello)" class as an "*explicit* request"?
>>:)
> 
> 
> Steve, you have good points. I agree wholeheartedly with you, so what
> more can I say? go for it :-)
> 
> just a quick note: the NEM, in its present state, is not really
> useable. I have different plans for the future (I already coded
> something in my codebase, but as I said it's not fully functional
> yet); that said, just be prepared for something completely different
> once I've ironed out all the design stuff and I will disclose my
> new codebase (which will probably be Win32::GUI 1.00 (at least! :-)).
> 
> if I find the time, I would like to write a (very) technical article
> about all this Event Model stuff on Win32::GUI, so that you can see
> where we are (supposedly) going. keep on working on the current
> release (.665-Fix) for now, and we'll sort out how to re-integrate
> all the good things in the upcoming 1.00.

All this sounds good.  I was a little surprised your hooks are done 
after regular Win32::GUI processing, but I guess they are still done 
before/instead of DefWindowProc, so that makes sense to me.

Is there any reason HEM cannot be used in conjunction with the old event 
model?

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

Re: [perl-win32-gui-hackers] Proposition for NEM

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

Stephen Pick wrote:
> Does typing "$win->Hook(132,\&hello)" class as an "*explicit* request"?
> :)

Steve, you have good points. I agree wholeheartedly with you, so what
more can I say? go for it :-)

just a quick note: the NEM, in its present state, is not really
useable. I have different plans for the future (I already coded
something in my codebase, but as I said it's not fully functional
yet); that said, just be prepared for something completely different
once I've ironed out all the design stuff and I will disclose my
new codebase (which will probably be Win32::GUI 1.00 (at least! :-)).

if I find the time, I would like to write a (very) technical article
about all this Event Model stuff on Win32::GUI, so that you can see
where we are (supposedly) going. keep on working on the current
release (.665-Fix) for now, and we'll sort out how to re-integrate
all the good things in the upcoming 1.00.



cheers,
Aldo

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

RE: [perl-win32-gui-hackers] Proposition for NEM

[Stephen P. <Ste...@uc...>]

Hi Aldo,

>1) you can't easily (I mean, without a lot of effort) intercept all
>   kind of messages. <snip>

I'm aware of this. Currently this is not meant as a simplicity feature;
the NEM does that already. It's meant as something for people who know
what they're doing when the NEM won't do, so they can process events
without recompiling the module. Hackers should be aware of where their
message is going to be going. The NEM supports a simpler interface to
windows messaging, this hooking event model offers a more complicated
one which supports all the messages that the NEM does not.

>2) getting out something useful from wParam and lParam may be really
>   hard sometimes, and you would need a lot of pack() and unpack()
>   and a deep knowledge of how C (and the Windows SDK) manages memory
>   or you risk to blow up things very easily.

This is true. I really should have offered more than just the wParam and
lParam, but since it's not meant for your "average" user right at the
moment, it doesnt matter. Once you start catering for people not knowing
stuff, you end up limiting capabilities in favor of simplicity. This IS
simple for people who have the brains to read a few lines of MSDN, and
they'd have to do that anyway to learn about the constants for messages.

>3) this may clash with Win32::GUI's own message processing. what to
>   do when you hook something to WM_NOTIFY, for example? if this
>   comes before what Win32::GUI already does, you may break things
>   and your GUI will be completely disfunctional.

It doesnt. All the processing on hooks is done AFTER AND IN ADDITION TO
any other NEM message processing.

>4) if not used properly, it could also slow things a lot. there
>   are some messages (like WM_SETCURSOR for example) that are
>   sent several times a second to a window. calling a Perl sub
>   each time such an event is seen will cause your program to be
>   as slow as a slug.

True, but since the current Win32::GUI NEM calls my message handlers 40
or 50 times for a simple mousedown event for reasons I can NOT figure
out (believe me, I've hunted and hunted for the cause), it isn't the
biggest problem currently. If this methodology slows down your
application, just don't use it. Find another way. I actually wrote this
routine for capturing WM_SETCURSOR messages, which should only be sent
when the OS has reset the cursor to the default class cursor, and that
SHOULD usually only happen on mouse move. Since there are already NEM
events that generate perl calls potentially hundreds of times per second
(-onMouseMove, -onResize for example), I can't see much justification in
this point.
  =20
>5) to summarize points 1-4, this is a nice feature when (and if) you
>   have the knowledge of the Windows GUI internals, but it has the
>   following drawbacks:
>   - is potentially dangerous and prone to be abused in all sorts
>     of nasty ways

I've captured every kind of message that the NEM supports already with
it and havent found a problem. The only potential problem is that you
have to watch your return values in handlers. If you capture WM_PAINT
and return 0, the window just won't be repainted. However this is
exactly the behaviour I would expect and desire from such functionality.
If I want to discard PAINT messages then I should be able to. The Hook
and UnHook routines are meant for hacking more than anything, for doing
things that the NEM cannot currently do.

>   - is absolutely impossible to document it properly, and this will
>     be an inevitable cause of frustration to the end user

A lot of Win32::GUI needs documentation and I am planning on writing up
and correcting a lot of issues with the current docs, and maybe
PODifying it all over the weekend. Yes Hook and UnHook are not easy to
document, but then neither is PeekMessage() or GetMessage(). It's
difficult to document the pitfalls of capturing messages and returning
the wrong values, but it's easy to say "Read the API documentation on
message handling".

   - it may cause "cargo-cult" programming that in the long run
     will do more harm than good (see the experience with -style)

People will always do things badly. Currently I can think of a few much
nastier ways to do this, most of which involve splatting in a ton of new
WM_XXX events in GUI_MessageLoops.cpp and recompiling. That is horrible,
especially since they're now running an incompatible version of
Win32::GUI if they do it, so none of their releases will work with other
people's libs. I'm unsure of the cargo-cult thing, i think that people
will tend to favour the NEM over this since the NEM is considerably
easier to use and provides custom information on the event that
occurred. I was doing the horrible method, and I'm thanking heaven that
i dont have to do that anymore (I take my software home, it doesnt work!
I left my fixed version of Win32::GUI at work! damn! etc.).

>
>all in all, I think this is a good idea (the very first version of
>Win32::GUI used a message loop where all WM_* were sent directly to
>a Perl subroutine, but soon I realized that this was not a Good
>Thing at all).

Yeah I thought of doing that but then immediately thought "aaargh
kludge".

> I don't think this should be categorized as NEM, but as
>PUEM (Power User Event Model) instead, and this should be something
>available only on *explicit* request by the programmer, or we may only
>be causing more confusion than we can handle.

Exactly. HEM =3D Hacker Event Model. However it should probably only be
documented as such. I don't like the idea of creating a whole new event
model for this kind of stuff, because then Win32::GUI sources would
become even more confusing to read :). Like I said many times, this is
just for the hackers who want something that Win32::GUI's current event
models do not support (like me) and is only a preliminary experiment. It
seems to work, and seems to work very well. Whether it'll screw
everything else up is yet to be seen, but it can easilly be taken out if
it causes too many problems. Hey, that's what a CVS version is for.

Does typing "$win->Hook(132,\&hello)" class as an "*explicit* request"?
:)

Regards,

Steve

Re: [perl-win32-gui-hackers] Proposition for NEM

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

Steve Pick wrote:
> Hello,
>
> Here's a nice idea:

mmm. that's nice, but not as nice as it may seem. I see many problems
with this one:

1) you can't easily (I mean, without a lot of effort) intercept all
   kind of messages. this is due to the rather complex nature of
   the Windows messaging system. just to make an example, WM_MOUSEMOVE
   messages are always sent to the window itself (eg. the handle
   of the window when the mouse moves over an *empty area* of the
   window, the handle of a button when the mouse moves over a button
   contained in the window). a click on the button, on the other
   hand, is always sent to the *container* window in the form of
   a WM_COMMAND message, so you won't get it attaching a "hook"
   to the button itself. that's rather confusing. and that's also
   why most of the complexity of Win32::GUI is there, otherwise it
   would be a really linear and simple module.

2) getting out something useful from wParam and lParam may be really
   hard sometimes, and you would need a lot of pack() and unpack()
   and a deep knowledge of how C (and the Windows SDK) manages memory
   or you risk to blow up things very easily.

3) this may clash with Win32::GUI's own message processing. what to
   do when you hook something to WM_NOTIFY, for example? if this
   comes before what Win32::GUI already does, you may break things
   and your GUI will be completely disfunctional.

4) if not used properly, it could also slow things a lot. there
   are some messages (like WM_SETCURSOR for example) that are
   sent several times a second to a window. calling a Perl sub
   each time such an event is seen will cause your program to be
   as slow as a slug.
   
5) to summarize points 1-4, this is a nice feature when (and if) you
   have the knowledge of the Windows GUI internals, but it has the
   following drawbacks:
   - is potentially dangerous and prone to be abused in all sorts
     of nasty ways
   - is absolutely impossible to document it properly, and this will
     be an inevitable cause of frustration to the end user
   - it may cause "cargo-cult" programming that in the long run
     will do more harm than good (see the experience with -style)
   

all in all, I think this is a good idea (the very first version of
Win32::GUI used a message loop where all WM_* were sent directly to
a Perl subroutine, but soon I realized that this was not a Good
Thing at all). I don't think this should be categorized as NEM, but as
PUEM (Power User Event Model) instead, and this should be something
available only on *explicit* request by the programmer, or we may only
be causing more confusion than we can handle.


cheers,
Aldo

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

[perl-win32-gui-hackers] [CVS Commit] (again)

[Steve P. <st...@ba...>]

Hi,

In this episode:

Hook(handle, msg, sub); or $win->Hook(msg, sub);

Allows you to say "whenever the window receives this msg id, call the given
subroutine with the msg's wParam and lParam as arguments".

This basically infinitely expands the NEM to encapsulate any event you want.
The sub given needs to be a coderef, otherwise it just won't register your
hook. The msg must be a number (not a freakin' string, for all those users
who dont know the difference between a constant and a bareword-string). If
you want to re-define the hook, err, call it again. This will probably cause
a memory leak, since it doesnt decrement the refcount when you re-assign the
AV, but hey, that'll be fixed soon (oops.).

UnHook(handle,msg); or $win->UnHook(msg);
Removes the hook for the given msg.

Please experiment with this, be ready for crashes. I've not got it to
explode yet, but it's worth heavilly testing.

Steve

Re: [perl-win32-gui-hackers] Proposition for NEM

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

Well, well, well.  Should I use the "great minds think alike" line?

Or is this just so obviously a good idea that we both have thought of it?

Clearly there are some well-defined events that need to have particular 
handling applied, and Win32::GUI needs to default to doing that handling.

Clearly any event for which a handler exists, it would be nice to be 
able to override or supplement the default handling.  I suppose for full 
generality, the hooks should define whether they are "pre-default 
handling" hooks, or "post-default handling" hooks, but it seems that 
most things in Windows are set up so that only "pre-default handling 
hooks" are needed.  But I'm no Windows expert, so correct me here if I'm 
wrong.

One of my most desired features for the NEM, other than getting the bugs 
and incompletenesses out of it, is the ability to obtain a reference to 
the "current handler", so that a new handler could be written to wrap 
the "current handler", or to substitute for it for a while, and then put 
it back.  Without that, NEM is not very extensible.

And the idea of defining the events for which the user can define hooks, 
which is the gist of your message, is clearly the way to go for full 
capability.  It is not clear to me if such a handler should be placed in 
Win32::GUI::Dialog/DoEvents/etc., or in the MessageLoops code, probably 
the latter, but there are so many of them, and I don't even understand 
fully why there are so many of them.  So the former seems like a more 
central location!

When I was contemplating finishing or replacing Win32::GUI since Aldo 
was "incognito" for an extended period, I considered discarding the 
MessageLoops stuff entirely, putting the hooks you suggest into Dialog, 
and discovering what else I didn't know, and how disastrous it would 
have been to do so... but I decided the shortest path to a working 
project would be to fix a few bugs in the old event model, and use it, 
so that is what I am doing.

BTW, I have seen/have a program that use PeekMessage extensively, as the 
primary GUI interface.  It does function, if properly manipulated.  Said 
program was not authored by me, however, so I don't feel I can 
distribute it... but I could give you a pointer to the author if you 
wish to ask him about it.


On approximately 12/4/2003 4:25 PM, came the following characters from
the keyboard of Steve Pick:
> Hello,
> 
> Here's a nice idea:
> 
> use Win32::GUI;
> my $win = new Win32::GUI::Window(
>     -name => "Test",
>     -left => 100,
>     -top => 100,
>     -width => 100,
>     -height => 100,
>     -onResize => \&Test_resize
> );
> 
> # Whenever we get WM_SETCURSOR, call perl sub setcursor with message
> parameters.
> $win->Hook(WM_SETCURSOR, \&setcursor);
> 
> # ... some code ...
> 
> # Reassign WM_SETCURSOR to go elsewhere
> 
> $win->Hook(WM_SETCURSOR, \&changecursorback);
> 
> # ... some more code ...
> 
> # Now reset WM_SETCURSOR to trigger DefWndProc().
> $win->UnHook(WM_SETCURSOR);
> 
> Since we can never implement all the events the user might wish to catch in
> the NEM, this method lets the user define when they want to catch a specific
> event and handle it in Perl, and when they want to finish their capture.
> This beats the hell out of using GetMessage (non-blocking, faster, simpler)
> and PeekMessage (peekmessage always seems to return nothing anyway).
> 
> What do you think? Should I implement this?
> 
> 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
> 
> 

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

Re: [perl-win32-gui-hackers] Proposition for NEM

[Steve P. <st...@ba...>]

Hi,

Glad you think it's a good idea, because it's implemented now. I THINK i've
stopped it crashing as well :) This is my first REAL bash at some new XS
code instead of just fixing C bugs. So the fact that it works is pretty
impressive. Anyway, it'll hit the CVS soon so keep your eyes peeled.

Steve

----- Original Message ----- 
From: "Glenn Linderman" <pe...@ne...>
To: "Steve Pick" <st...@ba...>
Cc: "Win32 GUI Hackers" <per...@li...>
Sent: Friday, December 05, 2003 2:26 AM
Subject: Re: [perl-win32-gui-hackers] Proposition for NEM


> Well, well, well.  Should I use the "great minds think alike" line?
>
> Or is this just so obviously a good idea that we both have thought of it?
>
> Clearly there are some well-defined events that need to have particular
> handling applied, and Win32::GUI needs to default to doing that handling.
>
> Clearly any event for which a handler exists, it would be nice to be
> able to override or supplement the default handling.  I suppose for full
> generality, the hooks should define whether they are "pre-default
> handling" hooks, or "post-default handling" hooks, but it seems that
> most things in Windows are set up so that only "pre-default handling
> hooks" are needed.  But I'm no Windows expert, so correct me here if I'm
> wrong.
>
> One of my most desired features for the NEM, other than getting the bugs
> and incompletenesses out of it, is the ability to obtain a reference to
> the "current handler", so that a new handler could be written to wrap
> the "current handler", or to substitute for it for a while, and then put
> it back.  Without that, NEM is not very extensible.
>
> And the idea of defining the events for which the user can define hooks,
> which is the gist of your message, is clearly the way to go for full
> capability.  It is not clear to me if such a handler should be placed in
> Win32::GUI::Dialog/DoEvents/etc., or in the MessageLoops code, probably
> the latter, but there are so many of them, and I don't even understand
> fully why there are so many of them.  So the former seems like a more
> central location!
>
> When I was contemplating finishing or replacing Win32::GUI since Aldo
> was "incognito" for an extended period, I considered discarding the
> MessageLoops stuff entirely, putting the hooks you suggest into Dialog,
> and discovering what else I didn't know, and how disastrous it would
> have been to do so... but I decided the shortest path to a working
> project would be to fix a few bugs in the old event model, and use it,
> so that is what I am doing.
>
> BTW, I have seen/have a program that use PeekMessage extensively, as the
> primary GUI interface.  It does function, if properly manipulated.  Said
> program was not authored by me, however, so I don't feel I can
> distribute it... but I could give you a pointer to the author if you
> wish to ask him about it.
>
>
> On approximately 12/4/2003 4:25 PM, came the following characters from
> the keyboard of Steve Pick:
> > Hello,
> >
> > Here's a nice idea:
> >
> > use Win32::GUI;
> > my $win = new Win32::GUI::Window(
> >     -name => "Test",
> >     -left => 100,
> >     -top => 100,
> >     -width => 100,
> >     -height => 100,
> >     -onResize => \&Test_resize
> > );
> >
> > # Whenever we get WM_SETCURSOR, call perl sub setcursor with message
> > parameters.
> > $win->Hook(WM_SETCURSOR, \&setcursor);
> >
> > # ... some code ...
> >
> > # Reassign WM_SETCURSOR to go elsewhere
> >
> > $win->Hook(WM_SETCURSOR, \&changecursorback);
> >
> > # ... some more code ...
> >
> > # Now reset WM_SETCURSOR to trigger DefWndProc().
> > $win->UnHook(WM_SETCURSOR);
> >
> > Since we can never implement all the events the user might wish to catch
in
> > the NEM, this method lets the user define when they want to catch a
specific
> > event and handle it in Perl, and when they want to finish their capture.
> > This beats the hell out of using GetMessage (non-blocking, faster,
simpler)
> > and PeekMessage (peekmessage always seems to return nothing anyway).
> >
> > What do you think? Should I implement this?
> >
> > 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
> >
> >
>
> -- 
> 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.
>
>

[perl-win32-gui-hackers] Proposition for NEM

[Steve P. <st...@ba...>]

Hello,

Here's a nice idea:

use Win32::GUI;
my $win = new Win32::GUI::Window(
    -name => "Test",
    -left => 100,
    -top => 100,
    -width => 100,
    -height => 100,
    -onResize => \&Test_resize
);

# Whenever we get WM_SETCURSOR, call perl sub setcursor with message
parameters.
$win->Hook(WM_SETCURSOR, \&setcursor);

# ... some code ...

# Reassign WM_SETCURSOR to go elsewhere

$win->Hook(WM_SETCURSOR, \&changecursorback);

# ... some more code ...

# Now reset WM_SETCURSOR to trigger DefWndProc().
$win->UnHook(WM_SETCURSOR);

Since we can never implement all the events the user might wish to catch in
the NEM, this method lets the user define when they want to catch a specific
event and handle it in Perl, and when they want to finish their capture.
This beats the hell out of using GetMessage (non-blocking, faster, simpler)
and PeekMessage (peekmessage always seems to return nothing anyway).

What do you think? Should I implement this?

Steve.

[perl-win32-gui-hackers] Thank You!

[Jeremy B. <jb...@dj...>]

I just wanted to send a big "Thank You" to all the Win32 GUI "Hackers".
I've been monitoring the mailing list for a long time now and while I'm
not currently using Win32-GUI for any projects (although I have in the
past), it's wonderful to see the activity after a long dry spell (no
offense to Aldo, I know what it's like trying to find time...).

I love the way Win32-GUI is setup, it's so much easier to understand
than Wx-Perl (although, one of these days, I'm going to learn it). =20

Anyway, I just wanted to say thank you and that your efforts are very
much appreciated.

Jeremy Blonde

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

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

Sorry, previous mail send unfinish

I have commit this :

+ [Laurent Rocher]
    - GUI.pm : Fix -prompt option for TextField, correct color option for
class (Win98SE).
    => Correct Label and Textfield position when use -prompt. Add support
for -pos and -size options.
    => For color class, i only remove +1 when COLOR_WINDOW.
    - GUI_Options.cpp : Correct -popstyle and -popexstyle like options.
    => Now popstyle only remove wanted style.
+ [Glenn Linderman] GUI_Options.cpp : Correct menu -enabled option.
    => Something i miss in previous pacth

Laurent.

[perl-win32-gui-hackers] [CVS Commit]

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

+ [Laurent Rocher]
 - GUI.pm : Fix -prompt option for TextField, correct color option for class
(Win98SE).
 - GUI_Options.cpp : Correct -popstyle and -popexstyle like options.
+ [Glenn Linderman] GUI_Options.cpp : Correct menu -enabled option.
----- Original Message ----- 
From: "Steve Pick" <st...@ba...>
To: "Win32 GUI Hackers" <per...@li...>
Sent: Wednesday, December 03, 2003 9:45 PM
Subject: [perl-win32-gui-hackers] [CVS Commit]


> In this exciting installment:
>
> Timers are now working in NEM mode. Create timers as normal. The onTimer
NEM
> event is triggered whenever any timer for the window ticks:
>
> my $win = new Win32::GUI::Window (
>     -name => "MainWin",
>     -top => 100, -left => 100, -width => 100, -height => 100,
>     -onTimer => \&timerEvent,
>     ...
> );
>
> $win->AddTimer("a_timer",1000);
> $win->AddTimer("another_timer",500);
>
> $win->Show();
>
> Win32::GUI::Dialog;
>
> sub timerEvent {
>     my($win, $timername) = @_;
>     print $timername." just ticked!\n";
> }
>
>
> ### Additions to changelog:
>
> GUI.h : Added PERLWIN32GUI_NEM_TIMER event.
> GUI.pm: fixed Win32::GUI::Class::new to avoid the "white background"
> syndrome on Windows 2000. Fixed conditional so that all operating systems
> with version above and including 5.1 have the no-white-background fix
> applicable to windows xp and up.
> GUI_MessageLoops.cpp: added WM_TIMER event to NEM_WindowMsgLoop, now NEM
> handler -onTimer will be called whenever a timer added to the window
> triggers. The NAME of the timer is provided as an argument to the handler.
> GUI_Options.cpp: Fix to allow -onTimer.
> GUI_Events.cpp: NEM Events always returned PerlResult of -2, even if a
> handler was found and called for the event. Now it returns 0 if everything
> was successful, as it should judging by the rest of the code.
>
>
>
> -------------------------------------------------------
> 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
>

[perl-win32-gui-hackers] [CVS Commit]

[Steve P. <st...@ba...>]

In this exciting installment:

Timers are now working in NEM mode. Create timers as normal. The onTimer NEM
event is triggered whenever any timer for the window ticks:

my $win = new Win32::GUI::Window (
    -name => "MainWin",
    -top => 100, -left => 100, -width => 100, -height => 100,
    -onTimer => \&timerEvent,
    ...
);

$win->AddTimer("a_timer",1000);
$win->AddTimer("another_timer",500);

$win->Show();

Win32::GUI::Dialog;

sub timerEvent {
    my($win, $timername) = @_;
    print $timername." just ticked!\n";
}


### Additions to changelog:

GUI.h : Added PERLWIN32GUI_NEM_TIMER event.
GUI.pm: fixed Win32::GUI::Class::new to avoid the "white background"
syndrome on Windows 2000. Fixed conditional so that all operating systems
with version above and including 5.1 have the no-white-background fix
applicable to windows xp and up.
GUI_MessageLoops.cpp: added WM_TIMER event to NEM_WindowMsgLoop, now NEM
handler -onTimer will be called whenever a timer added to the window
triggers. The NAME of the timer is provided as an argument to the handler.
GUI_Options.cpp: Fix to allow -onTimer.
GUI_Events.cpp: NEM Events always returned PerlResult of -2, even if a
handler was found and called for the event. Now it returns 0 if everything
was successful, as it should judging by the rest of the code.

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

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

On my Win98Se (major 4, minor 10).
COLOR_BTNFACE+1 and COLOR_WINDOW look to work well.
I have a grey background.

Laurent



> I will change this in the next commit.
> 
> Steve
> 
> > So then it really needs to read:
> >
> > if ( $major == 5 && $minor > 0  ||  $major > 5 )
> >
> > since Win2k is 5.0 and WinXP is 5.1 and who knows whether the next
> > incompatible upgrade to Windows will be called 5.2 or 6.0 or 8.3 ...
> >

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

[Steve P. <st...@ba...>]

I will change this in the next commit.

Steve

----- Original Message ----- 
From: "Glenn Linderman" <pe...@ne...>
To: "Aldo Calpini" <da...@pe...>
Cc: <per...@li...>; "Johan Lindstrom"
<jo...@ba...>; <per...@li...>
Sent: Wednesday, December 03, 2003 5:14 PM
Subject: Re: [perl-win32-gui-hackers] CVS Commit


> So then it really needs to read:
>
> if ( $major == 5 && $minor > 0  ||  $major > 5 )
>
> since Win2k is 5.0 and WinXP is 5.1 and who knows whether the next
> incompatible upgrade to Windows will be called 5.2 or 6.0 or 8.3 ...
>
>
> On approximately 12/3/2003 6:42 AM, came the following characters from
> the keyboard of Aldo Calpini:
> > Johan Lindstrom wrote:
> >
> >>Maybe it is just me, but the hardcoded $major == 5 (exactly 5) smells a
> >>little bit fragile.
> >
> >
> > heh. I don't know which COLOR_$@%!$# will be needed when $major will
> > be 6 :-)
> >
> > but yes, maybe it is safer to assume $major >= 5, thank you.
> >
> >
> > cheers,
> > Aldo
> >
> > __END__
> > $_=q,just perl,,s, , another ,,s,$, hacker,,print;
> >
> >
> >
> > -------------------------------------------------------
> > 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.
>
>
>
> -------------------------------------------------------
> 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
>

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

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

So then it really needs to read:

if ( $major == 5 && $minor > 0  ||  $major > 5 )

since Win2k is 5.0 and WinXP is 5.1 and who knows whether the next 
incompatible upgrade to Windows will be called 5.2 or 6.0 or 8.3 ...


On approximately 12/3/2003 6:42 AM, came the following characters from
the keyboard of Aldo Calpini:
> Johan Lindstrom wrote:
> 
>>Maybe it is just me, but the hardcoded $major == 5 (exactly 5) smells a
>>little bit fragile.
> 
> 
> heh. I don't know which COLOR_$@%!$# will be needed when $major will
> be 6 :-)
> 
> but yes, maybe it is safer to assume $major >= 5, thank you.
> 
> 
> cheers,
> Aldo
> 
> __END__
> $_=q,just perl,,s, , another ,,s,$, hacker,,print;
> 
> 
> 
> -------------------------------------------------------
> 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.

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

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

Johan Lindstrom wrote:
> Maybe it is just me, but the hardcoded $major == 5 (exactly 5) smells a
> little bit fragile.

heh. I don't know which COLOR_$@%!$# will be needed when $major will
be 6 :-)

but yes, maybe it is safer to assume $major >= 5, thank you.


cheers,
Aldo

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

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

[Johan L. <jo...@ba...>]

At 22:00 2003-12-02, Laurent ROCHER wrote:
>  # figure out the correct background color
>  # (to avoid the "white background" syndrome on XP)
>  if(not exists $args{-color}) {
>   my($undef, $major, $minor) = Win32::GetOSVersion();
>   if($major == 5 && $minor > 0) {
>    $args{-color} = Win32::GUI::constant("COLOR_BTNFACE", 0)+1;
>   } else {

Maybe it is just me, but the hardcoded $major == 5 (exactly 5) smells a 
little bit fragile.


/J

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

Latest bookmark: "Oracle 101"
http://www.rocket99.com/oracle/oracle12.html
dmoz: /Computers/Software/Databases/Oracle/ 212

Re: FIXES: [perl-win32-gui-hackers] CVS Commit

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

It's too late for me, i look this tomorrow ;o)

For your patch, a zip file like this it's not a problem (I use =
winmerge).

If you want to have CVS commit access, register a user on Sourceforge =
and send a mail to Aldo with your ID.
He give you developper access to Win32::GUI project.

Laurent.
  ----- Original Message -----=20
  From: Steve Pick=20
  To: Laurent ROCHER ; Win32 GUI Hackers=20
  Sent: Wednesday, December 03, 2003 12:15 AM
  Subject: FIXES: [perl-win32-gui-hackers] CVS Commit


  I have fixed the following bugs:

  1. Rehashed the way Win32::GUI::Class constructor detects xp or not. =
Removed the whole ELSE condition of that part that checks the OS =
version; it's not needed since if -color is not set, it's set to the =
correct color later on in the constructor.

  2. I was wrong about this one, I think.

  3. Timers don't work with NEM. I fixed it like so: You add timers as =
normal, but also create add an onTimer option to your window. When a =
timer triggers, onTimer is called with the string argument of the timer =
that triggered. Had to define a new NEM event in GUI.h to support this:

  #define PERLWIN32GUI_NEM_TIMER    0x08000000

  4. Looked into this, and made one change: DoEvent_NEM was always =
returning -2 (saying it hadnt handled the event) when it should have =
returned 0. Now if it finds an appropriate event, it sets perlresult to =
default to 0. Perlresult can still be overridden by an error or =
something after this setting.

  5. Exactly.

  My bugfixed version is available here: =
http://baxpace.com/Win32-GUI-Fix.zip

  The changes are scattered everywhere. If you have some kind of =
patch-generating program, that'd be a good idea. Patch relative to =
current CVS.

  Steve

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

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

> > 5.
> >     If -style need to be deprecated, i don't think it's a good idea to
> > a add -forcestyle.
> >     We keep -style without deprecated warning message.
> >     Or, we remove it and force people to use registered class for fix
> > a default style.
> >
> >     For me, -style don't need to be deprecated.
> >     It's a programmer choice (and supposed know what he's doing ;o).
> >     -popstyle/-pushstyle for set/reset a specific control style.
> >     -style are usefull for set a fixed style.
>
> There is also -addstyle and -remstyle, so really -style isn't that
> necessary.

It's do same job :

-addstyle == -pushstyle
-popstyle == -remstyle == -notstyle == -negstyle

from GUI_Options :

            } else if(strcmp(option, "-style") == 0) {
                next_i = i + 1;
                perlcs->cs.style = (DWORD) SvIV(ST(next_i));
                if(PL_dowarn) {
                    warn("Win32::GUI: the -style option is deprecated!");
                }
            } else if(strcmp(option, "-pushstyle") == 0
            ||        strcmp(option, "-addstyle") == 0) {
                next_i = i + 1;
                perlcs->cs.style |= (DWORD) SvIV(ST(next_i));
            } else if(strcmp(option, "-popstyle") == 0
            ||        strcmp(option, "-remstyle") == 0
            ||        strcmp(option, "-notstyle") == 0
            ||        strcmp(option, "-negstyle") == 0) {
                next_i = i + 1;
                perlcs->cs.style ^= (DWORD) SvIV(ST(next_i));

I think we have a bug on -remstyle like options.
If you remove a style not set, you push it !!!!

#perl
# remstyle on a set style
$var = 1;
$var ^=  1;
print "$var\n";      # print 0 OK

# remstyle on a not set style
$var = 2;
$var ^=  1;
print "$var\n";      # print 3 Wrong !!!

# correct remstyle
$var = 3;
$var &=  $var ^ 1;
print "$var\n";     # print 2 OK

So if we correct this, and use a -remstyle => 0xFFFFFFFF and a -addstyle
this work like -style option.

$W->AddLabel(
    -text    => 'Hello, world',
    -name    => 'Hello',
    -left    => 25,
    -top     => 25,
    -remstyle => 0xFFFFFFFF,
    -addstyle => WS_VISIBLE | WS_CHILD | SS_CENTER;
);

I don't know if it's possible to have an order parse options problem.
But, it's not very nice. -style option is better.

-style option have is avantage than others -*style options haven't (and
reverse is true).
It's why i think it's not need to be deprecated (actually warm message and
probably remove in futur version).
So, keep both and use as appropriate ;o)

Laurent.

FIXES: [perl-win32-gui-hackers] CVS Commit

[Steve P. <st...@ba...>]

I have fixed the following bugs:

1. Rehashed the way Win32::GUI::Class constructor detects xp or not. =
Removed the whole ELSE condition of that part that checks the OS =
version; it's not needed since if -color is not set, it's set to the =
correct color later on in the constructor.

2. I was wrong about this one, I think.

3. Timers don't work with NEM. I fixed it like so: You add timers as =
normal, but also create add an onTimer option to your window. When a =
timer triggers, onTimer is called with the string argument of the timer =
that triggered. Had to define a new NEM event in GUI.h to support this:

#define PERLWIN32GUI_NEM_TIMER    0x08000000

4. Looked into this, and made one change: DoEvent_NEM was always =
returning -2 (saying it hadnt handled the event) when it should have =
returned 0. Now if it finds an appropriate event, it sets perlresult to =
default to 0. Perlresult can still be overridden by an error or =
something after this setting.

5. Exactly.

My bugfixed version is available here: =
http://baxpace.com/Win32-GUI-Fix.zip

The changes are scattered everywhere. If you have some kind of =
patch-generating program, that'd be a good idea. Patch relative to =
current CVS.

Steve

  ----- Original Message -----=20
  From: Laurent ROCHER=20
  To: Win32 GUI Hackers=20
  Sent: Tuesday, December 02, 2003 9:00 PM
  Subject: Re: [perl-win32-gui-hackers] CVS Commit


  Hi,


  1.=20
     =20
      Aldo make a change in GUI.pm for correct XP color but don't work =
for me on Win98Se.

  In Win32::GUI::Class new

   # figure out the correct background color=20
   # (to avoid the "white background" syndrome on XP)
   if(not exists $args{-color}) {
    my($undef, $major, $minor) =3D Win32::GetOSVersion();
    if($major =3D=3D 5 && $minor > 0) {  =20
     $args{-color} =3D Win32::GUI::constant("COLOR_BTNFACE", 0)+1;
    } else {
     $args{-color} =3D Win32::GUI::constant("COLOR_WINDOW", 0)+1;
    }
   }

      I remove red +1 and now it's correct for me.

  2. 3. 4.
      New bug to investigate ;o)

  5.=20
      If -style need to be deprecated, i don't think it's a good idea to =
a add -forcestyle.
      We keep -style without deprecated warning message.=20
      Or, we remove it and force people to use registered class for fix =
a default style.

      For me, -style don't need to be deprecated.
      It's a programmer choice (and supposed know what he's doing ;o).
      -popstyle/-pushstyle for set/reset a specific control style.
      -style are usefull for set a fixed style.=20

  Laurent.
    ----- Original Message -----=20


    Hello.

    I'm going to look into this list of bugs to see what I can fix, but =
I'm quite sure none of them are to do with my patches :) and maybe you =
have some answers:

    1. Default DialogBox background is white on Windows 2000, rather =
than the correct colour for a buttonface/3dface. I assume this is known =
because it's blatantly obvious.

    2. NEM event onResize seems to be called in the constructor for =
Windows and possibly all other widgets. This is very frustrating because =
if you use onResize to handle your scaling, then often it tries to scale =
widgets that have not yet been defined, causing an error.=20

    3. Timers no longer seem to work as documented. In fact they don't =
work at all (for me). This could be something that only manifests itself =
when the NEM is used, but I haven't tested that.

    4. NEM events seem to be triggered tons of times. For example when I =
click a mouse button I get about 60 onMouseDown calls.

    5. There are times when -style is appropriate. I admit that -style =
SHOULD be deprecated, but there should be a new argument such as =
-forcestyle for when you know what you're doing. I can see that default =
styles could be changed in future, and hardcoding -popstyle for each =
default style seems rather crude to me.

    Steve

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

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

On approximately 12/2/2003 1:00 PM, came the following characters from
the keyboard of Laurent ROCHER:

> 5.
>     If -style need to be deprecated, i don't think it's a good idea to 
> a add -forcestyle.
>     We keep -style without deprecated warning message.
>     Or, we remove it and force people to use registered class for fix 
> a default style.
>  
>     For me, -style don't need to be deprecated.
>     It's a programmer choice (and supposed know what he's doing ;o).
>     -popstyle/-pushstyle for set/reset a specific control style.
>     -style are usefull for set a fixed style. 

There is also -addstyle and -remstyle, so really -style isn't that 
necessary.

>  
> Laurent.
> 
>     ----- Original Message -----
> 
>     Hello.
>      
>     I'm going to look into this list of bugs to see what I can fix, but
>     I'm quite sure none of them are to do with my patches :) and maybe
>     you have some answers:
>      
>     1. Default DialogBox background is white on Windows 2000, rather
>     than the correct colour for a buttonface/3dface. I assume this is
>     known because it's blatantly obvious.
>      
>     2. NEM event onResize seems to be called in the constructor for
>     Windows and possibly all other widgets. This is very frustrating
>     because if you use onResize to handle your scaling, then often it
>     tries to scale widgets that have not yet been defined, causing an
>     error.
>      
>     3. Timers no longer seem to work as documented. In fact they don't
>     work at all (for me). This could be something that only manifests
>     itself when the NEM is used, but I haven't tested that.
>      
>     4. NEM events seem to be triggered tons of times. For example when I
>     click a mouse button I get about 60 onMouseDown calls.
>      
>     5. There are times when -style is appropriate. I admit that -style
>     SHOULD be deprecated, but there should be a new argument such as
>     -forcestyle for when you know what you're doing. I can see that
>     default styles could be changed in future, and hardcoding -popstyle
>     for each default style seems rather crude to me.
>      
>     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.