QTip: [after cancel] to return non void

[Uwe Klein]

Hi,
This is to either remove BrainLint or grow into a TIP:

for "wait for action or timeout" functionality i would prefer to use

set timeout_id [ after $timeout { set ::myvar {} } ]
initate_action ::myvar
vwait ::myvar
if {[ after cancel $timeout_id ]} {
# process actionresult
} else {
# process timeout
}

but [after cancel $id ] returns void. ( the relevant info exists in the
c function, but is discarded. )

OK, i could use [ after info $id ] .. but this returns an ERROR and has
to be
caught if the after event has already run:

if {![ catch {after info $timeout_id} cerr ]} {
# and i have still to canccel it!
after cancel $timeout_id
} ..

there are a couple permutations to achieve the same goal.
They all have in common that they use more than one function call
and are not atomic.( i.e. _info on timeout_ and _cancelation_ are
disjunct )

I have: patch, test, manpage

G!
UK

--
Uwe Klein [mailto:uwe-...@foni.net]
KLEIN MESSGERAETE Habertwedt 1
D-24376 Groedersby b. Kappeln, GERMANY
phone: +49 4642 920 123 FAX: +49 4642 920 125

[Jeffrey Hobbs]

Uwe Klein wrote:
...

> for "wait for action or timeout" functionality i would prefer to use
>
> set timeout_id [ after $timeout { set ::myvar {} } ]
> initate_action ::myvar
> vwait ::myvar
> if {[ after cancel $timeout_id ]} {
> # process actionresult
> } else {
> # process timeout
> }

I assume that you have initiate_action setting ::myvar as well, and
you just want to see if it was your timeout firing that did it?
The usual method that to handle this is:

after $timeout { set ::myvar TIMEOUT }
initate_action ::myvar
vwait ::myvar
if {$::myvar == "TIMEOUT"} {
# process timeout
} else {
# process actionresult
}

which actually becomes slightly simpler than your example. Is this
something that you don't want to do?

--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions

[Uwe Klein]

Jeffrey Hobbs wrote:
>
> Uwe Klein wrote:
> ...
> > for "wait for action or timeout" functionality i would prefer to use
> >
> > set timeout_id [ after $timeout { set ::myvar {} } ]
> > initate_action ::myvar
> > vwait ::myvar
> > if {[ after cancel $timeout_id ]} {
> > # process actionresult
> > } else {
> > # process timeout
> > }
>
> I assume that you have initiate_action setting ::myvar as well, and
> you just want to see if it was your timeout firing that did it?
> The usual method that to handle this is:
>
> after $timeout { set ::myvar TIMEOUT }
> initate_action ::myvar
> vwait ::myvar
> if {$::myvar == "TIMEOUT"} {
> # process timeout
> } else {
> # process actionresult

after cancel $...
can't ommit this ^^^^^^^^^^^^^^^^
for a clean table you would still have to cancel the after event
if this code snipet is used regularly. Otherwise the still running
after event will disturb the next invocation.

> }
>
> which actually becomes slightly simpler than your example. Is this
> something that you don't want to do?

jein ( yes and no )
my motivation here was not that i can not have the functionality i want.

I just found it _unintuitive_ that [ after cancel id ] returns no
information.
The information is there, but it is discarded in the c function.
Or is there a deep reason why it is the way it is?

set id [ after $timeout ...]
.....
if {[ after cancel $id ]} ..
is IMHO more intuitiv, selfcontained and cannot be broken by inserting
code between
[ vwait ..] and [ after cancel ]
and you get information that can be useful. Discarding it would now be
the users option.

After thinking about this some more i would even go as far as wanting
[ after cancel $id ] to return the time remaining and -1 if there was no
event to cancel.