Tcl - Re: [Tk] events redirection?

Author

Re: [Tk] events redirection?

Sektor van Skijlen

2006-01-27, 7:59 am

Dnia Thu, 26 Jan 2006 20:56:14 GMT, Bryan Oakley skrobie:
> Sektor van Skijlen wrote:
[color=darkred]
> Tk has a similar feature but done in a different way. Events are
> processed according to the bindtags of the widget that receives the
> event. Bindtags usually contain the actual widget, the widget class, the
> toplevel (".") and "all". This, you can control which handlers will
> handle an event, and in what order.

Yes, I know this feature, but I didn't realize, what it means in practice.

> You can remove any of those from the equation entirely by changing the
> bindtags for a widget. For instance, try setting the bindtags on a text
> widget to be just the widget and nothing else. You'll see the widget
> becomes, in effect, dead.

:)

It means that most of the events are handled in its class, so removing the
class from the bindtag list makes it not responding to interresting events,
right?

> You can also interrupt this flow with a break.

Wow! It looks like some small thing not (or not obviously) described in the
documentation.

> For example, if you bind
> to <Tab>, the widget will handle the event and then the normal <Tab>
> binding will fire, typically moving focus to the next widget. You can
> prevent someone from tabbing to the next widget by using break, for example:

> bind .entry <Tab> {doMyOwnThing; break}

Hmm.. if I understand correctly, the mechanism is as follows:

1. The event is dispatched to a bindtag (first from the list)
2. If the handler contains "break" at the end, the action finishes
3. The event is then dispatched to a bindtag next from the list,
regardless if the previous bindtag handled this event or not

Is that correct?

> Read up on bindtags in the documentation and on the wiki. They are a
> powerful concept, though in practice you don't even need to know they
> exist for 99.9% of what you do. You'll likely find you don't have to
> resort to nearly as many tricks programming in Tk than you do for other
> toolkits. When you need to do something tricky, Tk has some powerful
> mojo under the hood just waiting to be set free.

The reason of a full understanding of Tk evnets is mostly because I plan to
design a GUI library for C++. I like the Tk approach and I plan to base the
philosophy on that. I have just prepared the mechanism of event binding and
dispatching, however - predictably :) - planned that the event handler must
always return a boolean value, which will decide if the event redirection
should stop or not. The mechanism of bindtags could be implemented by bindtag
objects, which will be responsible for dispatching events. Then, a widget will
contain a list of objects containing event dispatcher, to which the event will
be sent for dispatching. A user could add/remove dispatching objects, however
it will contain by default such dispatchers as Tk widgets have: the widget
itself, its class (characteristic object), the main top-level window and a
"general dispacher". The bind_event has a form:

bind_event( bindtag, event_name, handler, ea_one_argument,
ea_another_argument);

where ea_* are similar to %tags in Tk. The handler will be called with passing
these arguments as these marks require.

Now I think the boolean return value is not necessary; this should be rather
implemented by setting some valus in some object since the user wants not to
stop redirection in most cases (however I think throwing an exception - to
which the break/continue mechanism in Tcl is very similar indeed - would be
the only way).

--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)wp.pl>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Bryan Oakley

2006-01-27, 7:59 am

Sektor van Skijlen wrote:
>
>
> :)
>
> It means that most of the events are handled in its class, so removing the
> class from the bindtag list makes it not responding to interresting events,
> right?
>

Right.

>
>
>
> Wow! It looks like some small thing not (or not obviously) described in the
> documentation.
>

It is mentioned in the bind man page under the section "Multiple
Matches". I'll agree it's not entirely obvious.

>
>
>
>
>
> Hmm.. if I understand correctly, the mechanism is as follows:
>
> 1. The event is dispatched to a bindtag (first from the list)
> 2. If the handler contains "break" at the end, the action finishes
> 3. The event is then dispatched to a bindtag next from the list,
> regardless if the previous bindtag handled this event or not
>
> Is that correct?
>

close enough. Read the aforementioned man page for the definitive version.

Sektor van Skijlen

2006-01-27, 7:03 pm

Dnia Fri, 27 Jan 2006 11:57:39 GMT, Bryan Oakley skrobie:
[color=darkred]
> It is mentioned in the bind man page under the section "Multiple
> Matches". I'll agree it's not entirely obvious.

That's it; I lack a documentation about the behavior of the event system;
descriptions of that in "event", "bind" and "bindtags" command manual pages is
either dispersed or not clear.

[color=darkred]
> close enough. Read the aforementioned man page for the definitive version.

This is what I understand from this documentation. That's why I asked you to
correct me if I am not completely correct.

For example:

button .b -text button -command { puts "Normal Button click slot" }
pack .b
bind .b <ButtonRelease-1> { puts "Response for <ButtonRelease-1> event" }
bind Button <ButtonRelease-1> {+puts "Response from Button class" }

After clicking the button (just after releasing the mouse button) I receive:

Response for <ButtonRelease-1> event
Normal Button click slot
Response from Button class

However, when I do

bind .b <ButtonRelease-1> { puts "Response for <ButtonRelease-1> event" ; break }

Then it prints only:

Response for <ButtonRelease-1> event

And the button remains in "pushed" state ;)

--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)wp.pl>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Sponsored Links