Direct Sensor polling cleanup

Sam Adams ssadams at us.ibm.com
Mon Feb 24 15:51:20 UTC 2003





When experimenting with the EventRecorder it becomes obvious that *lots* of
code in the image still assumes real-time polling of input events,
MVC-style.  A typical example is:

InputSensor>>waitNoButton
      "Wait for the user to release any mouse button and then answer with
the
      current location of the cursor."

      [self anyButtonPressed] whileTrue:
            [(Delay forMilliseconds: 50) wait].
      ^self cursorPoint

Which is called 32 times throughout the system, from old MVC code to
Morphic.
I have spent a couple of days digging through all the code, and am about to
launch into an effort to clean this up so users of EventRecorder won't have
so many surprises.  The Morphic implementation of events handles almost
everything, but I suppose there are a couple of hundred methods that ignore
the event mechanism and go straight to the Sensor within while loops like
the above.

Any ideas on an approach to solving this problem cleanly?

BTW, since whileTrue: and whileFalse: are inlined, whats the easiest way to
find all senders?

Regards,
Sam



Sam S. Adams, IBM Distinguished Engineer, IBM Research
tie line 444-0736, outside 919-254-0736, email: ssadams at us.ibm.com
<<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, I Corinthians 1:10>>



More information about the Squeak-dev mailing list