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