[Q] handling mouse events (many questions)
ned at bike-nomad.com
Thu Apr 18 18:51:32 UTC 2002
On Thursday 18 April 2002 11:28 am, Martin Drautzburg wrote:
> Here is what I believe to understand about mouse events. I someone
> could comment this and answer the remaining queastions I'd be most
> grateful. If you can give me a good pointer, don't read any
> Why event handlers ?
To make event handling pluggable.
> There are event handlers and you can tell them things like
> on: #event send:#selector to: #someObject
> you can also send this to a Morph, but it will implicitly
> create an EventHandler if there isn't one already. I believe
> the benefits of event handlers is that these are objects so
> you can pass them around, but I'm not sure.
That's right. And the advantage of sticking these in the extension is
that they don't take up space unless they're used.
> When not to use the event handler ?
> I don't understand why there are these methods AND an event
> handler and when to override the methods and when to use
> the event handler.
If you need pluggable behavior, use the event handler. If you always
have the same response to events, save the space and implement the
event handling directly.
> Double clicks
> However a #doubleClick is always preceeded by a #click.
> What would I have to do when I want a #doubleClick without a
Then just ignore the click.
The problem is that omitting the click events would require delaying
for the double click time in order to see whether there is going to
be a second click. Which would produce an annoying delay on all
Perhaps you can add code like this:
self isThereGoingToBeAnotherClick ifFalse: [ do something ]
The implementation of isThereGoingToBeAnotherClick is, of course, left
as an exercise for the reader <g>.
> The only possiblity I found to handle a drop was to
> override acceptDroppingMorph: aMorph event: anEvent
> This is not done by the event handler. So why do I do this
> with a method whereas for other events I use the event
> handler ? Most notably the TrashCanMorph does not use an event
> handler at all.
The way the EventHandler is set up, there's an instance variable for
each pluggable selector. Perhaps when drag'n'drop was added, it was
decided not to grow each EventHandler by another slot.
You can, of course, make this pluggable yourself. AlignmentMorphBob1,
for instance, uses a property to hold a drop handler.
> List if events
> How do I know what events exist, i.e. what I can pass to
> the #on:send:to.
Look at the code for EventHandler>>on:send:to:
GPG key ID: BEEA7EFE
More information about the Squeak-dev