Oh, external process. If its on osx, possible to do an appleevent check? Like one of these in rev. send "whatyouwanttocheck" to program "programname"
On Fri, Sep 24, 2010 at 11:33 AM, Mike Bonner <[email protected]> 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, <[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 >> _______________________________________________ >> 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 >> > > _______________________________________________ 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
