On Wed, Oct 26, 2016 at 1:36 AM, Peter TB Brett
wrote:
>
> 1, 3, 5, 7, 2, 6, 4
>
> This _could_ account for the behaviour that Richard is reporting. I know
> that it is fixed in the development branch [1].
At the moment, while I single step through a script, I notice that the
message queue has
THAT is news to me. I thot the queue would clear. Good to know.
Bob S
On Oct 25, 2016, at 22:51 , Monte Goulding
mailto:mo...@appisle.net>> wrote:
So if you had two messages in the queue scheduled for exactly the same time and
only did a wait 0 with messages then only one would be sent.
Chee
I always use dispatch unless I need to send in time.
Bob S
On Oct 25, 2016, at 15:31 , Mark Talluto
mailto:m...@canelasoftware.com>> wrote:
On Oct 25, 2016, at 10:18 AM, Richard Gaskin
mailto:ambassa...@fourthworld.com>> wrote:
Dr. Hawkins wrote:
I (like I assume many others) have a number
On 25/10/2016 21:30, Monte Goulding wrote:
On 26 Oct. 2016, at 6:55 am, Dr. Hawkins wrote:
*unless* there is an opportunity to execute it, such as (exclusively?)
"Wait with messages", at which point the message due is supposed to be
checked.
send in time is supposed to return a message queue
> On 26 Oct. 2016, at 3:26 pm, Dr. Hawkins wrote:
>
>
> ON a "wait 0 with messages", does this effectively put the next line in the
> queue as the last (first? random?) entry for the current (next?)
> millisecond?
I think I'll need an interpreter to understand that question sorry ;-)
>
> I ha
On 10/25/2016 05:29 PM, hh wrote:
send in -the seconds seconds ?
Job has to be done in 1970 ... When I was a young man with curly hair.
In that case you don't want "send *in* "
What you need is "send *to* "
--
Mark Wieder
ahsoftw...@gmail.com
___
On Tue, Oct 25, 2016 at 5:49 PM, Monte Goulding wrote:
>
> send “foo” in 0
> —> insert script taking longer than 1 millisecond here
> send “bar” in -1 millisecond
>
> “bar” will be handled after “foo"
This leads to the next question.
ON a "wait 0 with messages", does this effectively put the n
> On 26 Oct. 2016, at 11:29 am, hh wrote:
>
> send in -the seconds seconds ?
> Job has to be done in 1970 ... When I was a young man with curly hair.
>
> Monte, please build a time machine.
;-)
The issue is this:
send “foo” in 0
—> insert script taking longer than 1 millisecond here
send “ba
send in -the seconds seconds ?
Job has to be done in 1970 ... When I was a young man with curly hair.
Monte, please build a time machine.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and ma
> On 26 Oct. 2016, at 11:13 am, hh wrote:
>
> [1] There is also Jacque's recent(?) info: send may also be called with a
> negative argument in order to overtake the current queue:
>send doIt to stack worker in -1 millisecs
Actually this does not guarantee that the message will be at the fr
... [3] Or try to use
send doIt to stack worker in 0 millisecs
this is 16 times faster than 0 ticks ;-)
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
prefere
[1] There is also Jacque's recent(?) info: send may also be called with a
negative argument in order to overtake the current queue:
send doIt to stack worker in -1 millisecs
[2] Or try to use "call" that has one big advantage:
"call" preserves the target, not "send", not "dispatch"
see http:
On Tue, Oct 25, 2016 at 3:31 PM, Mark Talluto
wrote:
> You might consider using 'dispatch' instead of 'send' if you really want
> it to execute the moment that line shows up. I read somewhere the dispatch
> is more performant anyways.
>
>
to be clear: I would certainly *like* it to happen right
> On Oct 25, 2016, at 10:18 AM, Richard Gaskin
> wrote:
>
> Dr. Hawkins wrote:
>
> > I (like I assume many others) have a number of places with blocks like
> >
> > send doIt to stack worker in 0
> > wait 0 with messages
> > doSomethingElse
> >
> > I'm seeing a situation in which the code hits
On Tue, Oct 25, 2016 at 1:30 PM, Monte Goulding wrote:
> Send in time has does not guarantee when a message will be sent. It’s ASAP
> after the event time. If there is a pending message that should be handled
> before the message you sent then it will be handled and then you will run
> out of tim
> On 26 Oct. 2016, at 6:55 am, Dr. Hawkins wrote:
>
> *unless* there is an opportunity to execute it, such as (exclusively?)
> "Wait with messages", at which point the message due is supposed to be
> checked.
>
> send in time is supposed to return a message queue id of the message,
> meaning it
On Tue, Oct 25, 2016 at 12:28 PM, mwieder wrote:
> That's the way the "send" command works. See the dictionary for details.
>
> If you "send" a command it's executed immediately, before anything else in
> the current handler.
> If you "send in time" it's executed *after* the current handler finis
That's the way the "send" command works. See the dictionary for details.
If you "send" a command it's executed immediately, before anything else in
the current handler.
If you "send in time" it's executed *after* the current handler finishes.
-
--
Mark Wieder
ahsoftw...@gmail.com
--
View
On Tue, Oct 25, 2016 at 10:18 AM, Richard Gaskin wrote:
> Dr. Hawkins wrote:
>
> > I (like I assume many others) have a number of places with blocks like
> >
> > send doIt to stack worker in 0
> > wait 0 with messages
> > doSomethingElse
> >
> > I'm seeing a situation in which the code hits "DoSo
Dr. Hawkins wrote:
> I (like I assume many others) have a number of places with blocks like
>
> send doIt to stack worker in 0
> wait 0 with messages
> doSomethingElse
>
> I'm seeing a situation in which the code hits "DoSomethingElse"
> before the "doIt" happens.
If you want to ensure "doIt" ha
I still don't have my finger completely on this one, but watching the
sluggish shifting back and forth between tabs on the script editor, I think
I'm starting to grasp it.
I (like I assume many others) have a number of places with blocks like
send doIt to stack worker in 0
wait 0 with messages
21 matches
Mail list logo
