Stopping a script

[Tore Nilsen]

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