Re: assess what subroutines are currently being called

I'll see if I can locate this function.  This sounds interesting in that 
I can at least make sure the things like $top->update, 
$output->see('end'), etc are actually updated on the client so that the 
user is aware the client is working as opposed to being locked up during 
an expected delay.

Jim Anderson wrote:
> On Wed, 11 Apr 2007 13:37:31 -0400, listmail wrote:
> > I had assumed that if an event was running a sub and if the client
> > pressed a widget button which also called a sub that the subs would
> > execute in parallel. If it is actually that a button (-command)
> > call would actually have to wait for the event sub (if already
> > running) to return, then this would mean there is no need for what
> > I am attempting.
>
> Correct.  The program can only handle one event at a time.  It won't 
> service another event until you exit the current event.  The exception 
> is if you call a special function (I can't find the name at the 
> moment) that will process any pending requests and then continue with 
> the current event.  This comes in useful if you have a long-running 
> event, and you want the user to be able to trigger other stuff while 
> the long-running event is still going.
>  

--++**==--++**==--++**==--++**==--++**==--++**==--++**==
ptk mailing list
[email protected]
https://mailman.stanford.edu/mailman/listinfo/ptk