One way to simulate a repeat loop would be to have something like this: on myHandler Do whatever the handler does send testForStateChange in 0 milleseconds send myHandler to me in 100 milliseconds end if on TestForStateChange Do whatever needs to be done for the test if tTest = tRequirement then exit to top end if end TestForStateChange
On Fri, Sep 24, 2010 at 1:33 PM, Mike Bonner <bonnm...@gmail.com> wrote: > 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 > -- Do all things with love _______________________________________________ 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