Scripts that are already running

zryip theSlug zryip.theslug at gmail.com
Fri Sep 24 14:32:04 EDT 2010


On Fri, Sep 24, 2010 at 7:15 PM,  <DunbarX at aol.com> wrote:
> Jacques, et al.
>
> The "wait with messages", which I know about, is compact and cool. But that
> code needs to reside within the running handler. As do, in their own way,
> all the other comments from everyone. For example, BonnMike notes you can
> read the state of a property while a handler is running. Certainly you can, but
> only from within the handler.
>
> I was asking if any state of the machine can be accessed from outside a
> running handler. I read from all the responses, as I thought, that it cannot.
>
> Say a variable is gettinig incremented in a repeat loop. Its state changes
> as the loop progresses. Can this state be returned to the engine from some
> externally running process, one that would be able to monitor handler
> variables on the fly. It would require, essentially, that the handler be
> interrupted continuously. I don't think this is part of the xTalk world. I am not sure
> about other procedural languages.
>
> This all came about because someone wanted a single universal watchdog on
> his stack. He had several handlers in several places, all of which could
> create a condition he wanted to act upon. So the "send in time" handler fit that
> bill. If he created yet another such handler somewhere, it would be
> covered. But it occurred to be that if the condition was met and the handler still
> had much to do and might take a long time to do it, then the condition could
> not be dealt with until that handler ends. It seemed intriguing to think
> that something could monitor, say, the state of variables, from outside the
> handler while it was running.
>
> Anyone think this is a useful, perhaps monumental, feature?
>
> Craig

The problem here, I think, is the scope of the variable:

A local variable exists only in its handler or function so you can't
read it from the outside.

That we can call a super local variable exists in the script itself
and handlers in the same script can read or write it
If you need to read a variable in a handler from another script you will failed

A global variable exists everywhere. The problem with this kind of
variable is that it could be overrided by another variable from the
outside. It was an old HC problem to take in care.

The property is an interesting way to explore because:
- it is protected
- it is available everywhere from the outside.

But in each case and because of the scope of the variable you will not
able to read the state of a variable from the outside if you not
manage something in the handler you have to observe.

In some other language, it is possible to read (or write) a variable
by knowing its name with a specific command. That is a handy method to
pass or force a value in a process. But LiveCode is not
multiprocessing.


Regards,
-- 
-Zryip TheSlug- wish you the best! 8)
http://www.aslugontheroad.co.cc



More information about the use-livecode mailing list