wait for 1.2 seconds with messages -- twice hangs

2004-04-06 Thread Steven Zins
It appears that when two wait for N seconds with messages
statements are used, one handler blocks the other.

The following code is in a card script:

on test0 -- cause other two handlers to start after this one ends
  send test1 to me in 0 seconds
  send test2 to me in 0 seconds
end test0

on test1
  repeat forever
put test1return after field Log of group grp
wait for 1 seconds with messages
  end repeat
end test1

on test2
  repeat forever
put test2return after field Log of group grp
wait for 1 seconds with messages
  end repeat
end test2




The result of sending a message to test0 is:
test1
test2
test2
test2
test2
test2
... 

If I then set a breakpoint in the test2 handler to stop the loop and
then press abort, the test1 handler resumes functioning.

I am running Runtime Revolution 2.1.2 on Windows 2000. I am using the
debug environment but Suspend Development Tools doesn't improve
matters.

Am I doing something wrong? Should this work with test1 and test2 on
different cards? Different stacks? A stand-alone application?  Must I
chop my code up to into pieces and use send .. in N seconds in
order to get a time delay?

Speculation: wait for N seconds with messages allows other handlers
to respond to messages but does not allow a handler to resume after a
wait.

Any help is appreciated.

Steven Zins
[EMAIL PROTECTED]




__
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: wait for 1.2 seconds with messages -- twice hangs

2004-04-06 Thread Dar Scott
On Friday, April 2, 2004, at 08:15 PM, Steven Zins wrote:

Speculation: wait for N seconds with messages allows other handlers
to respond to messages but does not allow a handler to resume after a
wait.
Many of us have had to do the same test when we first tried to do 
several things at once with Revolution.

This is not a multi-threading situation in which execution can switch 
back and forth between handlers.  Your test2 is started in the wait in 
test1 but does not return and thus test1 cannot continue; its wait does 
not complete.

I rarely use wait with messages and then only for a single big task I 
have trouble breaking up with 'send'.

In most cases, I use 'send'.  See my Message Mechanics Primer at my web 
site on using that for multi-tasking types of situations.  You can 
make your apps walk and chew gum at the same time.

Dar Scott
--

Dar Scott Consulting
http://www.swcp.com/dsc/
Programming Services

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution