Isn't this what your'e asking.. Put the following script in button 1 local tRunning on mouseUp if tRunning is empty then put false into tRunning put not tRunning into tRunning set the label of me to "Running: " & tRunning put 1 into tCount repeat while tRunning wait 1 millisecond with messages set the myProp of me to tCount put (tCount + 1) wrap 100 into tCount end repeat end mouseUp
And this following script in button 2 local tRunning on mouseUp if tRunning is empty then put false into tRunning put not tRunning into tRunning set the label of me to "Scanning: " & tRunning send checkState to me in 1 millisecond end mouseUp command checkstate if tRunning then if the myProp of button 1 > 50 then set the enabled of button 1 to false else set the enabled of button 1 to true end if send "checkState" to me in 1 millisecond end if end checkstate Click button 1 to start it looping. Click button 2 to start it scanning. Button 2 will toggle the state of button 1 based on the current value of myProp with a send in time. Will it work if button 2 is a repeat loop also? Not sure On Fri, Sep 24, 2010 at 11:15 AM, <dunb...@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 > _______________________________________________ > use-revolution mailing list > use-revolution@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution > _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution