The approach is workable, but it
1) isn't as easily portable from OEM accelerators, which I think is
useful to preserve.
2) a single handler is forced to "couple" the code for widely disparate
events, which isn't always the easiest to maintain... and you often wind
up with a haandler that has an extra switch statement in it to further
dispatch the event. The OEM accelerator model caused the dispatch of
the exact, already defined widget_Click event, allowing accelerators to
be handled without writing any additional code, which is a great
timesaver for adding many simple accelerators in many applications,
which I think should be preserved.
3) As I outlined in my previous message, some extensions could be made
to accelerators. If all accelerator keys are mapped to names that do
not have widgets, then you do wind up with the option of handling all
accelerators in a single handler, if that method appeals to you and/or
is an appropriate technique for particular applications.
Regarding handling menus via a single handler. I have the same concerns
that for many applications that adds an extra switch statement, and
couples disparate lines of code. And the implementation in Windows and
Win32::GUI for menus and accelerators is quite different, although that
alone shouldn't stop us from giving a unified interface if it makes
sense, isn't too hard, and is seen as desirable for some applications.
So what is the essence of a menu? And how are they different from
accelerators?
An accelerator is:
"key" => "name" (or possibly, by enhancement, "key" => sub {...} )
A menu is
"text" => "name" # OEM
"text" => { -name => "name, -onClick => sub {...}, } # NEM
The "text" part can also have flags which encode a level of hierarchy,
and some geometry (separators and columnization at least) specifications.
For OEM, we have the _Click event available, and if the name_Click
function exists it is called when the menu item is selected. So indeed,
the action part of the activity is very similar to accelerators, but
under the covers, there is a collection of Windows data structures
created, that are not created for accelarators... but this is mostly for
the user interface differences between menus and accelerators.
For NEM, while it isn't presently implemented, one could envision that
other events could be defined for menu items.... at least a RightClick
event could be envisioned, possibly also GotFocus/LostFocus, DblClick,
DblRightClick, maybe others). If this sort of extension would be made,
which I think would be useful (note that Windows differentiates clicking
and right clicking on Start menu items, among other things), then the
vision of accelerators and menus as being fairly similar starts to break
down.... there is no possibility of RightClick-ing an accelerator :)
And there could be a richer event model for menus than a simple, single,
Click event. And I would doubt that handling a richer event model for
menus would appropriately be done by a single handler in most applications.
On approximately 3/29/2004 2:30 AM, came the following characters from
the keyboard of Jez White:
My 2 cents worth. I *really* like this approach. The idea of one handler is
much cleaner and simpler, especially when you have many items in the table.
Going one step further I'd like to see the same kind of approach taken for
menus!
cheers,
jez.
----- Original Message -----
From: "Laurent ROCHER" <[EMAIL PROTECTED]>
To: "Win32 GUI Hackers" <perl-win32-gui-hackers@lists.sourceforge.net>
Sent: Sunday, March 28, 2004 8:56 PM
Subject: Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS.
Hi,
Some small bug fix :
- UpDown :
+ Fix Scroll event.
- GUI_Events.cpp :
+ In DoEvent_* functions : PERLWIN32GUI_EVENTHANDLING is set after
event call.
I looking for NEM support for accelerator and i don't know if my current
implementation was good.
If you look in sample below, you see it's always call -onClick window
event
with accelerator name but not call button click event like in OEM.
For NEM support it's probably nicer to call Button click method like OEM
do.
What do you think ?
Laurent.
use Win32::GUI;
my $acc = new Win32::GUI::AcceleratorTable(
"A" => "Window",
"B" => "Button",
);
$W = new Win32::GUI::Window(
-name => "Window",
-title => "test",
-pos => [100, 100],
-size => [280, 280],
-accel => $acc,
# NEM call comment for OEM.
-onClick => sub { my ($self, $name) = @_; print "Window OnClick :
$name\n"; },
);
$W->AddButton(
-name => "Button",
-pos => [5, 5],
-size => [100, 100],
-text => "Just button",
);
$W->Show;
Win32::GUI::Dialog();
# OEM call
sub Window_Click {
print "Window_Click\n";
}
sub Button_Click {
print "Button_Click\n";
}
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Perl-Win32-GUI-Hackers mailing list
Perl-Win32-GUI-Hackers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Perl-Win32-GUI-Hackers mailing list
Perl-Win32-GUI-Hackers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
--
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.
