|<< Prev||- Up -||Next >>|
An event pattern may take one of two forms. In the simplest case it is a single printing ASCII character, such as a or [. The character may not be a space character or the character
<. This form of pattern matches a
KeyPress event for the particular character. The second form of pattern is longer but more general. It is a virtual string of the form:
The entire event pattern is surrounded by angle brackets. Inside the angle brackets are zero or more modifiers, an event type, and an extra piece of information (detail) identifying a particular button or keysym. Any of the fields may be omitted, as long as at least one of type and detail is present. The fields must be separated by white space or dashes.
Modifiers consist of any of the following values:
Where more than one value is listed, separated by commas, the values are equivalent. Most of the modifiers have the obvious X meanings. For example,
Button1 requires that button 1 be depressed when the event occurs. For a binding to match a given event, the modifiers in the event must include all of those specified in the event pattern. An event may also contain additional modifiers not specified in the binding. For example, if button 1 is pressed while the shift and control keys are down, the pattern
<Control-Button-1> will match the event, but
<Mod1-Button-1> will not. If no modifiers are specified, then any combination of modifiers may be present in the event.
M refer to whichever of the
M5 modifiers is associated with the meta key(s) on the keyboard (keysyms
Meta_L). If there are no meta keys, or if they are not associated with any modifiers, then
M will not match any events. Similarly, the
Alt modifier refers to whichever modifier is associated with the alt key(s) on the keyboard (keysyms
Quadruple modifiers are a convenience for specifying double mouse clicks and other repeated events. They cause a particular event pattern to be repeated 2, 3 or 4 times, and also place a time and space requirement on the sequence: for a sequence of events to match a
Quadruple pattern, all of the events must occur close together in time and without substantial mouse motion in between. For example,
<Double-Button-1> is equivalent to
<Button-1><Button-1> with the extra time and space requirement.
The type field may be any of the standard X event types, with a few extra abbreviations. The type field will also accept a couple non-standard X event types that were added to better support the Macintosh and Windows platforms. Below is a list of all the valid types; where two names appear together, they are synonyms.
Most of the above events have the same fields and behaviors as events in the X Windowing system. You can find more detailed descriptions of these events in any X window programming book. A couple of the events are extensions to the X event system to support features unique to the Macintosh and Windows platforms. We provide a little more detail on these events here. These include:
Deactivate: These two events are sent to every sub-window of a toplevel when they change state. In addition to the focus Window, the Macintosh platform and Windows platforms have a notion of an active window (which often has but is not required to have the focus). On the Macintosh, widgets in the active window have a different appearance than widgets in deactive windows. The Activate event is sent to all the sub-windows in a toplevel when it changes from being deactive to active. Likewise, the Deactive event is sent when the window's state changes from active to deactive. There are no useful percent substitutions you would make when binding to these events.
MouseWheel: Some mice on the Windows platform support a mouse wheel which is used for scrolling documents without using the scrollbars. By rolling the wheel, the system will generate MouseWheel events that the application can use to scroll. Like Key events the event is always routed to the window that currently has focus. When the event is received you can use the
D substitution to get the delta field for the event that is an integer value of motion that the mouse wheel has moved. The smallest value for which the system will report is defined by the OS. On Windows 95 & 98 machines this value is at least 120 before it is reported. However, higher resolution devices may be available in the future. The sign of the value determines which direction your widget should scroll. Positive values should scroll up and negative values should scroll down.
The last part of a long event specification is detail. In the case of a
ButtonRelease event, it is the number of a button (1-5). If a button number is given, then only an event on that particular button will match; if no button number is given, then an event on any button will match. Note: giving a specific button number is different than specifying a button modifier; in the first case, it refers to a button being pressed or released, while in the second it refers to some other button that is already depressed when the matching event occurs. If a button number is given then type may be omitted: if will default to
ButtonPress. For example, the specifier
<1> is equivalent to
If the event type is
KeyRelease, then detail may be specified in the form of an X keysym. Keysyms are textual specifications for particular keys on the keyboard; they include all the alphanumeric ASCII characters (e.g.
"a" is the keysym for the ASCII character
a), plus descriptions for non-alphanumeric characters (
"comma" is the keysym for the comma character), plus descriptions for all the non-ASCII keys on the keyboard (
"Shift_L" is the keysm for the left shift key, and
"F1" is the keysym for the F1 function key, if it exists). The complete list of keysyms is not presented here; it is available in other X documentation and may vary from system to system. If necessary, you can use the
"K" notation described below to print out the keysym name for a particular key. If a keysym detail is given, then the type field may be omitted; it will default to
"KeyPress". For example,
<Control-comma> is equivalent to
args option of the
bind method takes a list of argument specifications. An argument specification describes the type of the argument and the argument itself. Figure 8.1 shows the valid types. Actual types used are the trivial mapping from the specified type. When the event is raised, all specified arguments are appended to the
action to execute in the order they appear in the list. Below is a list of all the valid arguments; where two names appear together, they are synonyms.
b: The number of the button that was pressed or released. Valid only for
c: The count field from the event. Valid only for
d: The detail field from the event. For
FocusOut events, the returned string will be one of the following:
For events other than these, the substituted string is undefined.
f: The focus field from the event (0 or 1). Valid only for
h: The height field from the event. Valid for the
k: The keycode field from the event. Valid only for
m: The mode field from the event. The substituted string is one of
NotifyWhileGrabbed. Valid only for
o: The override_redirect field from the event. Valid only for
p: The place field from the event, substituted as one of the strings
PlaceOnBottom. Valid only for
s: The state field from the event. For
Motion events, a decimal string is substituted. For Visibility, one of the strings
VisibilityFullyObscured is substituted.
t: The time field from the event. Valid only for events that contain a time field.
w: The width field from the event. Valid only for
x: The x field from the event. Valid only for events containing an x field.
y: The y field from the event. Valid only for events containing a y field.
'A': Substitutes the ASCII character corresponding to the event, or the empty string if the event doesn't correspond to an ASCII character (e.g. the shift key was pressed). XLookupString does all the work of translating from the event to an ASCII character. Valid only for
'B': The border_width field from the event. Valid only for
'D': This reports the delta value of a
MouseWheel event. The delta value represents the rotation units the mouse wheel has been moved. On Windows 95 & 98 systems the smallest value for the delta is 120. Future systems may support higher resolution values for the delta. The sign of the value represents the direction the mouse wheel was scrolled.
'E': The send_event field from the event. Valid for all event types.
'K': The keysym corresponding to the event, substituted as a textual string. Valid only for
'N': The keysym corresponding to the event, substituted as a decimal number. Valid only for
'R': The root window identifier from the event. Valid only for events containing a root field.
'S': The subwindow window identifier from the event, formatted as a hexadecimal number. Valid only for events containing a subwindow field.
'T': The type field from the event. Valid for all event types.
'W': The path name of the window to which the event was reported (the window field from the event). Valid for all event types.
'X': The x_root field from the event. If a virtual-root window manager is being used then the substituted value is the corresponding x-coordinate in the virtual root. Valid only for
'Y': The y_root field from the event. If a virtual-root window manager is being used then the substituted value is the corresponding y-coordinate in the virtual root. Valid only for
For more information please consult bind.
|<< Prev||- Up -||Next >>|