From: Steve P. <st...@ba...> - 2004-01-08 01:33:45
|
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 st...@ba... |