perl-win32-gui-hackers

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

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

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;