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
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
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'
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
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
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
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
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
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: 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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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.
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 &
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
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.
29 matches
Mail list logo
