> Is there any plans to support more event types? E.g.
> keyboard events. Then
> we might handle the TAB in our callbacks for a Window. Not an ideal
> solution. I'd rather use events for more creative stuff.
a) there are plans to come up with a whole new, extensible event model.
We're all eagerly awaiting the release :-)
b) for quite a number of new events, you have to use classes (see below).
Exactly what events which class gives you should be documented somewhere ...
maybe around here ... or was it there ... erm ... I'm sure I had it l8ly ...
:-/
Okay, if you dwell into gui.xs, around line 4100 you can see which classes
there are:
Button, Listbox, TabStrip, RichEdit, Graphic, InteractiveGraphic, Splitter
and SplitterH.
I don't know too much about it, but I vaguely remember that if you use
Graphic or InteractiveGraphic, you have to provide a paint method, which is
probably more than you want to do. The Splitter classes also might not be
too useful. If you search the xs file for "msgloop" and look at the other
classes, you will find that "button" and "listbox" give you MouseMove,
whereas RichEdit gives you MouseMove, LButtonDown, LButtonUp, RButtonDown
and RButtonUp. There's no restriction to not using a richedit class with
buttons, I tried that and it works just fine.
Here's how:
new Win32::GUI::Class
(
-name => '_Button',
-widget => 'Button', # use RichEdit if you want more than
MouseMove
-extends => 'Button', # which control type you're gonna use
);
$Main->AddButton
(
-name => 'Belly',
-text => 'Clickme',
-class => '_Button',
);
sub Belly_MouseMove # now we're talking
{
print join (', ', @_), "\n";
}
