| [ Team LiB ] |
|
Virtual EventsA virtual event corresponds to one or more event sequences. When any of the event sequences occurs, then the virtual event occurs. Example 29-4 shows the cut, copy, and paste virtual events for each platform: Example 29-4 Virtual events for cut, copy, and paste
switch $tcl_platform(platform) {
"unix" {
event add <<Cut>> <Control-Key-x> <Key-F20>
event add <<Copy>> <Control-Key-c> <Key-F16>
event add <<Paste>> <Control-Key-v> <Key-F18>
}
"windows" {
event add <<Cut>> <Control-Key-x> <Shift-Key-Delete>
event add <<Copy>> <Control-Key-c> <Control-Key-Insert>
event add <<Paste>> <Control-Key-v> <Shift-Key-Insert>
}
"macintosh" {
event add <<Cut>> <Control-Key-x> <Key-F2>
event add <<Copy>> <Control-Key-c> <Key-F3>
event add <<Paste>> <Control-Key-v> <Key-F4>
}
}
You can define more than one physical event that maps to the same virtual event: event add <<Cancel>> <Control-c> <Escape> <Command-period> With this definition any of the physical events will trigger a <<Cancel>>. This would be convenient if the same user commonly used your application on different platforms. However, it is also possible that the physical bindings on different platforms overlap in conflicting ways. By default, virtual event definitions add to existing definitions for the same virtual event. The previous command could be replaced with these three: event add <<Cancel>> <Control-c> event add <<Cancel>> <Escape> event add <<Cancel>> <Command-period> Several widgets use virtual events as a notification mechanism. They generate virtual events in response to various conditions so that you can create bindings to respond to those conditions. For example, the listbox widget generates a <<ListboxSelect>> virtual event whenever the listbox selection changes. The easiest way to respond to changes to the listbox selection is to bind to this virtual event, for example:
bind .lbox <<ListboxSelect>> {ListboxChanged %W}
|
| [ Team LiB ] |
|