Thanks bert,

Your analysis is correct. I always bump in the fact that I do not want 
to have a simulation system build on top
of morphic (using step) but in the same time I want to have a user 
friendly feedback.
So for me Morphic is a bit doomed regarding that (I got the same 
problem with my bot system)

> There are several options for you:
>
> a) Continue to use Sensor and accept that Morphic will block while 
> your code is running.
>
> b) Rewrite your example to follow the Morphic philosophy. This is 
> certainly possible, but I doubt it will exhibit the same simplicity 
> that the "old"code has.
>
> c) Apply a little hacker-fu to make Morphic run under your control:
> 	Turtle>>anyButtonPressed
> 		World doOneCycle.		"Bert's magic hacker-fu"
> 		^ ActiveHand anyButtonPressed

Ok I will try this one. I always thought that it was bad to use World 
doOneCycle. but you are right.

> 	This one works, since essentially Morphic runs the #doOneCycle method 
> in a loop all day anyway. You have to be careful though to when you 
> can call this, because I doubt Morphic is fully reentrant.
>
> d) Write a system that allows and encourages the coding style you used 
> (because it is so beautifully simple and almost obvious), but is 
> actually event-driven under the hood. Your code would run 
> quasi-parallel with all the other UI code. Tough stuff, though.

oh yes, especially when you only have the nitgh to code it and hate 
concurrency. I compared my turtle code to the one of nathanael
doing animation and I was really afraid I could not bug fix it. :)

> e) Do not write system d) yourself, but wait for Andreas to release it 
> ;-)

I know. I may port everything to tweak once released. But I want that 
my wife can work meanwhile
and finiiiiiisssssshhhhhh this @#$%^&*()_book

****Thanks****