On Saturday 05 April 2003 12:37 am, Stephane Ducasse wrote:

> for my small robot environment I define the following method so
> that a bot can move from one tile to another one.

[snip]

But how is this method being executed? It *must* be executed in the 
main UI process!

Which means you only have a couple of valid choices:

* run it from a step method (which is executed in the main UI process)

* use WorldState>>addDeferredUIMessage: to do the synchronization and 
updating.

> the bot misses to pick some diamonds: really annoying. I guess that
> this is because the method can pick and pick do not contain World
> doOneCycle.

Using World>>doOneCycle* is almost always a bad idea. I'd like to 
purge it from the existing "modal" dialogs wherever possible. And 
it's just wrong if you do it from a background thread.

> I have the impression that this is a really bad practice to
> explicitly wait for the refresh but I do not know how to do it in a
> better way.
>
> Have you suggestion to fix my problem?

Yes. I would do this:

* put your interpreter or control thread into a background process.

* where synchronization/refresh is necessary (i.e. on a new position), 
add a message to your robot's SharedQueue that contains the new 
position.

* then, wait on a per-robot Semaphore from your background process.

* have your step method peek at the SharedQueue; if there is a new 
position there, remove the new position, update the robot's position 
(which will invalidate the robot's display rectangle and force it to 
be refreshed), and then signal the Semaphore.

You can set the step rate to whatever gives you the most usable 
animation speed.

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE