Id of after command created by -afteridle flag

[georgtree]

Hello!
I have a problem - I create tablelist with this code:

$objPave paveWindow $win.fra.nbk.fOutput.lfrCustomTables.lfr$customDataFieldName {
                {tbl1 - - 1 2 {pack -side left -fill both -expand 1}\
                         {-h 3 -stripebackground $::modelTestVerTool::gui::globVars(stripebackground) -editselectedonly 1\
                              -lbxsel buT -columns {$columns}\
                              -afteridle {$globVars(fontConf) -labelfont TkDefaultFont}}}
                {sbvExpVals tbl1 L 1 1 {pack -before %w} {}}
                {sbhExpVals tbl1 T - - {pack -before %w} {}}
            }

but if I in the same procedure destroy the table (before procedure returns), it obviously throws error of non-existent table name command. So I have to cancel after idle event, but I need an id for that. Is there a way to get that id?

The only way now is to call update idle right after table creation explicitly.

Regards, George.

[georgtree]

And also, what is the clean/proper way to recreate widget? Delete previous first and then create new? Because it works even without deletion as in usual Tk widget, but there could be another loose ends to catch like that after idle call

[aplsimple]

Hi George,

From apave docs:

-afteridle {command %w}	means a command to be run as "after idle" argument when the window paving done;
%w is a full path to a widget with this attribute

Thus, -afteridle option is for convenience' sake mostly:

1. it provides %w placeholder for the current widget's path
2. the after command is located closely to the widget declaration

Of course, if you set after immediately after $pobj paveWindow

   $pobj paveWindow {
      ...
    }
   set afterID [after idle ...]

this would work in the same manner as your -afteridle option - but you can handle its ID.

The more so as your command

  $globVars(fontConf) -labelfont TkDefaultFont

doesn't contain %w (current widget's path).

[georgtree]

I see, thank you. Is there any bindings that apave does behind the scenes so I can clean them too when destroy a widget?

[georgtree]

So, i discovered the issue with interaction of process_* and tablelist creation.

If I call tablelist creation between process_Go ... calls, the number of scheduled after explodes, from stable 8 to 50 and later to 130.

There is some interference between tablelist and process_*, and it breaks modality of the window (which itself is called with -modal yes flag) in which I call progress_*.

Maybe it messes with update inside the progress bar?

I can't paste code here, but I will try to recreate it with simpler code.

[georgtree]

Interesting, if I comment update in both progress_Go and progress_Begin, everything just crashes

[georgtree]

Removing this:

set ::apave::_AP_VARS(ProSplash,after) [list]
rename ::after ::ProSplash_after
proc ::after {args} {
    lappend ::apave::_AP_VARS(ProSplash,after) $args
}

and this:

rename ::after {}
rename ::ProSplash_after ::after
foreach aftargs $::apave::_AP_VARS(ProSplash,after) {
    after {*}$aftargs
}
unset ::apave::_AP_VARS(ProSplash,after)

fixed the issue, but obviously it brings the initial issue with update re-entrancy back