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

Tablelist bindings

54 views
Skip to first unread message

Alan Grunwald

unread,
Apr 12, 2021, 4:03:40 PM4/12/21
to
I'm writing my own colour chooser dialog, based on a Tablelist with two
columns showing the name of the colour and a sample, and three entry
widgets showing the red/green/blue components of the selected colour.

I defined a script to update the values of the colour components when
the user clicked on a colour name which used

[.tablelist index active]

to identify the selected colour and populated the entry widgets accordingly.

I bound the script to <Button-1> on [.tablelist bodytag] and everything
seemed to working fine.

I then realised that this simply didn't work if the user changed the
selection in the tablelist widget by using the arrow keys, and I need to
bind to the <<TablelistSelect>> virtual event. This didn't work all that
well because the entries reflected the old colour rather than the new
one, which is because Tablelist seems to deliver the virtual event
before it updates the active row.

I did a little experiment and found that <Button-1> was delivered before
<<TablelistSelect>>, so I've added a binding to <Button-1> that
activates the row when the user clicks on it, and on on <<Tablelist>>
that updates the component entries according to the content of the
active row.

This all seems to work fine, but I'm concerned that a future version of
Tablelist may deliver the events in a different order, or malfunction
because the active row has changed unexpectedly.

Is there a better way to do this that I've overlooked or is this the
supported way to achieve what I'm trying to do?

TIA - Alan

nemethi

unread,
Apr 13, 2021, 6:34:01 AM4/13/21
to
Am 12.04.21 um 22:03 schrieb Alan Grunwald:
The default bindings for tablelist widgets handle the active item and
the selection in *exactly* the same way as those for listbox widgets.
The rules below are valid for the default selection mode "browse" and
selection type "row":

- The selection is changed (and the <<TablelistSelect>> virtual event is
sent) as a result of a <Button-1> event.

- The active item is changed by a <ButtonRelease-1> event.

- The Up and Down keys change both the active item and the selection
(and generate the <<TablelistSelect>> virtual event).

From the above it follows that it is not safe to use [.tablelist index
active] in a script bound to the <Button-1> event or to the
<<TablelistSelect>> virtual event. In a script bound to the <Button-1>
event you can use the nearest subcommand instead, like in the example below:

bind [.tablelist bodytag] <Button-1> {printClickedRow %W %x %y}

proc printClickedRow {w x y} {
foreach {tbl x y} [tablelist::convEventFields $w $x $y] {}
puts "clicked on row [$tbl nearest $y]"
}

To your concern regarding the event order: It is extremely unlikely
that Tablelist might change the order in which the events are delivered.

BTW: The simplest way to react on changes of the active item is to use
my Wcb package.

--
Csaba Nemethi https://www.nemethi.de mailto:csaba....@t-online.de

Ralf Fassel

unread,
Apr 13, 2021, 9:38:17 AM4/13/21
to
* Alan Grunwald <nospam....@gmail.com>
| I'm writing my own colour chooser dialog, based on a Tablelist with
| two columns showing the name of the colour and a sample, and three
| entry widgets showing the red/green/blue components of the selected
| colour.
>
| I defined a script to update the values of the colour components when
| the user clicked on a colour name which used
>
| [.tablelist index active]

Is there some specific reason using 'index active' instead of
'curselection' and -selectmode single?

R'

Alan Grunwald

unread,
Apr 14, 2021, 8:11:18 AM4/14/21
to
On 13/04/2021 11:33, nemethi wrote:

<snip>

>
> The default bindings for tablelist widgets handle the active item and
> the selection in *exactly* the same way as those for listbox widgets.
> The rules below are valid for the default selection mode "browse" and
> selection type "row":
>
> - The selection is changed (and the <<TablelistSelect>> virtual event is
> sent) as a result of a <Button-1> event.
>
> - The active item is changed by a <ButtonRelease-1> event.
>
> - The Up and Down keys change both the active item and the selection
> (and generate the <<TablelistSelect>> virtual event).
>
> From the above it follows that it is not safe to use [.tablelist index
> active] in a script bound to the <Button-1> event or to the
> <<TablelistSelect>> virtual event.  In a script bound to the <Button-1>
> event you can use the nearest subcommand instead, like in the example
> below:
>
> bind [.tablelist bodytag] <Button-1> {printClickedRow %W %x %y}
>
> proc printClickedRow {w x y} {
>     foreach {tbl x y} [tablelist::convEventFields $w $x $y] {}
>     puts "clicked on row [$tbl nearest $y]"
> }
>
> To your concern regarding the event order:  It is extremely unlikely
> that Tablelist might change the order in which the events are delivered.
>
> BTW: The simplest way to react on changes of the active item is to use
> my Wcb package.
>

Thanks Csaba,

I will add a function to update my entry widgets according to the
contents of the row passed as an argument and bind scripts to
<<TablelistSelect>> and <Button-1> to find the appropriate row using
[index active] and [nearest] respectively and then call the new function.

Thanks again,
Alan

Alan Grunwald

unread,
Apr 14, 2021, 8:27:03 AM4/14/21
to
Thank you for your reply Ralf.

There was no specific reason for not using 'curselection' and
'-selectmode single'; I wasn't aware of curselection and am always a
little confused by -selectmode, so tend to leave well alone.

I developed by trying what was essentially the first thing I thought of
and then, when I found it didn't work, tried the first fix I thought of.

Thanks again, I will probably try a fix along the lines that Csaba
suggested, but will also bear curselection and -selectmode in mind for
the future.

Alan

nemethi

unread,
Apr 14, 2021, 8:34:32 AM4/14/21
to
Am 14.04.21 um 14:10 schrieb Alan Grunwald:
Actually, the simplest solution is to use a binding for
<<TablelistSelect>> only and get the selected row by invoking the
curselection subcommand, as suggested by Ralf (you can keep the default
selection mode "browse", no need to set it to "single").

Alan Grunwald

unread,
Apr 14, 2021, 2:30:36 PM4/14/21
to
On 14/04/2021 13:26, Alan Grunwald wrote:
> On 13/04/2021 14:38, Ralf Fassel wrote:
>> * Alan Grunwald <nospam....@gmail.com>
>> | I'm writing my own colour chooser dialog, based on a Tablelist with
>> | two columns showing the name of the colour and a sample, and three
>> | entry widgets showing the red/green/blue components of the selected
>> | colour.

<snip>

> Thanks again, I will probably try a fix along the lines that Csaba
> suggested, but will also bear curselection and -selectmode in mind for
> the future.

Thank you yet again. I read Csaba's initial reply and noticed that he
recommended against using [$tbl index active] from each of the bindings
I was using. By the time I saw his second response I had already gone
ahead and implemented something using both <Button-1> and
<<TablelistSelect>> binding scripts. I have now removed the <Button-1>
binding leaving quite a clean looking system that has the merit of
working too!

A final note that I was a little spooked to see that the highlighting
behaviour changed when I set -selectmode single, but I have now restored
the default and all is (still) well!

Alan

Ralf Fassel

unread,
Apr 15, 2021, 4:59:06 AM4/15/21
to
* Alan Grunwald <nospam....@gmail.com>
| A final note that I was a little spooked to see that the highlighting
| behaviour changed when I set -selectmode single, but I have now
| restored the default and all is (still) well!

Yes, as Csaba noted it is not necessary to change the selectmode.
In fact, I confused "-selectmode browse" with "-selectmode multiple"...
(-:

R'
0 new messages