Scripts that are already running

Mike Bonner bonnmike at gmail.com
Fri Sep 24 13:33:18 EDT 2010


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, <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
> _______________________________________________
> 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
>



More information about the use-livecode mailing list