Morph event handling (was: [Q] doubleclickable and dragable morph: how?)

tblanchard at mac.com tblanchard at mac.com
Fri May 2 16:53:09 UTC 2003


Well, I believe the second one is correct - its not a 'click' until the 
mouse is up.

This was drummed into us Mac users' heads in hypercard (new buttons 
provided mouseUp handlers for actions by default) and it was baked into 
the system buttons on the Mac.

So I feel fairly certain about this (and look at the trouble it causes 
when trying to pop open a modal widget with that pending mouseUp 
lurking out there ready to be delivered to the wrong thing.

Looking at the code again, I think I should add one more state 
#secondClickDown and then process doubleClick on the mouseUp event 
delivery.   But the hack definitely produces nicer behavior now with no 
noticeable problems.  IOW, doing "self ChangeColor" works the same 
whether its implemented in #click: or #doubleClick:

So I'm confident about this one.


On Friday, May 2, 2003, at 10:01  AM, Ned Konz wrote:

> On Thursday 01 May 2003 10:56 pm, tblanchard at mac.com wrote:
>> Ned,
>>
>> You ROCK!
>>
>> Only I put the wait code in the MouseClickState handleEvent:from:
>> method (because I'd guess its a universal problem).
>
> I don't think I'd do that.
>
> Actually, if you were going to change the meaning globally, you could
> just respond to the second mouse-up instead of the second mouse down
> to make a double click.
>
> I just don't know how people expect to experience double-clicking.
> It's the difference between (use fixed font):
>
> up   --      ---------          ------
>        \    /         \        /
> down    ----           --------
>
> event        ^click    ^doubleClick
>
>
> and:
>
> up   --      ---------          ------
>        \    /         \        /
> down    ----           --------
>
> event        ^click             ^doubleClick
>
> -- 
> Ned Konz
> http://bike-nomad.com
> GPG key ID: BEEA7EFE
>
>



More information about the Squeak-dev mailing list