[[Explain virtual events.  Is there a tutorial?
Illustrate usage.  Put forward references in appropriate
places--what are those?  "advanced Tk-ing?"]]








[[Important thread:
http://groups.google.com/groups?th=5f799aadcb2caf35 ]]

----

[Bryan Oakley]'s wizard mega- (meta?) widget taught me a ''wonderful'' use of virtual events.  Whereas I had code in my wizard implementation like:

    proc doNextThing { args } {
       ...
    }
    button $w.next -text "Next" -command doNextThing
    
Bryan had the foresight to indirect the button handling via virtual events.  Now I do something like:

    proc doNextThing { args } {
    }
    proc dispatch { event } {
        switch -- $event {
            <<Next>> {
                doNextThing
            } 
            ...
        }
    }
    ...
    button $w.next -text "Next" \
        -command [list event generate $w <<Next>>]
    bind $w <<Next>> [list dispatch <<Next>>]

The wonder of this is that my testing harness can do:

    bind $w <<Next>> {+doTestingThing}

and trap the button presses without making invasive changes to the wizard code!

--[Chris Nelson]

----

[MC] (5 May 2003): Until today I hadn't realized that you could have Virtual Events that weren't associated with a real physical event.  Then while googling on [event] add I came across this[http://groups.google.com/groups?selm=u1tT9.47%24fF3.61480166%40newssvr11.news.prodigy.com] enlightening comp.lang.tcl post from [Bryan Oakley].

[DKF] - Most virtual events are generated in response to a physical event of one kind or another (since they all have to have a window) but there's no need for them to be directly associated with anything.  Various events dealing with those changes to Tk's internal data models that are not bound to variables (e.g. the '''<<ListboxSelect>>''' and '''<<MenuSelect>>''' events) are produced to make tracking things easier.
----
See also [Concepts of Architectural Design for Tcl Applications].
----
[Category Concept]