Scripts that are already running

Jonathan Lynch jonathandlynch at gmail.com
Fri Sep 24 13:49:55 EDT 2010


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



-- 
Do all things with love



More information about the use-livecode mailing list