Stopping a script

Mike Bonner bonnmike at gmail.com
Tue Jun 28 18:27:26 EDT 2016


Since you're using a repeat until.. You can do repeat until (your first
requirement)  or not myflag

where on mouseenter you set myflag to true
on mouseleave you set it to false.

As a quick example (not using a flag, but even so you get the idea...)
repeat until the thumbpos of me  >= the endvalue of me or the shiftkey is
down
      set the thumbpos of me to the thumbpos of me + 1
      wait 10 millisec with messages
   end repeat

The above repeat loop fills up a progress bar.
You'll want a wait with messages somewhere in your repeat loop otherwise
there won't be time to set a flag.  (Not really necessary here because it
checks the shiftkey on each loop, but.. well ok it is necessary for the
screen to update and slow down the fill of the progress bar)

Even a wait 0 with messages should allow for your mouseleave to fire and
set your flag.

Also, if you're using small enough move increments, it would probably work
just as well to "set the loc.." of your button to the new location.  (or if
you don't mind it "jumping" around)


On Tue, Jun 28, 2016 at 1:57 PM, Tore Nilsen <tore.nilsen at me.com> wrote:

> Agreed. The send moveFigure to me in the moveFigure handler could be
> removed if you only want the figure to move once each time the mouse enters
> the object.
>
> I handed my students a stack with a similar script where a button would
> jump to a new loc each time the tried to press it. (The loc was randomly
> chosen though)
> They had to figure out how to stop this from happening, without deleting
> any of the code I had written.
>
>
> Tore
> > 28. jun. 2016 kl. 21.49 skrev Dar Scott <dsc at swcp.com>:
> >
> > This could end up with several copies of moveFigure in pending
> messages.  Don't resend if the flag is false.  Or, cancel the message.
> >
> > (And you might be able to do this with moveStopped instead of send.)
> >
> >> On Jun 28, 2016, at 1:45 PM, Tore Nilsen <tore.nilsen at me.com> wrote:
> >>
> >> The variables needs to be global rather than local if the scripts are
> to be placed in both the card script and the script of the figure that
> should be moved. The first line of the card script and the first line of
> the script in the object should then read:
> >>
> >> global sMoveLine,sMoveSteps,sMove
> >>
> >> Tore
> >>
> >>> 28. jun. 2016 kl. 21.40 skrev Tore Nilsen <tore.nilsen at me.com>:
> >>>
> >>> I am not quite sure I understand what you are trying to do , but I’ll
> have a go at it:
> >>>
> >>> /*This is what I would put into the cardscript*/
> >>>
> >>> local sMoveLine,sMoveSteps,sMove
> >>>
> >>> on openCard
> >>>
> >>> put field "moveSpots" into sMoveSteps --put the coordinates into a
> variable for faster execution of script
> >>>
> >>> put 0 into sMoveLine -- initialising the steps
> >>>
> >>> put "false" into sMove -- initialising a variable to control movement
> >>>
> >>> end openCard
> >>>
> >>>
> >>> /*This would go into the script of the object that should be moved*/
> >>>
> >>> on mouseEnter
> >>>
> >>> put not sMove into sMove -- change the movement control to true
> >>>
> >>> add 1 to sMoveLine -- get the next set of coordinates
> >>>
> >>> send moveFigure to me in x milliseconds --starts/stops the movement
> >>>
> >>> end mouseEnter
> >>>
> >>>
> >>> on moveFigure
> >>>
> >>> if sMove is true then
> >>>
> >>> put line sMoveLine of sMoveSteps into tNewLoc -- finds the new location
> >>>
> >>> move me to tNewLoc in y seconds -- moves to the new location in
> specified time
> >>>
> >>> end if
> >>>
> >>> send moveFigure to me in x milliseconds --starts/stops the movement
> >>>
> >>> end moveFigure
> >>>
> >>>
> >>> on mouseLeave
> >>>
> >>> put "false" into sMove
> >>>
> >>> end mouseLeave
> >>>
> >>>
> >>> Regards Tore
> >>>
> >>>
> >>>
> >>>> 28. jun. 2016 kl. 21.05 skrev dsc at swcp.com:
> >>>>
> >>>> correction:  the walking figure used 'send' not 'move'
> >>>>
> >>>>> On Jun 28, 2016, at 12:59 PM, Dar Scott <dsc at swcp.com> wrote:
> >>>>>
> >>>>> Maybe this is a good time to introduce the event style of
> programming.
> >>>>>
> >>>>> Focus on 'move...without waiting', and 'moveStopped' and maybe
> 'send'.
> >>>>>
> >>>>> Well, if the details allow that.  If using moveStopped makes things
> jerky, then you might need to do something else.  However, I think my
> grandson made a walking stick figure doing this.
> >>>>>
> >>>>> When you stop, not only stop moving but also set a flag so
> moveStopped does not start the next motion.
> >>>>>
> >>>>>
> >>>>>> On Jun 28, 2016, at 12:32 PM, Richmond <richmondmathewson at gmail.com>
> wrote:
> >>>>>>
> >>>>>> I have a *button* which, when I click on it, sends a *graphic
> object* off on a mad journey all over
> >>>>>> a *card* based on reading positions from a*listField*.
> >>>>>>
> >>>>>> I have tried *STOP MOVING* to interrupt that script, but that does
> *NOT* work
> >>>>>> because the graphic is executing a large number of very short
> movements in a cycling
> >>>>>> *REPEAT UNTIL* structure.
> >>>>>>
> >>>>>> Ideally (Ho, Ho, Ho.) I should like to be able to have something
> like this:
> >>>>>>
> >>>>>> the mad movement script starts executing when triggered by a
> *mouseEnter* script
> >>>>>> in the *graphic object* that moves,
> >>>>>>
> >>>>>> and
> >>>>>>
> >>>>>> some sort of *STOP SCRIPT* in a *mouseLeave* script in the same
> *graphic object*.
> >>>>>>
> >>>>>> Now, I know that sounds a bit *bonkers*, but I am writing this on
> behalf of a very bright chap
> >>>>>> who is attending my Summer classes, and I do understand what he is
> trying to achieve.
> >>>>>>
> >>>>>> Richmond.
> >>>>>> _______________________________________________
> >>>>>> use-livecode mailing list
> >>>>>> use-livecode at lists.runrev.com
> >>>>>> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> >>>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> use-livecode mailing list
> >>>>> use-livecode at lists.runrev.com
> >>>>> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> >>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> use-livecode mailing list
> >>>> use-livecode at lists.runrev.com
> >>>> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> >>>> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>>
> >>> _______________________________________________
> >>> use-livecode mailing list
> >>> use-livecode at lists.runrev.com
> >>> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> >>> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> >>
> >> _______________________________________________
> >> use-livecode mailing list
> >> use-livecode at lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> >
> >
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



More information about the use-livecode mailing list