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 is news to me. I thot the queue would clear. Good to know.
Bob S
On Oct 25, 2016, at 22:51 , Monte Goulding
> 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
I always use dispatch unless I need to send in time.
Bob S
On Oct 25, 2016, at 15:31 , Mark Talluto
> wrote:
On Oct 25, 2016, at 10:18 AM, Richard Gaskin
> wrote:
Dr.
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
> 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
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
> 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
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
> 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
... [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
[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
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
> 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
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
> 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
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*
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
--
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
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"
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