On Fri, Sep 24, 2010 at 7:15 PM, <[email protected]> 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 [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
