On Monday 19 May 2003 05:58 am, Lex Spoon wrote:
> Ned Konz <ned at bike-nomad.com> wrote:
> > On Friday 16 May 2003 10:22 am, Bovaird, Brian wrote:
> > > I looked at the basic morph programming tutorials but these all
> > > concentrate on scripting.
> > >
> > > I am writing a game and need to put a gui on it. I need to do
> > > "programatic" morph programming.
> > >
> > > Are there any good tutorials for doing this?
> > >
> > > I am currently looking at all the games (Tetris, Chess, etc.)
> > > examples but it is confusing without explainations.
> >
> > Hi Brian,
> >
> > Be wary of overriding mouseDown: etc. unless you have very
> > special needs; instead, use the
> > 	self on: #mouseDown send: #someMessage to: self
>
> Why do it this way?  I tend to lean the opposite direction.  Using
> mouseDown: methods makes the code easier to browse.

Well, I admit to mostly using mouseDown: methods myself. Or doing the 
event dispatching using a FSM, which is more flexible.

However, if you've got the possibility of having to reassign the event 
behavior (and you're not otherwise tracking event handling state) it 
probably makes sense to use the pluggable event handler that's 
already there.

Another big plus is that it handles the waitForClicksOrDrag: stuff for 
you. So you can plug in handlers for the derived actions like #click, 
#doubleClick, #doubleClickTimeout, etc. in a single line of code, 
rather than having to set up separate handlers.

If you want to use your Morphs with eToys, you have to use the event 
handler (or at least understand #on:send:to:) since that's how the 
wiring between the events that the Morphs receive and the scripts 
that get run in the Players happens.

Also there's some menu actions and settings in the environment that 
only work via the event handler.

For instance, any morph can become a button. And its button behavior 
is set using the event handler. And PluggableListMorphOfMany gets its 
dragging behavior from the event handler.

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