Hi there,

It looks like you did some research and are being quite thoughtful about what's going on in this case. I'm far from a Tk expert, but maybe can point you in the right direction at least.

As for your first observation, yes you're correct. Your substituted code should be fine in this case. In general you only need to wait for Idle to ensure that a previous operation completes.

Next, you ask:

             after(*ms*, *callback*?).
    So how do these fit in to permit the syntax  2000=> configure => $tree in your code:
    $mw->after( 2000 => configure => $tree, -background => 'green' ); ?

The syntax is unfortunate, it's equivalent to this which is more clear:

$mw->after( 2000, ('configure', ($tree, -background => 'green') ) );
[download]

Which says, after 2 seconds, call the "configure" method of the $tree object, with everything that follows as the remaining arguments. What might be slightly confusing is that $tree is considered an argument to the method. If you look at modules that implement a class, each method takes the object reference as the first argument. That's why in sub's that implement a class method, you'll typically see something like this:

sub  method_name {
       my $self = shift;
       ...
}
[download]

And from then on the sub will use $self as a handle to the current object being operated on. After the shift, the @_ array has all of the actual arguments which were passed to the method.

As for your last question, if you read closely the description given in Re^6: Table matrix suspected selected cell discrepancy, you'll see that what is happening, is that when the mouse is clicked, the TableMatrix $t has its "curselection" updated before the brscmd sub gets called (as desired). However, Tk calls brscmd _first_ when the keystroke event fires. The update of the "curselection" will happen after brscmd returns (too late).

Tk keeps a list of things it must do; multiple callbacks it must make that have been registered to a given event. So in the example above, after brscmd returns, Tk still has on its list of callbacks the TableMatrix, which will update its "curselection" and then return control to Tk, which may make additional callbacks if there are any remaining.

When all this work gets done and Tk has nothing else to do until the next keyboard or mouse event happen, it enters "idle" mode. And boom, all the callbacks registered to the idle timer are run.

So, the answer as to why the afterIdle solved the problem in the example you found. It was so that Tk could continue its job, allowing the TableMatrix to update, at which point Tk goes idle, and only then calling the afterIdle code which can reliably depend on the correct value being available via $t->curselection.