1bind(3) User Contributed Perl Documentation bind(3)
2
6 Tk::bind - Arrange for X events to invoke callbacks
7
9 Retrieve bindings:
10 $widget->bind
12 $widget->bind(tag)
14 $widget->bind(sequence)
16 $widget->bind(tag,sequence)
18 Associate and destroy bindings:
20 $widget->bind(sequence,callback)
22 $widget->bind(tag,sequence,callback)
24
26 The bind method associates callbacks with X events. If callback is
27 specified, bind will arrange for callback to be evaluated whenever the
28 event(s) given by sequence occur in the window(s) identified by $widget
29 or tag. If callback is an empty string then the current binding for
30 sequence is destroyed, leaving sequence unbound. In all of the cases
31 where a callback argument is provided, bind returns an empty string.
32 If sequence is specified without a callback, then the callback
34 currently bound to sequence is returned, or undef is returned if there
35 is no binding for sequence. If neither sequence nor callback is
36 specified, then the return value is a list whose elements are all the
37 sequences for which there exist bindings for tag.
38 If no tag is specified then the bind refers to $widget. If tag is
40 specified then it is typically a class name and the bind refers to all
41 instances of the class on the MainWindow associated with $widget. (It
42 is possible for tag to be another "widget object" but this practice is
43 deprecated.) Perl's ref($object) can be used to get the class name of
44 any object. Each window has an associated list of tags, and a binding
45 applies to a particular window if its tag is among those specified for
46 the window. Although the bindtags method may be used to assign an
47 arbitrary set of binding tags to a window, the default binding tags
48 provide the following behavior:
49 If a tag is the name of an internal window the binding applies to that
51 window.
52 If the tag is the name of a toplevel window the binding applies to the
54 toplevel window and all its internal windows.
55 If the tag is the name of a class of widgets, such as Tk::Button, the
57 binding applies to all widgets in that class;
58 If tag has the value all, the binding applies to all windows descended
60 from the MainWindow of the application.
61
63 The sequence argument specifies a sequence of one or more event
64 patterns, with optional white space between the patterns. Each event
65 pat may take one of three forms. In the simplest case it is a single
66 printing ASCII character, such as a or [. The character may not be a
67 space character or the character <. This form of pattern matches a
68 KeyPress event for the particular character. The second form of
69 pattern is longer but more general. It has the following syntax:
70 '<modifier-modifier-type-detail>'
72 The entire event pattern is surrounded by angle brackets, and normally
74 needs to be quoted, as angle brackets are special to perl. Inside the
75 angle brackets are zero or more modifiers, an event type, and an extra
76 piece of information (detail) identifying a particular button or
77 keysym. Any of the fields may be omitted, as long as at least one of
78 type and detail is present. The fields must be separated by white
79 space or dashes.
80 The third form of pattern is used to specify a user-defined, named
82 virtual event; see Tk::event for details. It has the following syntax:
83 '<<name>>'
85 The entire virtual event pattern is surrounded by double angle
87 brackets. Inside the angle brackets is the user-defined name of the
88 virtual event. Modifiers, such as Shift or Control, may not be
89 combined with a virtual event to modify it. Bindings on a virtual
90 event may be created before the virtual event is defined, and if the
91 definition of a virtual event changes dynamically, all windows bound to
92 that virtual event will respond immediately to the new definition.
93
95 Modifiers consist of any of the following values:
96 Control Mod2, M2
98 Shift Mod3, M3
99 Lock Mod4, M4
100 Button1, B1 Mod5, M5
101 Button2, B2 Meta, M
102 Button3, B3 Alt
103 Button4, B4 Double
104 Button5, B5 Triple
105 Mod1, M1 Quadruple
106 Where more than one value is listed, separated by commas, the values
108 are equivalent. Most of the modifiers have the obvious X meanings.
109 For example, Button1 requires that button 1 be depressed when the event
110 occurs. For a binding to match a given event, the modifiers in the
111 event must include all of those specified in the event pattern. An
112 event may also contain additional modifiers not specified in the
113 binding. For example, if button 1 is pressed while the shift and
114 control keys are down, the pattern <Control-Button-1> will match the
115 event, but <Mod1-Button-1> will not. If no modifiers are specified,
116 then any combination of modifiers may be present in the event.
117 Meta and M refer to whichever of the M1 through M5 modifiers is
119 associated with the meta key(s) on the keyboard (keysyms Meta_R and
120 Meta_L). If there are no meta keys, or if they are not associated with
121 any modifiers, then Meta and M will not match any events. Similarly,
122 the Alt modifier refers to whichever modifier is associated with the
123 alt key(s) on the keyboard (keysyms Alt_L and Alt_R).
124 The Double, Triple and Quadruple modifiers are a convenience for
126 specifying double mouse clicks and other repeated events. They cause a
127 particular event pattern to be repeated 2, 3 or 4 times, and also place
128 a time and space requirement on the sequence: for a sequence of events
129 to match a Double, Triple or Quadruple pattern, all of the events must
130 occur close together in time and without substantial mouse motion in
131 between. For example, <Double-Button-1> is equivalent to
132 <Button-1><Button-1> with the extra time and space requirement.
133
135 The type field may be any of the standard X event types, with a few
136 extra abbreviations. Below is a list of all the valid types; where two
137 names appear together, they are synonyms.
138 Activate Destroy Map
140 ButtonPress, Button Enter MapRequest
141 ButtonRelease Expose Motion
142 Circulate FocusIn MouseWheel
143 CirculateRequest FocusOut Property
144 Colormap Gravity Reparent
145 Configure KeyPress, Key ResizeRequest
146 ConfigureRequest KeyRelease Unmap
147 Create Leave Visibility
148 Deactivate
149 Most of the above events have the same fields and behaviors as events
151 in the X Windowing system. You can find more detailed descriptions of
152 these events in any X window programming book. A couple of the events
153 are extensions to the X event system to support features unique to the
154 Macintosh and Windows platforms. We provide a little more detail on
155 these events here. These include:
156 Activate
158 Deactivate
159 These two events are sent to every sub-window of a toplevel when they
161 change state. In addition to the focus Window, the Macintosh platform
162 and Windows platforms have a notion of an active window (which often
163 has but is not required to have the focus). On the Macintosh, widgets
164 in the active window have a different appearance than widgets in
165 deactive windows. The Activate event is sent to all the sub-windows in
166 a toplevel when it changes from being deactive to active. Likewise,
167 the Deactive event is sent when the window's state changes from active
168 to deactive. There are no use- ful percent substitutions you would
169 make when binding to these events.
170 MouseWheel
172 Some mice on the Windows platform support a mouse wheel which is used
174 for scrolling documents without using the scrollbars. By rolling
175 the wheel, the system will generate MouseWheel events that the
176 application can use to scroll. Like Key events the event is always
177 routed to the window that currently has focus. When the event is
178 received you can use the %D substitution to get the delta field for the
179 event which is a integer value of motion that the mouse wheel has
180 moved. The smallest value for which the system will report is defined
181 by the OS. On Windows 95 & 98 machines this value is at least 120
182 before it is reported. However, higher resolution devices may be
183 available in the future. The sign of the value determines which
184 direction your widget should scroll. Positive values should scroll up
185 and negative values should scroll down.
186 The last part of a long event specification is detail. In the case of
188 a ButtonPress or ButtonRelease event, it is the number of a button
189 (1-5). If a button number is given, then only an event on that
190 particular button will match; if no button number is given, then an
191 event on any button will match. Note: giving a specific button number
192 is different than specifying a button modifier; in the first case, it
193 refers to a button being pressed or released, while in the second it
194 refers to some other button that is already depressed when the matching
195 event occurs. If a button number is given then type may be omitted:
196 if will default to ButtonPress. For example, the specifier <1> is
197 equivalent to <ButtonPress-1>.
198 If the event type is KeyPress or KeyRelease, then detail may be
200 specified in the form of an X keysym. Keysyms are textual
201 specifications for particular keys on the keyboard; they include all
202 the alphanumeric ASCII characters (e.g. ``a'' is the keysym for the
203 ASCII character ``a''), plus descriptions for non-alphanumeric
204 characters (``comma'' is the keysym for the comma character), plus
205 descriptions for all the non-ASCII keys on the keyboard (``Shift_L'' is
206 the keysm for the left shift key, and ``F1'' is the keysym for the F1
207 function key, if it exists). The complete list of keysyms is not
208 presented here; it is available in other X documentation and may vary
209 from system to system. If necessary, you can use the 'K' notation
210 described below to print out the keysym name for a particular key. If
211 a keysym detail is given, then the type field may be omitted; it will
212 default to KeyPress. For example, <Control-comma> is equivalent to
213 <Control-KeyPress-comma>.
214
216 The callback argument to bind is a perl/Tk callback. which will be
217 executed whenever the given event sequence occurs. (See Tk::callbacks
218 for description of the possible forms.) Callback will be associated
219 with the same MainWindow that is associated with the $widget that was
220 used to invoke the bind method, and it will run as though called from
221 MainLoop. If callback contains any Ev(%) calls, then each "nested"
222 Ev(%) "callback" will be evaluated when the event occurs to form
223 arguments to be passed to the main callback. The replacement depends
224 on the character %, as defined in the list below. Unless otherwise
225 indicated, the replacement string is the numeric (decimal) value of the
226 given field from the current event. Perl/Tk has enhanced this mechanism
227 slightly compared to the comparable Tcl/Tk mechanism. The enhancements
228 are not yet all reflected in the list below. Some of the substitutions
229 are only valid for certain types of events; if they are used for other
230 types of events the value substituted is undefined (not the same as
231 undef!).
232 '#' The number of the last client request processed by the server (the
234 serial field from the event). Valid for all event types.
235 'a' The above field from the event, formatted as a hexadecimal number.
237 Valid only for Configure events.
238 'b' The number of the button that was pressed or released. Valid only
240 for ButtonPress and ButtonRelease events.
241 'c' The count field from the event. Valid only for Expose events.
243 'd' The detail field from the event. The 'd' is replaced by a string
245 identifying the detail. For Enter, Leave, FocusIn, and FocusOut
246 events, the string will be one of the following:
247 NotifyAncestor NotifyNonlinearVirtual
249 NotifyDetailNone NotifyPointer
250 NotifyInferior NotifyPointerRoot
251 NotifyNonlinear NotifyVirtual
252 For ConfigureRequest events, the string will be one of:
254 Above Opposite
256 Below None
257 BottomIf TopIf
258 For events other than these, the substituted string is undefined.
260 (Note that this is not the same as Detail part of sequence use to
261 specify the event.)
262 'f' The focus field from the event (0 or 1). Valid only for Enter and
264 Leave events.
265 'h' The height field from the event. Valid only for Configure,
267 ConfigureRequest, Create, Expose, and ResizeRequest events.
268 'i' The window field from the event, represented as a hexadecimal
270 integer.
271 'k' The keycode field from the event. Valid only for KeyPress and
273 KeyRelease events.
274 'm' The mode field from the event. The substituted string is one of
276 NotifyNormal, NotifyGrab, NotifyUngrab, or NotifyWhileGrabbed.
277 Valid only for Enter, FocusIn, FocusOut, and Leave events.
278 'o' The override_redirect field from the event. Valid only for Map,
280 Reparent, and Configure events.
281 'p' The place field from the event, substituted as one of the strings
283 PlaceOnTop or PlaceOnBottom. Valid only for Circulate and
284 CirculateRequest events.
285 's' The state field from the event. For ButtonPress, ButtonRelease,
287 Enter, KeyPress, KeyRelease, Leave, and Motion events, a decimal
288 string is substituted. For Visibility, one of the strings
289 VisibilityUnobscured, VisibilityPartiallyObscured, and
290 VisibilityFullyObscured is substituted.
291 't' The time field from the event. Valid only for events that contain
293 a time field.
294 'w' The width field from the event. Valid only for Configure,
296 ConfigueRequest, Create, Expose, and ResizeREquest events.
297 'x' The x field from the event. Valid only for events containing an x
299 field.
300 'y' The y field from the event. Valid only for events containing a y
302 field.
303 '@' The string "@x,y" where x and y are as above. Valid only for
305 events containing x and y fields. This format is used my methods
306 of Tk::Text and similar widgets.
307 'A' Substitutes the UNICODE character corresponding to the event, or
309 the empty string if the event doesn't correspond to a UNICODE
310 character (e.g. the shift key was pressed). XmbLookupString does
311 all the work of translating from the event to a UNICODE character.
312 Valid only for KeyPress and KeyRelease events.
313 'B' The border_width field from the event. Valid only for Configure,
315 ConfigureRequest and Create events.
316 'D' This reports the delta value of a MouseWheel event. The delta
318 value represents the rotation units the mouse wheel has been
319 moved. On Windows 95 & 98 systems the smallest value for the
320 delta is 120. Future systems may support higher resolution values
321 for the delta. The sign of the value represents the direction the
322 mouse wheel was scrolled.
323 'E' The send_event field from the event. Valid for all event types.
325 'K' The keysym corresponding to the event, substituted as a textual
327 string. Valid only for KeyPress and KeyRelease events.
328 'N' The keysym corresponding to the event, substituted as a decimal
330 number. Valid only for KeyPress and KeyRelease events.
331 'R' The root window identifier from the event. Valid only for events
333 containing a root field.
334 'S' The subwindow window identifier from the event, as an object if it
336 is one otherwise as a hexadecimal number. Valid only for events
337 containing a subwindow field.
338 'T' The type field from the event. Valid for all event types.
340 'W' The window to which the event was reported (the $widget field from
342 the event) - as an perl/Tk object. Valid for all event types.
343 'X' The x_root field from the event. If a virtual-root window manager
345 is being used then the substituted value is the corresponding
346 x-coordinate in the virtual root. Valid only for ButtonPress,
347 ButtonRelease, KeyPress, KeyRelease, and Motion events.
348 'Y' The y_root field from the event. If a virtual-root window manager
350 is being used then the substituted value is the corresponding
351 y-coordinate in the virtual root. Valid only for ButtonPress,
352 ButtonRelease, KeyPress, KeyRelease, and Motion events.
353
355 It is possible for several bindings to match a given X event. If the
356 bindings are associated with different tag's, then each of the bindings
357 will be executed, in order. By default, a class binding will be
358 executed first, followed by a binding for the widget, a binding for its
359 toplevel, and an all binding. The bindtags method may be used to
360 change this order for a particular window or to associate additional
361 binding tags with the window.
362 return and Tk->break may be used inside a callback to control the
364 processing of matching callbacks. If return is invoked, then the
365 current callback is terminated but Tk will continue processing
366 callbacks associated with other tag's. If Tk->break is invoked within
367 a callback, then that callback terminates and no other callbacks will
368 be invoked for the event. (Tk->break is implemented via perl's die
369 with a special value which is "caught" by the perl/Tk "glue" code.)
370 If more than one binding matches a particular event and they have the
372 same tag, then the most specific binding is chosen and its callback is
373 evaluated. The following tests are applied, in order, to determine
374 which of several matching sequences is more specific: (a) an event
375 pattern that specifies a specific button or key is more specific than
376 one that doesn't; (b) a longer sequence (in terms of number of events
377 matched) is more specific than a shorter sequence; (c) if the modifiers
378 specified in one pattern are a subset of the modifiers in another
379 pattern, then the pattern with more modifiers is more specific. (d) a
380 virtual event whose physical pattern matches the sequence is less
381 specific than the same physical pattern that is not associated with a
382 virtual event. (e) given a sequence that matches two or more virtual
383 events, one of the virtual events will be chosen, but the order is
384 undefined.
385 If the matching sequences contain more than one event, then tests
387 (c)-(e) are applied in order from the most recent event to the least
388 recent event in the sequences. If these tests fail to determine a
389 winner, then the most recently registered sequence is the winner.
390 If there are two (or more) virtual events that are both triggered by
392 the same sequence, and both of those virtual events are bound to the
393 same window tag, then only one of the virtual events will be triggered,
394 and it will be picked at random:
395 $widget->eventAdd('<<Paste>>' => '<Control-y>');
397 $widget->eventAdd('<<Paste>>' => '<Button-2>');
398 $widget->eventAdd <<Scroll>>' => '<Button-2>');
399 $widget->bind('Tk::Entry','<<Paste>>',sub { print 'Paste'});
400 $widget->bind('Tk::Entry','<<Scroll>>', sub {print 'Scroll'});
401 If the user types Control-y, the <<Paste>> binding will be invoked, but
403 if the user presses button 2 then one of either the <<Paste>> or the
404 <<Scroll>> bindings will be invoked, but exactly which one gets invoked
405 is undefined.
406 If an X event does not match any of the existing bindings, then the
408 event is ignored. An unbound event is not considered to be an error.
409
411 When a sequence specified in a bind method contains more than one event
412 pattern, then its callback is executed whenever the recent events
413 (leading up to and including the current event) match the given
414 sequence. This means, for example, that if button 1 is clicked
415 repeatedly the sequence <Double-ButtonPress-1> will match each button
416 press but the first. If extraneous events that would prevent a match
417 occur in the middle of an event sequence then the extraneous events are
418 ignored unless they are KeyPress or ButtonPress events. For example,
419 <Double-ButtonPress-1> will match a sequence of presses of button 1,
420 even though there will be ButtonRelease events (and possibly Motion
421 events) between the ButtonPress events. Furthermore, a KeyPress event
422 may be preceded by any number of other KeyPress events for modifier
423 keys without the modifier keys preventing a match. For example, the
424 event sequence aB will match a press of the a key, a release of the a
425 key, a press of the Shift key, and a press of the b key: the press of
426 Shift is ignored because it is a modifier key. Finally, if several
427 Motion events occur in a row, only the last one is used for purposes of
428 matching binding sequences.
429
431 If an error occurs in executing the callback for a binding then the
432 Tk::Error mechanism is used to report the error. The Tk::Error
433 mechanism will be executed at same call level, and associated with the
434 same MainWindow as as the callback was invoked.
435
437 Note that for the Canvas widget, the call to bind has to be fully
438 qualified. This is because there is already a bind method for the
439 Canvas widget, which binds individual canvas tags.
440 $canvas->Tk::bind
442
444 Tk::Error Tk::callbacks Tk::bindtags
445
447 Event, binding
448perl v5.16.3 2014-06-10 bind(3)