On Sunday 25 July 2004 10:16 pm, Peace Jerome wrote:
> The comment in one of the method 

That is #waitForClicksOrDrag:event:selectors:threshold:

> to handle click, 
> doubleClick, and drag states:
>
>
> "Wait until the difference between click,
> double-click, or drag gesture is
> 	known, then inform the given morph what transpired.
> This message is
> 	sent when the given morph first receives a mouse-down
> event. If the
> 	mouse button goes up, then down again within
> DoubleClickTime, then
> 	'doubleClick: evt' is sent to the morph. If the mouse
> button goes up but
> 	not down again within DoubleClickTime, then the
> message 'click: evt' is
> 	sent to the morph. Finally, if the button does not go
> up within
> 	DoubleClickTime, then 'drag: evt' is sent to the
> morph. In all cases, the
> 	event supplied is the original mouseDown event that
> initiated the
> 	gesture. mouseMove: and mouseUp: events are not sent
> to the morph
> 	until it becomes the mouse focus, which is typically
> done by the client
> 	in its click:, doubleClick:, or drag: methods."
>
> 	This is NOT what happens. A click is always sent
> before a double click event.

Yes. The comment should be changed.

> 	DoubleClickTimeout selectors are never sent.
>

They are if they're set in the #waitForClicksOrDrag:event:selectors:threshold: 
selectors list. However, the only place in the stock image where the third 
(doubleClickTimeout) selector is not nil is in the HandMorph.

But they work, which I know because I use them:

NCGrabbableDisplayTextMorph(Object)>>break
NCGrabbableDisplayTextMorph>>doubleClickTimeout: [break]
MouseClickState>>doubleClickTimeout
MouseClickState>>handleEvent:from:
HandMorph>>processEvents

You can show this yourself with the following workspace snippet:

r := RectangleMorph new.
r on: #click send: #value to: [ r color: Color red ].
r on: #doubleClick send: #value to: [ r color: Color blue ].
r on: #doubleClickTimeout send: #value to: [ r borderWidth: 2 ].
r on: #mouseDown send: #value to: [ r color: Color white; borderWidth: 1 ].
r on: #startDrag send: #value to: [ r color: Color orange ].
r openInWorld.


If you double-click successfully the rectangle becomes blue, otherwise its 
border gets wider on double-click timeout.

> 	The proof of this is demonstrated by
> DoubleClickExampleMorph. Try as hard as you like you
> can not get a doubleclick to occur w/o a click
> happening first.

This is by design.

Since we can't look into the future, we'd have to wait until the 
doubleClickTimeout if we wanted to suppress #clicks in favor of 
#doubleClicks.

> 	Particularly Dramatic is pressing mouse down, up,
> down (pause) up. At the pause the mouse click has
> registered in the example and then the doulbleckick
> registers with the following mouse up. This is not
> according to contract or I believe intention. Mouse
> click state is doing something wrong,

This is probably a bug. I'll fix it.

> I've been looking at these methods and trying to
> figure whats going on but the logic seem wonderfully
> tortured and complex.  As Sherlock would say a three
> pipe problem.

It could stand to be refactored.

Thanks,
-- 
Ned Konz
http://bike-nomad.com/squeak/