Tktable browsecommand question

Hello.

I'm trying to understand a certain Tktable behavior which seems to
contradict what is described in the man page. The man page says that
-browsecommand "Specifies a command which will be evaluated anytime the
active cell changes." The behavior in question is seen when the
-browsecommand is a lengthy process that runs the event loop, as in this
little demo:

package require Tktable
proc cmd {cell args} {
set act [.t tag cell active]
set sel [.t tag cell sel]
puts "$args cell $cell active $act selected $sel"
}
proc browse args {
eval cmd $args browse
update idletasks
# Works if you comment out everything after 2000, or change
# the table -browsecommand to {after idle browse %C}
after 2000 set ::Done 1; tkwait variable ::Done
eval cmd $args done
}
table .t -variable T -state disabled \
-selectmode extended -exportselection false \
-browsecommand {browse %C}
bind .t <1> {cmd [%W index @%x,%y] click}
pack .t
catch {console show}

Run the demo then click on three different cells in rapid succession,
i.e., while the 2-second timer is still running from the first click. If
I click on the top left cell and the two below it, I get:

click cell 0,0 active  selected
browse cell 0,0 active 0,0 selected 0,0
click cell 1,0 active 0,0 selected 0,0
click cell 2,0 active 1,0 selected 1,0
done cell 0,0 active 2,0 selected 2,0

This all makes sense; there was initially no cell active or selected,
but the first click activated and selected a cell and triggered the
browsecommand. Subsequent clicks activate and select new cells, but the
browsecommand is never called.

The net result is that the GUI is showing cell 2,0 selected, but the
last cell for which the browsecommand was called is 0,0. In my real app
this is an undesirable state. As noted in the comments above, you can
avoid this situation by either not running the event loop during the
browsecommand, or scheduling the lengthy event-looping processes to run
when idle. That queues up *all* clicks for eventual execution, which is
good for some apps but is not what I want for my app.

The existing behavior is close to being what I want, ignoring some
clicks that occur during the lengthy process, but it can also ignore the
last click. I'm thinking that the way to handle that is to check at the
very end of the browsecommand whether another cell has been activated
and, if so, process it.

Back on topic: Is the bug in the man page, tktable, or my understanding?

John Seal wrote:
> I'm trying to understand a certain Tktable behavior which seems to
> contradict what is described in the man page. The man page says that
> -browsecommand "Specifies a command which will be evaluated anytime the
> active cell changes." The behavior in question is seen when the
> -browsecommand is a lengthy process that runs the event loop, as in this
> little demo:

It should be noted in the docs that -browsecommand also does not allow
itself to be called recursively.  The C code specifically sets a flag
when in -browsecommand to not call itself until it has finished.  That
would clarify what you are seeing as "correct by design" (if not
necessarily as doc'ed).

Jeff

Jeff Hobbs wrote:
> It should be noted in the docs that -browsecommand also does not allow
> itself to be called recursively.  The C code specifically sets a flag
> when in -browsecommand to not call itself until it has finished.

That's not what I'm seeing! See my follow-up posting for an example
where browsecommands seem to nest. I've been adding an explicit check to
the browsecommand in my real app to prevent reentry, which you imply
should be unnecessary.

> That
> would clarify what you are seeing as "correct by design" (if not
> necessarily as doc'ed).

The phrase we use around here is "works as coded"!

Should I write a bug against the man page?