On approximately 3/30/2004 12:14 PM, came the following characters from
the keyboard of Laurent ROCHER:
Hi,
I commit new Accelerator event handling.
- GUI.h :
+ Add FindChildWindowsProc prototype and search typedef struct.
- GUI_Events.cpp :
+ Rewrite DoEvent_Accelerator.
- GUI_Helpers.cpp :
+ Add FindChildWindowsProc for search a child with specific name.
Sounds good.
2) if accelerator define like : "Key" => "Name"
- Find a window called "Name" in current window hierarchy and
call -onClick event if exist with Window Self .
- Call Window -onClick event if exist with Self + Name (-acc is
availlable
only for Window and Dialog so Click event isn't use for specific stuff).
Yes, -accel is only available for those two, but I could imagine other
uses for Click event on the "white space" of a parent window. So that
is why I suggested making a new "Accel" event, so one could specify
-onAccel => sub {...}
Actually, i keep Click because :
- I win an NEM event flag ;o)
- For Click event on the "white space", it's not standard window event.
And, i think it's more application implementation to use KeyDown event
and check white space.
- We can reuse Click event for menu (like Jez suggest) (so accelerator
and menu call same method).
When your menu is "text" => "name" like in OEM.
We can call Window -click event if we can't found a OEM event
handler.
But of course it's easy to change.
OK, I'm no expert in what is standard window event, so that sounds
reasonable, given the availability of KeyDown on window.
So is it implemented that menus without -onClick events will call Window
-onClick? If not, this isn't a very good reason, and I'm not fond of
the idea, but I can see it would be slightly handy.
So it occurred to me this morning that if we are going this route, that
Buttons without -onClick should also fall into the Window -onClick.
I'm not fond of the idea because the Window -onClick, winds up having to
handle lots of events, so has to include a "dispatcher" or "switch
statement" to do so... and inside GUI, if -onClick is specified for all
the individual events, the dispatching can be done in C code instead of
Perl code, which should be faster.
I can see the "convenience" of writing one humongous function to handle
all of Accelerators, Menus, and Buttons, with the same code regardless
of which way an operation is invoked... but it suffers in performance,
and I am somewhat negative about encouraging that.
Specifying -onClick => sub { ... } allows the dispatch to happen in
C, and if the ... is simply { & my_sprongle_handler() } that is fine to
handle either the sprongle button, the accelerator key for sprongle, or
the Tools / Sprongle menu entry. So you have 3 dinky wrapper
functions... or you could specify -onClick => \& my_sprongle_handler
if there is no need to distinguish between which way the handler was
invoked.
But I can't complain too much, because both technique will be available
for use.
- Check for OEM Name_Click and call it if exist.
This last would only be done for OEM mode, and BOTH mode, I presume.
Actually, i call it, only if haven't find a named child window or named
child window is OEM/BOTH.
I can call Unknow_Click method like in OEM (for compatibility).
Ah. OK.
--
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.
