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"
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.
g its value to
allow the poster to do just what I mentioned.
Thanks,
Craig
-Original Message-
From: Mark Wieder
To: How to use LiveCode
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 delete
bject: 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 &
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.
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 adde
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
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 li
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 an
J. Landman Gay 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
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
To: use-livecode
Sent: Tu
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
To: How to use LiveCode
Sent: Tue, Oct 2, 2012 4:43 pm
Subject: Re: Finally found one.
Hi, Cra
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
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...@ahsoftwa
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
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
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
e
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 prob
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 wil
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
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
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
To: How to use LiveCode
Sent: Tue, Oct 2, 2012 4:43 pm
Subject: Re: Finally found one.
Hi, Craig. Looks like
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
en
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" w
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 b
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 pen
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
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'
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
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
30 matches
Mail list logo
