update a progress indicator or do other minor housekeeping.
Would that help your situation?
I haven't quite grasped Richard's problem of the pendingMessages.
But I doubt it would make a difference whether using blocking or
non-blocking url routines. The so-called blocking routines are only
that help your situation?
I haven't quite grasped Richard's problem of the pendingMessages.
But I doubt it would make a difference whether using blocking or
non-blocking url routines. The so-called blocking routines are
only script-blocking. i.e. they block the currently executing
handler
transfer and one
that has been called before the previous one completes?) it could get
messy.
I don't think using the pendingMessages queue to schedule blocking
transfers is the best approach. Typically, you would wait until one
transfer completes, and then start the next one.
If you know
think using the pendingMessages queue to schedule blocking
transfers is the best approach. Typically, you would wait until one
transfer completes, and then start the next one.
If you know the files to be transferred when you start the
procedure, I would do something like this (error checking
Hi Richard
You could try retrieving the directory through a cgi process that also
returns a meta info related to the event.
regards
alex
Richard Miller wrote:
Tied into this is that getting a directory from the server is obviously
just as prone to failure as getting any file from the server
On 6 Mar 2007, at 13:55, Richard Miller wrote:
Can/should a directory ftp call be unloaded (i.e. via unload URL)
before trying a second time?
Only if it's obtained with a non-blocking call. (e.g. load url)
There's no need to use unload with any blocking call (get url, put ..
into url).
Great idea. Thanks Alex.
Richard
On Mar 6, 2007, at 7:40 AM, Alex Shaw wrote:
Hi Richard
You could try retrieving the directory through a cgi process that
also returns a meta info related to the event.
regards
alex
Richard Miller wrote:
Tied into this is that getting a directory from
Richard,
We discovered that the pending messages were the source of our file
transferring problem. I don't know what the doc's say or when these
messages are supposed to be sent, but I do know they greatly effected
our file transferring routine, interrupting it at seemingly random
times.
are off with regard to
pendingMessages, since messages from libURL may easily become
interleaved with your own.
--
Richard Gaskin
Fourth World Media Corporation
___
[EMAIL PROTECTED] http://www.FourthWorld.com
cause may lie with libURL, or with the way
libURL is used.
While some libURL calls are blocking, most are asynchronous. If you
were using any of the non-blocking calls all bets are off with
regard to pendingMessages, since messages from libURL may easily
become interleaved with your own
some libURL calls are blocking, most are asynchronous. If you
were using any of the non-blocking calls all bets are off with
regard to pendingMessages, since messages from libURL may easily
become interleaved with your own.
Yes that was exactly it. We were using a non-blocking transfer
haven't quite grasped Richard's problem of the pendingMessages. But
I doubt it would make a difference whether using blocking or non-
blocking url routines. The so-called blocking routines are only
script-blocking. i.e. they block the currently executing handler,
but will allow other asynchronous
Will lock messages halt pending messages from occurring until an
unlock messages command is sent?
I need to have all pending messages that relate to file transfers to
wait until a foreground file transfer is complete. I'm thinking that
lock messages will do that. If not, is there another
Richard Miller wrote:
Will lock messages halt pending messages from occurring until an
unlock messages command is sent?
Pending messages are only sent at idle, and lock messages no longer
has effect once idle hits should there should be no conflict.
--
Richard Gaskin
Fourth World Media
the pendingMessages into tPending
if (pMsg ) and (pMsg all) then filter tPending with *,
pMsg ,*
put tPending into gPendingMessages
repeat for each line tMsg in tPending
cancel item 1 of tMsg
end repeat
end PausePending
on ResumePending pMsg
global gPendingMessages
put
complex messaging needs:
on PausePending pMsg
global gPendingMessages
put the pendingMessages into tPending
if (pMsg ) and (pMsg all) then filter tPending with *,
pMsg ,*
put tPending into gPendingMessages
repeat for each line tMsg in tPending
cancel item 1 of tMsg
end repeat
an approach I've used that works pretty well, so long as you don't
have
really complex messaging needs:
on PausePending pMsg
global gPendingMessages
put the pendingMessages into tPending
if (pMsg ) and (pMsg all) then filter tPending with *,
pMsg ,*
put tPending into gPendingMessages
One problem here is that any parameters sent with the message will be lost,
since pendingMessages does not contain parameter information.
At 03:02 PM 3/2/2007, you wrote:
On Fri, 2 Mar 2007 13:14:08 -0700, Richard Miller wrote:
Will lock messages halt pending messages from occurring until
)
Cheers
andre
On Mar 2, 2007, at 7:11 PM, Peter T. Evensen wrote:
One problem here is that any parameters sent with the message will
be lost, since pendingMessages does not contain parameter information.
At 03:02 PM 3/2/2007, you wrote:
On Fri, 2 Mar 2007 13:14:08 -0700, Richard Miller wrote
On Fri, 2 Mar 2007 13:55:49 -0800, Brian Yennie wrote:
Ken,
Very clever... one question: how do you deal with the actual timing
of those messages, or do these scripts assume that everything pending
should be processed ASAP? Or am I confused (entirely possible!)?
It assumes that
What I did was make a function that would cache a parameter for a
message. When I suspended messages, I calculated the renaming time, and
when I resumed the messages, I used that as an offset from the current time
to resend the messages, along with the parameter that I cached, if any,
based
On 3/2/07 2:32 PM, Andre Garzia [EMAIL PROTECTED] wrote:
In case we had some nifty function, a cousin of the functiona
'variableNames' that could access all the current variables in memory
and their context, we could then freeze the engine state to some
container and restore it or bits of it
!
Thanks Ken.
on CancelPending pWhat
if pWhat = then put all into pWhat
switch pWhat
case all
repeat with x = (the number of lines of the pendingmessages) down to 1
cancel (item 1 of line x of the pendingMessages)
end repeat
break
default
repeat with x = (the number of lines
no 'backlog' which can create quite a
confusion when debugging!
Thanks Ken.
on CancelPending pWhat
if pWhat = then put all into pWhat
switch pWhat
case all
repeat with x = (the number of lines of the pendingmessages) down to 1
cancel (item 1 of line x of the pendingMessages
a great bitesize tutorial on pendingMessages.
thanks.
Erik Hansen
Set up a loop like this:
on checkCaps
if the capsLockKey = down then put
Capslock ON
else put Capslock OFF
if the pendingMessages contains checkCaps
is false then
send checkCaps to me in 10 ticks
Puzzle for Revolutionaries: Watch messages in realtime. There is one
message you can't ever see, even though it is almost always in the
pendingMessages. What message is that?
idle?
Terry
___
use-revolution mailing list
[EMAIL PROTECTED]
http
On Thursday, June 19, 2003, at 02:08 AM, Terry Vogelaar wrote:
Puzzle for Revolutionaries: Watch messages in realtime. There is one
message you can't ever see, even though it is almost always in the
pendingMessages. What message is that?
idle?
I don't know how that is implemented, but I don't
On Thursday, June 19, 2003, at 07:56 AM, Dar Scott wrote:
On Thursday, June 19, 2003, at 02:08 AM, Terry Vogelaar wrote:
Puzzle for Revolutionaries: Watch messages in realtime. There is
one
message you can't ever see, even though it is almost always in the
pendingMessages. What message
Puzzle for Revolutionaries: Watch messages in realtime. There is one
message you can't ever see, even though it is almost always in the
pendingMessages. What message is that?
idle?
I don't know how that is implemented, but I don't think it is ever in
pendingMessages().
Nope
On Thursday, June 19, 2003, at 03:06 PM, Scott Slaugh wrote:
Puzzle for Revolutionaries: Watch messages in realtime. There is
one
message you can't ever see, even though it is almost always in the
pendingMessages. What message is that?
idle?
I don't know how that is implemented, but I don't
see these in real time and even see the
Revolution messages.
I have never seen messages like mouseUp in pendingMessages. However,
messages like moveStopped and socketClosed will show up there.
This also can help you learn the format of the value returned from
pendingMessages. That value
. By
checking the right box, you can see these in real time and even see the
Revolution messages.
I have never seen messages like mouseUp in pendingMessages. However,
messages like moveStopped and socketClosed will show up there.
This also can help you learn the format of the value returned from
Dar Scott wrote:
On Wednesday, June 18, 2003, at 10:00 AM, Dar Scott wrote:
repeat for each line msgLine in the pendingMessages
if char 1 to 3 of item 3 of msgLine != rev then cancel item 1 of
msgLine
end repeat
Whoops, sorry. I just got back from a universe in which Scott added
At 6:45 PM -0700 4/16/2002, Dar Scott wrote:
There's no reason it should. It's not in the pendingMessages at
that point,
since you haven't used send in time to send a mouseUp message.
OK. I guess pendingMessages is only for pending messages sent by
send in time.
Right.
If, during my
On Tuesday, April 16, 2002, at 09:11 PM, Jeanne A. E. DeVoto wrote:
It looks like in this situation, queued
messages are sent before any events are processed - I'll check on
this to
be sure.
That is the impression I have gotten.
And I'm learning the lingo:
queued messages are sent
events
Recently, Dar Scott wrote:
I noticed that mouseUp does not show up in pendingMessages.
What other pending messages do not show up in pendingMessages?
I believe the only pending messages returned are those explicitly sent by
you:
send myMsg to me in 10 seconds
Regards,
Scott Rossi
At 3:20 PM -0700 4/16/2002, Dar Scott wrote:
I noticed that mouseUp does not show up in pendingMessages.
It does for me.
--
Jeanne A. E. DeVoto ~ [EMAIL PROTECTED]
Runtime Revolution Limited - The Solution for Software Development
http://www.runrev.com
On Tuesday, April 16, 2002, at 06:12 PM, Jeanne A. E. DeVoto wrote:
At 3:20 PM -0700 4/16/2002, Dar Scott wrote:
I noticed that mouseUp does not show up in pendingMessages.
It does for me.
on mouseUp
wait for 2 seconds -- I click a couple times here.
put linefeed
At 6:24 PM -0700 4/16/2002, Dar Scott wrote:
on mouseUp
wait for 2 seconds -- I click a couple times here.
put linefeed = linefeed the pendingMessages after
field Report
end mouseUp
A couple rev messages show up, but no mouse messages for the two clicks.
There's no reason
On Tuesday, April 16, 2002, at 07:29 PM, Jeanne A. E. DeVoto wrote:
There's no reason it should. It's not in the pendingMessages at
that point,
since you haven't used send in time to send a mouseUp message.
OK. I guess pendingMessages is only for pending messages sent by
send in time
40 matches
Mail list logo
