Events
Events always belong to a particular widget.
To which widget events are actually directed
depends upon
whether the programmer has defined a binding for the
event type.
When such a binding exists for a widget
and the (toolkit) environment decides that
the event belongs to that widget, then the callback
associated with that event is executed.
Information concerning the event may be retrieved
by asking the kit for the latest event.
\slide{class-event}{The event class}{
interface event { \fbox{event}
int type(); \c{ X event type }
char* name(); \c{type as string}
int x();
int y();
...
void* rawevent(); \c{delivers} raw X event
};
}{
interface event { \fbox{event}
int type(); \c{// X event type }
char* name(); \c{// type as string}
int x();
int y();
int button(int i = 0); \c{// ButtonPress}
int buttonup(int i = 0); \c{// ButtonRelease}
int motion(); \c{// MotionNotify}
int keyevent(); \c{// KeyPress or KeyRelease}
int buttonevent(int i = 0); \c{// ButtonPress or Release}
int keycode();
void trace(); \c{// prints event information}
void* rawevent(); // \c{delivers} raw X event
};
}
}
Event objects represent the events generated by
the X-window system.
Each event has a type.
The type of the event can be inspected with which
returns an integer value or which returns
a string representation of the type.
For some of the common event types, such as ButtonPress,
ButtonRelease and MotionNotify, member functions
are provided to facilitate testing.
If an integer argument (1, 2 or 3) is given to button,
buttonup or buttonevent, it is checked whether
the event has occurred for the corresponding button.
The functions x and y deliver the widget
coordinates of the event, if appropriate.
Calling trace for the event results in printing
the type and coordinate information for the event.
When setting the level to 2 this
information is automatically printed.
Programmers not satisfied with this interface can
check the type and access the underlying XEvent at their
own risk.