Re: Finally found one.
On Oct 3, 2012, at 8:47 AM, Mark Wieder wrote: John- Tuesday, October 2, 2012, 11:12:58 PM, you wrote: Pressing the stop button just makes another call to the handler, it doesn't cancel the scheduled message - it's still there and will still fire. The problem, as I see it, is that the documentation incorrectly states that exit to top will cancel pending messages, and that's not the case. Thank goodness as I use that all the time. Best regards, Mark Talluto http://www.canelasoftware.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Hi, Craig. There's no message build up : every time you send a 'showRandoms tSecs', you schedule another 'showRandoms tSecs' if your time check is true, so there's one pending. Pressing the stop button just makes another call to the handler, it doesn't cancel the scheduled message - it's still there and will still fire. When you send 'showRandoms 0', the existing scheduled message is still 'showRandoms x' - it still has it's random number as the tSecs parameter. On 03/10/2012 02:15, dunb...@aol.com wrote: John. Just read your post. I came to the same conclusion. See the last entry in the thread in the forums. But it seems like each time a pending message is queued, a message is sent, so I do not see why these should build up. But I posted an example, similar to your thinking, and it obviously is the reason behind it all. But as Bernd notes, why the exit to top doesn't kill everything is still a mystery... Craig Newman -Original Message- From: John Craig j...@splash21.com To: How to use LiveCode use-livecode@lists.runrev.com Sent: Tue, Oct 2, 2012 4:43 pm Subject: Re: Finally found one. Hi, Craig. Looks like the trouble is that you've always got a pending message, so after you press stop, there's another message fired immediately to start things rolling again. try this handler in the card; command cancelMessages pMessages -- cancel any pending messages in the pMessages list if pMessages = empty then exit cancelMessages put the pendingMessages into tPending repeat for each line tMsg in tPending put item 1 of tMsg into tID put item 3 of tMsg into tName if tName is among the items of pMessages then cancel tID end repeat end cancelMessages and change your showRandoms command to; on showRandoms tSecs put random(99) if tSecs = 0 then cancelMessages showRandoms exit to top end if if tSecs the seconds then send showRandoms tSecs to me in 10 millisecs end showRandoms HTH :) On 02/10/2012 03:25, dunb...@aol.com wrote: Finally found reproducible scripts that work as advertised when stepping through in the deBugger, but do not when simply run. This gremlin has been sighted, like the Yeti, by nominally sane people, but never caught. Make two buttons. Name one start. Name the other stop. in btn start: on mouseUp put the seconds + 8 into tSecs showrandoms tSecs end mouseUp In btn stop: on mouseup send showRandoms 0 to this card end mouseup In the card script: on showRandoms tSecs put random(99) if tSecs = 0 then exit to top end if if tSecs the seconds then send showRandoms tSecs to me in 0 millisecs end showRandoms Try it. If you press the start button, you get random numbers in msg for eight seconds. If you press the stop not while this is going on, nothing happens. If you place a breakpoint at the exit to top line in the card script. the handler is caught there, and if you then step through, you exit. The stop button resets the variable tSecs to a value that will force showRandoms to end. And it does, but only if you step through, not if you run it. The variable watcher shows a 0 as the value of tSecs, as it should, and the conditional tosses you out of the handler. As it should. But not in a normal run, only in the debugger. I have been chasing this since 1987. I am not crazy. I have pictures. I will start a support group. Craig Newman ___ use-livecode mailing list use-livecode@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@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Mark Wieder wrote: Scott- Yes to all the above with the exception that I'm not sure send xyz to me in 0 milliseconds gives any time for other messages to get through. It seems to, at least with this test: 1 card, two buttons. Script of btn A: on mouseUp global g put true into g end mouseUp Script of btn B: on mouseUp global g put empty into i repeat forever add 1 to i if g is not empty then exit to top wait 0 with messages put i end repeat end mouseUp Click on btn B, enjoy the number incrementing in the Message Box for a while, then click on btn A - btn B's script stops. I believe any use of with messages will queue messages to be handled at first idle or the earliest timer expiration, whichever occurs first. So with a timer set to a delay of zero, this still applies just with the shortest possible delay. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
John- Tuesday, October 2, 2012, 11:12:58 PM, you wrote: Pressing the stop button just makes another call to the handler, it doesn't cancel the scheduled message - it's still there and will still fire. The problem, as I see it, is that the documentation incorrectly states that exit to top will cancel pending messages, and that's not the case. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Scott- Tuesday, October 2, 2012, 9:26:31 PM, you wrote: Mark: One thing worth noting is that send xyz to me in 0 millisecs can allow screen updates and other events to take place, while attempts to do the same in a repeat loop may not. So I'm pretty sure other events will take place before the send is executed. This is why long running sessions of send with a specific interval can eventually get thrown off. Interesting distinction. Thanks. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
RE: Finally found one.
I reported this on this exit to top thing on this list back in July. Is it a Engine or Documentation bug? Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net The problem, as I see it, is that the documentation incorrectly states that exit to top will cancel pending messages, and that's not the case. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
This is actually very informative. I also was under the impression that exit to top meant stop everything. I thought it was the equivalent of a kill command. It seems another nuance of Livetalk (is that what we are calling it now) has surfaced. Bob On Oct 2, 2012, at 7:11 PM, Scott Rossi wrote: Not speaking as an authority, just from my own experienceŠ exit xyz exits the current handler, and allows a calling handler to continue executing, if present exit to top exits and stops executing the current handler and any calling handler if present; any pending messages will be sent ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Apparently we now need a kill command that stops everything! Bob On Oct 3, 2012, at 8:47 AM, Mark Wieder wrote: John- Tuesday, October 2, 2012, 11:12:58 PM, you wrote: Pressing the stop button just makes another call to the handler, it doesn't cancel the scheduled message - it's still there and will still fire. The problem, as I see it, is that the documentation incorrectly states that exit to top will cancel pending messages, and that's not the case. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
On 10/3/12 10:47 AM, Mark Wieder wrote: John- Tuesday, October 2, 2012, 11:12:58 PM, you wrote: Pressing the stop button just makes another call to the handler, it doesn't cancel the scheduled message - it's still there and will still fire. The problem, as I see it, is that the documentation incorrectly states that exit to top will cancel pending messages, and that's not the case. I think it's a poor description; what it means is pending handlers. It should be changed. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Mark. I thought of that, but believed that the send in time, where I even increased the time value to, say, 100 ticks, would be more than enough to allow the engine to rest. So I am misunderstanding the two paths. I see clearly what wait with messages does. But I am trying to avoid wait in general. This from an old HC user. But I thought that send in time also placed control back in the hands of the engine (the message pending) for the specified interval. What else is going on during that time? There is no loop. The handler ends, the message is queued, and I would have thought that I can invoke a new instance of that handler from another source, like clicking a button. This was derived from a post I made on the forum. I tried something like this, and failed, eventually setting a custom property and checking its value to allow the poster to do just what I mentioned. Thanks, Craig -Original Message- From: Mark Wieder mwie...@ahsoftware.net To: How to use LiveCode use-livecode@lists.runrev.com Sent: Tue, Oct 2, 2012 1:10 am Subject: Re: Finally found one. Craig- Monday, October 1, 2012, 7:25:49 PM, you wrote: [bunch of stuff deleted] Try it. If you press the start button, you get random numbers in msg for eight seconds. If you press the stop not while this is going on, nothing happens. You need to give the engine some room to breathe. Insert the line wait 0 milliseconds with messages at the start of your showRandoms function. The with messages part will allow the engine a chance to look around and see if any events have occurred (as for instance someone pressing the Stop button). Otherwise you've coded up a loop that's so tight the engine will never see the mouseUp (or any other) message. When you're running this in the debugger there are a lot of engine events happening - your actual code is only a small fraction of that, and the engine is paying attention to everything in the environment. That's why your mouseclicks get registered. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Mark. I had not even time to try the wait with messages thing, when I read Bernd's reply in the forum (I posted there as well). Check it out. Now I have to go experiment some more. Craig -Original Message- From: dunbarx dunb...@aol.com To: use-livecode use-livecode@lists.runrev.com Sent: Tue, Oct 2, 2012 9:49 am Subject: Re: Finally found one. Mark. I thought of that, but believed that the send in time, where I even increased the time value to, say, 100 ticks, would be more than enough to allow the engine to rest. So I am misunderstanding the two paths. I see clearly what wait with messages does. But I am trying to avoid wait in general. This from an old HC user. But I thought that send in time also placed control back in the hands of the engine (the message pending) for the specified interval. What else is going on during that time? There is no loop. The handler ends, the message is queued, and I would have thought that I can invoke a new instance of that handler from another source, like clicking a button. This was derived from a post I made on the forum. I tried something like this, and failed, eventually setting a custom property and checking its value to allow the poster to do just what I mentioned. Thanks, Craig -Original Message- From: Mark Wieder mwie...@ahsoftware.net To: How to use LiveCode use-livecode@lists.runrev.com Sent: Tue, Oct 2, 2012 1:10 am Subject: Re: Finally found one. Craig- Monday, October 1, 2012, 7:25:49 PM, you wrote: [bunch of stuff deleted] Try it. If you press the start button, you get random numbers in msg for eight seconds. If you press the stop not while this is going on, nothing happens. You need to give the engine some room to breathe. Insert the line wait 0 milliseconds with messages at the start of your showRandoms function. The with messages part will allow the engine a chance to look around and see if any events have occurred (as for instance someone pressing the Stop button). Otherwise you've coded up a loop that's so tight the engine will never see the mouseUp (or any other) message. When you're running this in the debugger there are a lot of engine events happening - your actual code is only a small fraction of that, and the engine is paying attention to everything in the environment. That's why your mouseclicks get registered. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Craig- I thought of that, but believed that the send in time, where I even increased the time value to, say, 100 ticks, would be more than enough to allow the engine to rest. It's not a matter of giving the engine time to rest. See below. I see clearly what wait with messages does. No, I do think you're missing the point. It's the with messages part that's important, not the wait part. It doesn't matter how long you wait - if you omit the messages part the engine still won't be looking for other events. With messages says look around and see what other messages may have been triggered before continuing. As in, someone might have clicked a button. Or a message may have come in from another control. Or another timer has expired. Or... But I am trying to avoid wait in general Waiting for 0 milliseconds is essentially not waiting. It just gives us something to tack the with messages part onto. So don't be afraid of waiting for no time. The overhead of checking for messages will take up more time than the wait statement and you won't even notice it. -- Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
On 10/2/12 12:49 PM, Mark Wieder wrote: Craig- I thought of that, but believed that the send in time, where I even increased the time value to, say, 100 ticks, would be more than enough to allow the engine to rest. It's not a matter of giving the engine time to rest. See below. I added wait 0 with messages to Craig's card handler and it didn't work. :( I've been tinkering with it and I can't find anything so far that makes it work. I did think that sending a message in time allows a brief idle state where the engine would pick up any pending user actions. I've used it with a 0 millisecond send in order to force events to go through. In this case I can't find anything that allows the Stop button to work. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Jacque, Try inside opencard : if MyStartUpVar is not a number then send opencard to this cd in 0 milliseconds put 1 into MyStartUpVar end if or : something with message without waiting Best, Pierre Le 2 oct. 2012 à 22:06, J. Landman Gay a écrit : On 10/2/12 12:49 PM, Mark Wieder wrote: Craig- I thought of that, but believed that the send in time, where I even increased the time value to, say, 100 ticks, would be more than enough to allow the engine to rest. It's not a matter of giving the engine time to rest. See below. I added wait 0 with messages to Craig's card handler and it didn't work. :( I've been tinkering with it and I can't find anything so far that makes it work. I did think that sending a message in time allows a brief idle state where the engine would pick up any pending user actions. I've used it with a 0 millisecond send in order to force events to go through. In this case I can't find anything that allows the Stop button to work. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Pierre Sahores mobile : 06 03 95 77 70 www.sahores-conseil.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Hi, Craig. Looks like the trouble is that you've always got a pending message, so after you press stop, there's another message fired immediately to start things rolling again. try this handler in the card; command cancelMessages pMessages -- cancel any pending messages in the pMessages list if pMessages = empty then exit cancelMessages put the pendingMessages into tPending repeat for each line tMsg in tPending put item 1 of tMsg into tID put item 3 of tMsg into tName if tName is among the items of pMessages then cancel tID end repeat end cancelMessages and change your showRandoms command to; on showRandoms tSecs put random(99) if tSecs = 0 then cancelMessages showRandoms exit to top end if if tSecs the seconds then send showRandoms tSecs to me in 10 millisecs end showRandoms HTH :) On 02/10/2012 03:25, dunb...@aol.com wrote: Finally found reproducible scripts that work as advertised when stepping through in the deBugger, but do not when simply run. This gremlin has been sighted, like the Yeti, by nominally sane people, but never caught. Make two buttons. Name one start. Name the other stop. in btn start: on mouseUp put the seconds + 8 into tSecs showrandoms tSecs end mouseUp In btn stop: on mouseup send showRandoms 0 to this card end mouseup In the card script: on showRandoms tSecs put random(99) if tSecs = 0 then exit to top end if if tSecs the seconds then send showRandoms tSecs to me in 0 millisecs end showRandoms Try it. If you press the start button, you get random numbers in msg for eight seconds. If you press the stop not while this is going on, nothing happens. If you place a breakpoint at the exit to top line in the card script. the handler is caught there, and if you then step through, you exit. The stop button resets the variable tSecs to a value that will force showRandoms to end. And it does, but only if you step through, not if you run it. The variable watcher shows a 0 as the value of tSecs, as it should, and the conditional tosses you out of the handler. As it should. But not in a normal run, only in the debugger. I have been chasing this since 1987. I am not crazy. I have pictures. I will start a support group. Craig Newman ___ use-livecode mailing list use-livecode@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
On 10/2/12 3:42 PM, John Craig wrote: Hi, Craig. Looks like the trouble is that you've always got a pending message, so after you press stop, there's another message fired immediately to start things rolling again. try this handler in the card; command cancelMessages pMessages -- cancel any pending messages in the pMessages list if pMessages = empty then exit cancelMessages put the pendingMessages into tPending repeat for each line tMsg in tPending put item 1 of tMsg into tID put item 3 of tMsg into tName if tName is among the items of pMessages then cancel tID end repeat end cancelMessages and change your showRandoms command to; on showRandoms tSecs put random(99) if tSecs = 0 then cancelMessages showRandoms exit to top end if if tSecs the seconds then send showRandoms tSecs to me in 10 millisecs end showRandoms HTH :) Ah, that's it. I tried handling pending messages differently but in the wrong place: on showRandoms tSecs put random(99) wait 0 with messages if tSecs = 0 then exit to top end if if tSecs the seconds and showRandoms is not in the pendingmessages then send showRandoms tSecs to me in 5 end showRandoms Your way works. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
J. Landman Gay jacque@... writes: I added wait 0 with messages to Craig's card handler and it didn't work. :( I've been tinkering with it and I can't find anything so far that makes it work. OK - granted I've only tried it on Windows and linux so far. There may be some other platform out there. I'll give it a try again when I get back to my mac. -- Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Mark. I know that. I know that wait is blocking without the with messages part. I found this a terrific and profound improvement over HC. I've been around the block, you know. What I am missing, though, is what happens during the time a script has finished, and a new message is sent in time. I see no blocking intrinsic to any portion of such a construct. Two buttons. In one, place on mouseUp put random(99) if the optionKey is down then exit to top send mouseUp to me in 1 second end mouseUp In btn 2: on mouseUp set the loc of me to the mouseLoc end mouseUp Press button 1. You get a second counter. Any time you wish, you may click on the other button and watch it jump to the mouseLoc. As advertised, and as i understood it. In original sample script, why isn't the secondary message caught by the working handler while it is running, as opposed to while it is under the control of the debugger? It does not matter if I send the message back in a longer time. So to simplify, two more buttons. In the first: on mouseUp showRandoms 3 end mouseUp In the second: on mouseUp showRandoms 0 end mouseUp in the card script: on showRandoms var put random(99) if var = 0 then repeat for each line tLine in the pendingMessages cancel item 1 of tLine end repeat exit to top end if send showRandoms 3 to this card in 60 end mouseup Does the existence of a pending message block a new call to that very handler from another source? The stop works if the code runs as shown. It fails if the repeat construct is commented out. That is what I am trying to understand. Craig -Original Message- From: Mark Wieder mwie...@ahsoftware.net To: use-livecode use-livecode@lists.runrev.com Sent: Tue, Oct 2, 2012 1:52 pm Subject: Re: Finally found one. Craig- I thought of that, but believed that the send in time, where I even increased the time value to, say, 100 ticks, would be more than enough to allow the engine to rest. It's not a matter of giving the engine time to rest. See below. I see clearly what wait with messages does. No, I do think you're missing the point. It's the with messages part that's important, not the wait part. It doesn't matter how long you wait - if you omit the messages part the engine still won't be looking for other events. With messages says look around and see what other messages may have been triggered before continuing. As in, someone might have clicked a button. Or a message may have come in from another control. Or another timer has expired. Or... But I am trying to avoid wait in general Waiting for 0 milliseconds is essentially not waiting. It just gives us something to tack the with messages part onto. So don't be afraid of waiting for no time. The overhead of checking for messages will take up more time than the wait statement and you won't even notice it. -- Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
John. Just read your post. I came to the same conclusion. See the last entry in the thread in the forums. But it seems like each time a pending message is queued, a message is sent, so I do not see why these should build up. But I posted an example, similar to your thinking, and it obviously is the reason behind it all. But as Bernd notes, why the exit to top doesn't kill everything is still a mystery... Craig Newman -Original Message- From: John Craig j...@splash21.com To: How to use LiveCode use-livecode@lists.runrev.com Sent: Tue, Oct 2, 2012 4:43 pm Subject: Re: Finally found one. Hi, Craig. Looks like the trouble is that you've always got a pending message, so after you press stop, there's another message fired immediately to start things rolling again. try this handler in the card; command cancelMessages pMessages -- cancel any pending messages in the pMessages list if pMessages = empty then exit cancelMessages put the pendingMessages into tPending repeat for each line tMsg in tPending put item 1 of tMsg into tID put item 3 of tMsg into tName if tName is among the items of pMessages then cancel tID end repeat end cancelMessages and change your showRandoms command to; on showRandoms tSecs put random(99) if tSecs = 0 then cancelMessages showRandoms exit to top end if if tSecs the seconds then send showRandoms tSecs to me in 10 millisecs end showRandoms HTH :) On 02/10/2012 03:25, dunb...@aol.com wrote: Finally found reproducible scripts that work as advertised when stepping through in the deBugger, but do not when simply run. This gremlin has been sighted, like the Yeti, by nominally sane people, but never caught. Make two buttons. Name one start. Name the other stop. in btn start: on mouseUp put the seconds + 8 into tSecs showrandoms tSecs end mouseUp In btn stop: on mouseup send showRandoms 0 to this card end mouseup In the card script: on showRandoms tSecs put random(99) if tSecs = 0 then exit to top end if if tSecs the seconds then send showRandoms tSecs to me in 0 millisecs end showRandoms Try it. If you press the start button, you get random numbers in msg for eight seconds. If you press the stop not while this is going on, nothing happens. If you place a breakpoint at the exit to top line in the card script. the handler is caught there, and if you then step through, you exit. The stop button resets the variable tSecs to a value that will force showRandoms to end. And it does, but only if you step through, not if you run it. The variable watcher shows a 0 as the value of tSecs, as it should, and the conditional tosses you out of the handler. As it should. But not in a normal run, only in the debugger. I have been chasing this since 1987. I am not crazy. I have pictures. I will start a support group. Craig Newman ___ use-livecode mailing list use-livecode@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Craig- Tuesday, October 2, 2012, 5:49:03 PM, you wrote: I've been around the block, you know. LOL. You and me both, buddy. Does the existence of a pending message block a new call to that very handler from another source? The stop works if the code runs as shown. It fails if the repeat construct is commented out. That is what I am trying to understand. In spite of the documentation, I remain unconvinced that exit to top really cancels pending messages. What I see happening in the absence of a wait with messages statement is that the exit to top does exit, but leaves a call to showRandoms still pending. Then the pending call executes and off you go again. To demonstrate this, change the card script to on showRandoms tSecs put random(99) after msg if tSecs = 0 then put exiting to top cr after msg exit to top end if put still working cr after msg if tSecs the seconds then send showRandoms tSecs to me in 500 millisecs end showRandoms and you'll see the still working message appear even after the exiting to top message. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Jacque- Tuesday, October 2, 2012, 1:56:30 PM, I wrote: OK - granted I've only tried it on Windows and linux so far. There may be some other platform out there. I'll give it a try again when I get back to my mac. OK - no surprise here. Same result on OSX. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Jacque- Tuesday, October 2, 2012, 1:50:27 PM, you wrote: Ah, that's it. I tried handling pending messages differently but in the wrong place: on showRandoms tSecs put random(99) wait 0 with messages if tSecs = 0 then exit to top end if if tSecs the seconds and showRandoms is not in the pendingmessages then send showRandoms tSecs to me in 5 end showRandoms You actually don't need the pendingmessages test if you've got the wait 0 with messages line in there. Unless you hit the start button multiple times there will only ever be one showRandoms message pending because it's queued up at the end of the previous one. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Not speaking as an authority, just from my own experience exit xyz exits the current handler, and allows a calling handler to continue executing, if present exit to top exits and stops executing the current handler and any calling handler if present; any pending messages will be sent send xyz to me in 200 millisecs allows other messages/events to take place wait until condition with messages allows other messages/events to take place (in what I think of as being an ultra-tight repeat loop) If you want to cancel a message that has been sent in time, you can: 1) grab the id upon sending the message to be canceled later 2) do a repeat for each in the pending messages to find the line containing the message name and cancel it 3) cancel all the pendingMessages Hope this helps. Regards, Scott Rossi Creative Director Tactile Media, UX Design On 10/2/12 6:15 PM, dunb...@aol.com dunb...@aol.com wrote: But as Bernd notes, why the exit to top doesn't kill everything is still a mystery... ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
On 10/2/12 8:29 PM, Mark Wieder wrote: Jacque- Tuesday, October 2, 2012, 1:50:27 PM, you wrote: Ah, that's it. I tried handling pending messages differently but in the wrong place: on showRandoms tSecs put random(99) wait 0 with messages if tSecs = 0 then exit to top end if if tSecs the seconds and showRandoms is not in the pendingmessages then send showRandoms tSecs to me in 5 end showRandoms You actually don't need the pendingmessages test if you've got the wait 0 with messages line in there. Unless you hit the start button multiple times there will only ever be one showRandoms message pending because it's queued up at the end of the previous one. Yeah. I pasted the wrong one of many attempts that were stacked up in the script editor. Some of them had lots of commented lines and I just uncommented everything and pasted. That's my story and I'm sticking with it. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Jacque- Tuesday, October 2, 2012, 7:12:32 PM, you wrote: Yeah. I pasted the wrong one of many attempts that were stacked up in the script editor. Some of them had lots of commented lines and I just uncommented everything and pasted. That's my story and I'm sticking with it. Copy is no problem. Paste always get me in trouble. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
On 10/2/12 7:49 PM, dunb...@aol.com wrote: Does the existence of a pending message block a new call to that very handler from another source? The stop works if the code runs as shown. It fails if the repeat construct is commented out. That is what I am trying to understand. The exit to top will abort the current handler and all of the handlers that called the current one (basically everything that's currently running.) Pending messages aren't running yet so there is nothing to abort there. As soon as the abort happens, the waiting pending message fires and the showRandoms handler starts up again. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Scott- Yes to all the above with the exception that I'm not sure send xyz to me in 0 milliseconds gives any time for other messages to get through. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Mark: One thing worth noting is that send xyz to me in 0 millisecs can allow screen updates and other events to take place, while attempts to do the same in a repeat loop may not. So I'm pretty sure other events will take place before the send is executed. This is why long running sessions of send with a specific interval can eventually get thrown off. Regards, Scott Rossi Creative Director Tactile Media, UX Design On Oct 2, 2012, at 7:28 PM, Mark Wieder mwie...@ahsoftware.net wrote: Scott- Yes to all the above with the exception that I'm not sure send xyz to me in 0 milliseconds gives any time for other messages to get through. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Finally found one.
Finally found reproducible scripts that work as advertised when stepping through in the deBugger, but do not when simply run. This gremlin has been sighted, like the Yeti, by nominally sane people, but never caught. Make two buttons. Name one start. Name the other stop. in btn start: on mouseUp put the seconds + 8 into tSecs showrandoms tSecs end mouseUp In btn stop: on mouseup send showRandoms 0 to this card end mouseup In the card script: on showRandoms tSecs put random(99) if tSecs = 0 then exit to top end if if tSecs the seconds then send showRandoms tSecs to me in 0 millisecs end showRandoms Try it. If you press the start button, you get random numbers in msg for eight seconds. If you press the stop not while this is going on, nothing happens. If you place a breakpoint at the exit to top line in the card script. the handler is caught there, and if you then step through, you exit. The stop button resets the variable tSecs to a value that will force showRandoms to end. And it does, but only if you step through, not if you run it. The variable watcher shows a 0 as the value of tSecs, as it should, and the conditional tosses you out of the handler. As it should. But not in a normal run, only in the debugger. I have been chasing this since 1987. I am not crazy. I have pictures. I will start a support group. Craig Newman ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Finally found one.
Craig- Monday, October 1, 2012, 7:25:49 PM, you wrote: [bunch of stuff deleted] Try it. If you press the start button, you get random numbers in msg for eight seconds. If you press the stop not while this is going on, nothing happens. You need to give the engine some room to breathe. Insert the line wait 0 milliseconds with messages at the start of your showRandoms function. The with messages part will allow the engine a chance to look around and see if any events have occurred (as for instance someone pressing the Stop button). Otherwise you've coded up a loop that's so tight the engine will never see the mouseUp (or any other) message. When you're running this in the debugger there are a lot of engine events happening - your actual code is only a small fraction of that, and the engine is paying attention to everything in the environment. That's why your mouseclicks get registered. -- -Mark Wieder mwie...@ahsoftware.net ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
