in reply to Tk Multiple Event Binding

If you call Tk->break from an event handler, it will prevent any further event handlers being called for that event. So, if you call Tk->break at then end of your event handler bound to '<c>', your '<c><d>' event handler will never be called.

Whether that is the answer to the question you are asking, is as unclear as your question :) Basically, you are unlikely to get good results from bindings that overlap in this way. How would you (or Tk) decide which of your event handlers should be processed?


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: Tk Multiple Event Binding
by Philippe (Novice) on Dec 16, 2005 at 12:11 UTC
    Thanks a lot for your reply! I was already experimenting with that (but I haven't been very successful yet...). I was somehow assuming that the event already matched would be "cleared" and not further looked up (I've now realised that it's clearly stated in the documentation that it's not!) Philippe
      In case anyone is ever interesting in such a messy thing...

      "Tk->break" is not really the way, as it's actually *another* "sequence" which kicks in...

      The dirty trick of inserting meaningless events (which are not going to be part of any sequence) with "eventGenerate" seems to do it...

      Thanks!

      Philippe