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]
