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... |
From: Steve P. <st...@ba...> - 2004-01-13 18:25:53
|
Hi, In this update: - GUI.xs : Made ProgressBar aware of -foreground and -background colour settings Example: my $progressbar = new Win32::GUI::ProgressBar($mainwindow, -name => "PB1", -left => 0, -top => 0, -width => 100, -height => 20, -foreground => [255,0,0], # Red. Can also use a color object as normal -background => [0,0,0], # Black. ); $progressbar->Change(-foreground => [80,80,80]); # Change bar colour to grey. $progressbar->Change(-background => [0,80,80]); # Change background colour to slate. - GUI.xs : Added Result(handle, code) call for explicitly setting the returned LRESULT from a handler. (normally the value returned from Perl handlers was not returned from their calling wndproc, this allows you to specify a result that will be returned.) Example: my notifyhandler { my $object = shift; $object->Result(20); # set the value we should return to Windows to be 20. return 0; } See the API documentation on msdn.microsoft.com for valid values to return on particular messages. This feature is most useful for responding to the various WM_NOTIFY and WM_COMMAND messages. - GUI_MessageLoops.cpp : If CommonMsgLoop must be called then it is called before any Hook handlers are called. You will probably not notice a difference with this change. Basically it means that any events that were previously processed AFTER the hooks were called are now done BEFORE the hooks are called. The most significant advantage of this is that you can now hook WM_PAINT and do all your client-area drawing there (previously, any drawing you did was erased immediately). Any problems, mail the list. Any suggestions, bug reports or feature requests, please use: http://sourceforge.net/tracker/?group_id=16572 Thank you and good night :) Steve |
From: Steve P. <st...@ba...> - 2004-01-25 01:47:47
|
In this commit: AbsLeft and AbsTop now can take arguments: AbsLeft(10) sets the absolute left co-ordinate of a window to 10 pixels, for example. GetEvent(name) will return the coderef for the specified NEM event handler. "name" should be an event name like "Resize". SetEvent(name, handler) will set the coderef for the specified NEM event handler. "name" should be an event name, and "handler" should be a code reference to a subroutine that will handle the event. You can use this to change event handlers to something else if you need to. Steve. |
From: Glenn L. <pe...@ne...> - 2004-05-17 20:32:57
|
+ [Glenn Linderman] : Fix GetOpenFileName - GUI.h: + change VERSION - GUI.xs: + change GetOpenFileName to support -multisel => N, where N is multiplied by 4000 to obtain the results buffer size. The minimum results buffer size is 256 for N <= 0, and 4000 for N == 1. -- Glenn -- http://nevcal.com/ =========================== The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing. |
From: Glenn L. <pe...@ne...> - 2004-01-08 02:04:45
|
On approximately 1/7/2004 5:33 PM, came the following characters from the keyboard of Steve Pick: > 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 Thanks. The above should let me catch WM_MENUCHAR messages, which are needed in order to handle keystrokes that are not simple alphanumerics, when displaying menus. Eventually. When I get to it. -- Glenn -- http://nevcal.com/ =========================== The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing. |
From: Johan L. <johanl@DarSerMan.com> - 2004-01-08 19:35:28
|
At 02:33 2004-01-08, Steve Pick wrote: >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); I'm sorry but, from the outside, doesn't this seem slightly illogical? What happens if you do: $win->Hook(WM_MOVE, $mysub); $win->Hook(WM_MOVE, $myothersub); or even using the same handler for two windows: $win->Hook(WM_MOVE, $mysub); $win2->Hook(WM_MOVE, $mysub); Would that result in weirdness? Would it not be more logical to key the hook by the $win and the message (WM_MOVE) rather than the handler coderef? 1) No strange semantics. 2) No need to remember what I happened to hook it with. Or is it just me? :) /J -------- ------ ---- --- -- -- -- - - - - - Johan Lindström Sourcerer @ Boss Casinos johanl@DarSerMan.se Latest bookmark: "Open Text Summarizer" http://libots.sourceforge.net/ dmoz (1 of 6): /Computers/Software/Operating_Systems/Linux/ 9 |
From: Steve P. <st...@ba...> - 2004-01-08 19:59:16
|
Hi, > >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); > > I'm sorry but, from the outside, doesn't this seem slightly illogical? No? From what you wrote below there might be some misunderstanding here... > What happens if you do: > $win->Hook(WM_MOVE, $mysub); > $win->Hook(WM_MOVE, $myothersub); Two hooks are assigned. When $win receives WM_MOVE, $mysub is called, then $myothersub is called. > or even using the same handler for two windows: > $win->Hook(WM_MOVE, $mysub); > $win2->Hook(WM_MOVE, $mysub); > Would that result in weirdness? No, when $win receives WM_MOVE, $mysub is called. when $win2 receives WM_MOVE, $mysub is called. Hooklists are per-object. It works as you would expect. If you want to remove $mysub handler from $win2, you'd do $win2->UnHook(WM_MOVE,$mysub); - literally "remove the $mysub handler from $win2's list of handlers for WM_MOVE". > Would it not be more logical to key the hook by the $win and the message > (WM_MOVE) rather than the handler coderef? No. The hook is ALREADY keyed by the $win, we're (pseudo) object oriented here. There is an individual array of handlers for every message for every window/widget. This is to allow you to add several hooks to ONE message in a specific window. The advantages of this include: 1) 3rd party modules can get a window object passed to them and assign and unassign their own hooks without breaking the users own hooks, since every hook you remove is identified by the coderef of the handler, there is no possibility that a 3rd party module could accidentally remove one of the users own hooks. 2) You can temporarilly make one window message call an additional handler, without first having to remove the original handler and re-add the original handler afterwards. 3) It's just generally versatile. Also, the semantics are not strange if you do something like this: $win->Hook(WM_MOVE,\&handler); $win->UnHook(WM_MOVE,\&handler); since \&handler always returns a coderef of the same value. Hope that helps, Steve |
From: Johan L. <johanl@DarSerMan.com> - 2004-01-08 20:06:23
|
At 20:59 2004-01-08, Steve Pick wrote: > > What happens if you do: > > $win->Hook(WM_MOVE, $mysub); > > $win->Hook(WM_MOVE, $myothersub); > >Two hooks are assigned. When $win receives WM_MOVE, $mysub is called, then >$myothersub is called. Ah, that accounts for my confusion. The solution was more clever than I expected, not less :) /J -------- ------ ---- --- -- -- -- - - - - - Johan Lindström Sourcerer @ Boss Casinos johanl@DarSerMan.se Latest bookmark: "Open Text Summarizer" http://libots.sourceforge.net/ dmoz (1 of 6): /Computers/Software/Operating_Systems/Linux/ 9 |