Sensor vs. Hand (was: Re: Squeak-3.7: Title-Bar Buttons)
bert at impara.de
Fri Mar 5 10:35:44 UTC 2004
Am 05.03.2004 um 09:59 schrieb ducasse:
> hi andreas
> I need your help :) about ActiveHand use instead of Sensor
Andreas is not yet in, so I'll answer that ;-)
> (Delay forMilliseconds: 2) wait.
> ^ ActiveHand anyButtonPressed
> [self anyButtonPressed]
> whileFalse: [self go: 30 atRandom.
> self turnLeft: 30 atRandom]
This will not work (as you have discovered) since this piece of code
runs on its own and does not give Morphic the chance to check for
events, hence the button state will never change. You may have noticed
that the rest of Squeak (or, more specifically, Morphic) is blocked
while you execute this code.
Andreas did not say to *never* use Sensor. But certainly you should
never refer to Sensor in well-behaved *Morphic* code. Your Turtle code
is an example of simple "I-have-the-whole-machine-for-me" code, but it
does not cooperate well with the event-driven logic of Morphic.
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:
World doOneCycle. "Bert's magic hacker-fu"
^ ActiveHand anyButtonPressed
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.
e) Do not write system d) yourself, but wait for Andreas to release it
- Bert -
More information about the Squeak-dev