Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Giving the current selection in the bind function

24 views
Skip to first unread message

Cecil Westerhof

unread,
Jun 27, 2018, 9:44:05 AM6/27/18
to
I am interested in the current selection. At the moment I use:
bind .brew <<ListboxSelect>> [list makeTea .brew]

and:
proc makeTea {nb} {
puts "Entering makeTea"
puts [${nb} get [${nb} curselection]]
puts "Leaving makeTea"
}

But I would expect it to be possible in the bind. Am I overlooking
something?

Also: do you need the two steps I use to get the current selection?

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Cecil Westerhof

unread,
Jun 27, 2018, 10:14:05 AM6/27/18
to
Cecil Westerhof <Ce...@decebal.nl> writes:

> I am interested in the current selection. At the moment I use:
> bind .brew <<ListboxSelect>> [list makeTea .brew]
>
> and:
> proc makeTea {nb} {
> puts "Entering makeTea"
> puts [${nb} get [${nb} curselection]]
> puts "Leaving makeTea"
> }
>
> But I would expect it to be possible in the bind. Am I overlooking
> something?
>
> Also: do you need the two steps I use to get the current selection?

I expect to need it more often, so I wrote a proc for it:
proc getCurSelection {node} {
${node} get [${node} curselection]
}

and changed:
puts [${nb} get [${nb} curselection]]

to:
puts [getCurSelection ${nb}]

Brad Lanam

unread,
Jun 27, 2018, 10:27:06 AM6/27/18
to
On Wednesday, June 27, 2018 at 6:44:05 AM UTC-7, Cecil Westerhof wrote:
> I am interested in the current selection. At the moment I use:
> bind .brew <<ListboxSelect>> [list makeTea .brew]
>
> and:
> proc makeTea {nb} {
> puts "Entering makeTea"
> puts [${nb} get [${nb} curselection]]
> puts "Leaving makeTea"
> }
>
> But I would expect it to be possible in the bind. Am I overlooking
> something?
>
> Also: do you need the two steps I use to get the current selection?

bind itself has no knowledge of the listbox's current selection.
bind only has knowledge of the event and possibly a few parameters
associted with the event.
In this case, <<ListboxSelection>> is a virtual event, and there are no
parameters for bind to access.

Also, once the bind script becomes more than very simple, it is better
to put the code into a procedure so that the procedure is byte-compiled.

A bind script (i.e. the script directly attached to the bind command) is not byte-compiled.

Cecil Westerhof

unread,
Jun 27, 2018, 12:28:06 PM6/27/18
to
So the way I did it is the 'best' way?

Rich

unread,
Jun 27, 2018, 12:33:55 PM6/27/18
to
More like the /only/ way. Bind gives you information about the event
that triggered the action, but does not give you info about the
contents (here I merge the "selection state" into 'contents') of any of
the widgets.

Read the bind man page for a description of all of the 'event data'
that it can provide.

Cecil Westerhof

unread,
Jun 27, 2018, 2:28:04 PM6/27/18
to
I will do that. Thanks.

Mike Griffiths

unread,
Jun 27, 2018, 4:33:42 PM6/27/18
to
It's a minor change, but I'd suggest using %W in the binding in place of .brew - it's self-documenting that you're passing the 'active' widget with the binding, and you don't have to worry about updating it if you alter your UI layout in future and the widget path changes.

Cecil Westerhof

unread,
Jun 27, 2018, 5:28:04 PM6/27/18
to
Mike Griffiths <mi...@keyboardzombie.com> writes:

> It's a minor change, but I'd suggest using %W in the binding in place of
> .brew - it's self-documenting that you're passing the 'active' widget
> with the binding, and you don't have to worry about updating it if you
> alter your UI layout in future and the widget path changes.

I like that very much. I really did not like that I was using .brew.
Thanks. It starts to look like something useful. ;-)
0 new messages