Hi,
OK let me introduce Hooks to those in Win32::GUI::Users who may have missed its
introduction.
The Hacker Event Model / Hook Event Model / HEM allows you to define one or
more Perl handlers for any window message, window command or notification. When
your application receives a message that you have defined a hook for,
Win32::GUI will call your Perl hook handlers.
The upshot of this is that you can now catch any Win32 API message, instead of
just the ones that Win32::GUI knows about.
Here is a quick example or two. Note that the constants used below may not be
exported by Win32::GUI at this time, so it's worth discovering their values
from WinUser.h, otherwise things won't work.
# Add a hook for WM_MOVE in the main window.
$window->Hook(WM_MOVE, \&windowmoved);
sub windowmoved {
my($widget, $wparam, $lparam, $type, $msg) = @_;
# The message should not be from WM_COMMAND or WM_NOTIFY:
if($type != 0) { return };
print "Window moved!";
$widget->Text("You moved me");
}
# Add a hook for BN_CLICKED on a button.
my $coderef = sub {
if($_[3] != WM_COMMAND) {return};
print "Button clicked!\n";
};
$button->Hook(BN_CLICKED, $coderef);
# Add another hook for BN_CLICKED on the same button.
my $coderef2 = sub {
if($_[3] != WM_COMMAND) {return};
print "This is the second hook handler!\n";
};
$button->Hook(BN_CLICKED, $coderef2);
# Remove a specific hook handler from the button for
# a particular event:
$button->UnHook(BN_CLICKED, $coderef);
# Remove all the hooks for a particular event (BAD PRACTICE).
$button->UnHook(BN_CLICKED);
All in all, hooks save you a lot of trouble with nasty GetMessage()/PeekMessage
loops and allow pretty much unlimited freedom. They were originally conceived
as a way for modules that act as wrappers around widgets to unobtrusively
capture events from the widget they wrapped, and to allow you to modify your
handlers at any point in your code (normally, all the NEM handlers were forced
to be defined when you created the object).
I hope that sort of explained something. Anyway, the current version is in the
CVS under the 665-Fix branch. The documentation is inline in GUI.xs but I'm
sure someone will update the main docs again soon....
Steve
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Frazier, Joe Jr
> Sent: 08 January 2004 12:23
> To: Steve Pick; Win32 GUI Users
> Subject: RE: [perl-win32-gui-users] CVS commit
>
>
> Steve, can you demonstrate the use of this and what this is
> for, because I am not quite following the whole thread. Is
> this a way to get controls to fire event handlers which were
> previously not available for that control?
>
> Joe Frazier, Jr.
> Technical Support Engineer
> Peopleclick Service Support
>
> Tel: +1-800-841-2365
> E-Mail: mailto:[EMAIL PROTECTED]
>
>
> > -----Original Message-----
> > From: Steve Pick [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, January 07, 2004 8:34 PM
> > To: Win32 GUI Users; Win32 GUI Hackers
> > Subject: [perl-win32-gui-users] CVS commit
> >
> >
> > Hi,
> >
> > I've committed the updated hooks code in 665-Fix. See GUI.xs for the
> > documentation for the Hook and UnHook functions.
> >
> > What's new:
> >
> > Hooks work in Old Event Model and New Event Model
> > You can hook WM_COMMAND and WM_NOTIFY submessages if you call
> > Hook on a
> > child widget (like a button, for example)
> > You can now add multiple hooks for each message. Calling
> > Hook(MSG, CODEREF)
> > no longer replaces the current handler returning the old
> > handler for that
> > hook (which didnt work properly anyway) but adds another
> > handler for the
> > specified message. Returns true if adding succeeded or
> false otherwise
> > (normally if it returns false then the hook has already
> been defined).
> >
> > When removing hooks they are identified by coderef, so this
> is WRONG:
> >
> > $win->Hook(WM_MOVE, sub { print "moved!" });
> > $win->UnHook(WM_MOVE, sub { print "moved!" });
> >
> > In that case, UnHook will return false and the hook will not
> > be removed
> > because the codref passed to the UnHook call will be
> > different to the one
> > passed to Hook. You should do it like this:
> >
> > $movedsub = sub { print "moved!\n" };
> > $win->Hook(WM_MOVE, $movedsub);
> > $win->UnHook(WM_MOVE, $movedsub);
> >
> > Some more arguments have been added to the handler callbacks.
> > These are
> > $type and $msg. $msg is simply the code for the message that
> > triggered the
> > hook, and $type is 0 for normal window message, WM_NOTIFY for
> > WM_NOTIFY
> > messages, and WM_COMMAND for WM_COMMAND messages. $type is
> > there because
> > often WM_COMMAND submessages, WM_NOTIFY submessages and
> > normal messages can
> > conflict so it's good to check if your handler has been
> called by the
> > correct type of message. Yes this is a nasty kludge, but i
> > chose it because
> > all the other options would have taken too long to get right
> > or would have
> > been less intuitive.
> >
> > Doing UnHook() inside a hook handler seems to be safe
> (after a lot of
> > bugfixing and tweaks to make it safe), but if you find any
> > problems (usually
> > crashes) with this kind of thing let me know.
> >
> > Steve Pick
> > [EMAIL PROTECTED]
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Perforce Software.
> > Perforce is the Fast Software Configuration Management
> System offering
> > advanced branching capabilities and atomic changes on 50+ platforms.
> > Free Eval! http://www.perforce.com/perforce/loadprog.html
> > _______________________________________________
> > Perl-Win32-GUI-Users mailing list
> > Perl-Win32-GUI-Users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> >
> >
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>
