Set DoubleClickInterval very low!

[Mark Waddingham]

On 2016-08-04 01:32, Sannyasin Brahmanathaswami wrote:
> How is it a bug? logically the engine must wait for the double click
> interval before responding or double clicks could never be passed?
> N'est ce pas?

No - that isn't how double clicks work in LiveCode.

On the first mouseDown the engine:

   1) Stores the time of the mouseDown (last-click-time)
   2) Stores the location of the mouseDown (last-click-loc)
   3) Dispatches mouseDown

On a subsequent mouseDown the engine does the following:

   if current-click-time - last-click-time < doubleClickInterval and \
        abs(current-click-loc.x - click-loc.x) < doubleClickDelta and \
           abs(current-click-loc.y - click-loc.y) < doubleClickDelta then
       dispatch mouseDoubleDown
   else
       dispatch mouseDown
   end if

i.e. If a click is within the doubleClickInterval time-wise since the 
last click, and within the doubleClickDelta distance since the last 
click a mouseDoubleDown message is sent instead of mouseDown.

(Note that if a mouse down event results in a mouseDown message, then 
you will receive a mouseUp message when the mouse is released, and if a 
mouse down even results in a mouseDoubleDown message, then you will 
receive a mouseDoubleUp message when the mouse is released).

What you are seeing is the fact that if you tap quickly (i.e. each one 
within the doubleClickInterval and close to each other on the screen) 
then you will receive:

   mouseDown
   mouseUp
   mouseDoubleDown
   mouseDoubleUp
   mouseDown
   mouseUp
   mouseDoubleDown
   mouseDoubleUp

i.e. You will get an alternating sequence of down/up and 
doubleDown/doubleUp pairs.

Solution: If you don't need to handle double clicks do:

   on mouseDoubleDown
     mouseDown
   end mouseDoubleDown

   on mouseDoubleUp
     mouseUp
   end mouseDoubleUp

This is a long standing (i.e. forever!) 'the way things work' in 
LiveCode - although I think there is a way it could be a great deal 
better, and more intuitive.

The only use of multi-click 'gestures' (which is what 'double clicks' 
are) which makes sense from a UI interaction point of view is where each 
click builds upon the action of the previous one.

e.g. In Finder:

   1) The first click selects a file
   2) The second click runs the file (which is already selected at this 
point)

e.g. In Text Editors:

   1) The first click places the caret
   2) The second click selects the word the caret is in
   3) The third click selects the line the word is in

Thus, one possible improvement would be to ditch the 'double' messages 
entirely, and add a 'clickCount' event property (a bit like the 
clickLoc) which returns the number of subsequent clicks. This would mean 
that (in a mouseDown / Up) handler you just choose what you do based on 
the clickCount. This means you can easily handle single, double or 
triple click sequences (which, I think is pretty much as far as you can 
stretch that particular bit of physical interaction - unless you want to 
cause the user significant problems in using your UI). i.e. In a double 
click scenario you would get:

   mouseDown (clickCount == 1)
   mouseUp (clickCount == 1)
   mouseDown (clickCount == 2)
   mouseUp (clickCount == 2)

This can be further built upon by introducing the idea of gestures. A 
'click' is actually a gesture, not an event - i.e. it is a precise 
sequence of events which can be interpreted as a specific type of 
action. Introducing gestures you'd get the following message sequence:

   mouseDown (clickCount == 1)
   mouseUp (clickCount == 1)
   click (clickCount == 1)
   mouseDown (clickCount == 2)
   mouseUp (clickCount == 2)
   doubleClick (clickCount == 2)
     if passed then click (clickCount == 2)

For what its worth, LiveCode Builder uses the clickCount model (i.e. no 
double messages) - although we haven't added 'gestures' there yet.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps