Scripts that are already running

[wayne durden]

I think the scenario Dunbar is describing can be handled with a combination
of an overhead watcher script that includes a send in time message to call
itself every so often, and a global variable or variables which are being
set in the sub-condition checking scripts which may contain repeat forever
loops with wait with messages which will allow the overhead watcher to kick
in and check the global(s)...

Wayne

On Fri, Sep 24, 2010 at 2:32 PM, zryip theSlug <zryip.theslug at gmail.com>wrote:

> 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
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>