mousedoubleup

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark

Locked
Martin Koob
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 256
Joined: Sun May 27, 2007 8:19 pm

mousedoubleup

Post by Martin Koob » Wed Jan 08, 2014 9:48 pm

Just found out that double-clicking the mouse will send both the mouseUp and mouseDoubleUp messages. I looked in the QA and there is indeed a bug report about this.

http://quality.runrev.com/show_bug.cgi?id=3567

In the report it says that this has issue been around since HyperCard.

Is there any chance this could be addressed in the work on the engine or is it impossible to fix or fixing it would break stacks.

I managed to work around it but I thought I would bring it up here to see if it needs a new look.

Martin

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: mousedoubleup

Post by FourthWorld » Wed Jan 08, 2014 11:35 pm

I think it's been around so long because it's extremely rare that you would handle both messages in the same control. The common workaround is to wait a brief interval when handling mouseUp:
http://forums.runrev.com/viewtopic.php? ... eup#p43101
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: mousedoubleup

Post by LCMark » Thu Jan 09, 2014 11:19 am

The reason for the current behavior is that the engine cannot predict the future...

If the engine only sent *either* a mouseUp *or* a mouseDoubleUp, all single-clicks would need to be delayed by the double-click interval before they could be dispatched (to ensure that the first click wasn't part of a double-click) this would mean all mouse click messages would be delayed. If this were the case, UI response would seem sluggish (think about if there was a fixed, but noticeable delay on every click of your UI before anything happened).

If you need to handle both and have them do completely different things, then typically this means there's a flaw in the UI design. Generally actions tied to double-click have to be extensions of the action tied to the click. For example, the first click highlights an item in a list, the double-click performs an action on the item in the list (which makes sense because that item has already been highlighted by the first click and thus it would be natural that it is the one the action targets). There's a similar situation with mouseDown/mouseDrag - the engine can't know whether a mouseDown will become a mouseDrag until the drag detection interval has passed.

The code pattern to be able to handle both distinctly (albeit with delay) looks something like this:

Code: Select all

local sMouseSingleUpMessageId

on mouseUp
  send "mouseSingleUp" to me in the doubleClickInterval millisecs
  put the result into sMouseClickMessageId
end mouseUp

on mouseSingleUp
  put empty into sMouseSingleUpMessageId
  -- handle the single-click (definitely not part of a double-click)
end mouseSingleUp

on mouseDoubleUp
  cancel sMouseClickMessageId
  put empty into sMouseClickMessageId

  -- handle the double-click
end mouseDoubleUp
Now having said all of that, this is perhaps very much a 'desktop'/mouse-interaction UI point of view. It would be worth noting that mobile (touch!) type interfaces do have delays typically built in so that correct actions can be taken. A good example is the typical mobile 'scroller' type control - here, there is usually a setting 'delayContentTouches' or some such which basically says: don't send me any touches until you are sure they aren't part of a gesture that would be used to manipulate the container. The prototypical example here is again a list - a single touch highlights an item, a swipe down or up scrolls the list but does *not* change selection, and a side-swipe highlights the item and augments it with options for editing (typically 'delete'). Here, there is always a delay between the initial 'touch-down' occurring, and a subsequent touch message propagating to script (or not at all, if it becomes a scroll action).

Thus whilst we cannot make the engine predict the future it would be possible to have object properties that determine whether 'gestures' (e.g. double-click as opposed to single-click, drag as opposed to single-click) should be discounted before *any* messages are sent. So, in the original case above, if such a property is set on the object you'd only get mouseUp *or* mouseDoubleUp albeit by having to pay the small-delay tax on all single mouse click messages.

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7210
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: mousedoubleup

Post by jacque » Thu Jan 09, 2014 7:16 pm

runrevmark wrote:The reason for the current behavior is that the engine cannot predict the future...
Could that be added to the stretch goals please?

:)
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

[-hh]
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2262
Joined: Thu Feb 28, 2013 11:52 pm
Location: Göttingen, DE

Re: mousedoubleup

Post by [-hh] » Fri Jan 10, 2014 8:48 am

..........
Last edited by [-hh] on Wed Aug 13, 2014 1:33 pm, edited 2 times in total.
shiftLock happens

Martin Koob
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 256
Joined: Sun May 27, 2007 8:19 pm

Re: mousedoubleup

Post by Martin Koob » Fri Jan 10, 2014 10:29 pm

Thanks Richard and Mark for the explanations.

I wasn't aware of the thinking behind how double-click should work. Very interesting.

I was using it in a data grid form in a Mac OS X application and I wanted the double click to trigger the appearance of the button to delete the row by sliding buttons and fields to the right. I was using a mouseUp in the row behavior to handle mouse clicks on the delete button in the row template but I also had it perform an action when the row was hilited. I realize now that I should have been handling the action when a row is hilited in the 'on dgHilite' handler. So I made those changes and it works properly.

Just a further question, by UI conventions would using a mouseDoubleUp in this situation be appropriate? One click to select the row and the second click to perform a shortcut action --reveal an option(delete button) for the row.

Martin

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: mousedoubleup

Post by FourthWorld » Fri Jan 10, 2014 10:44 pm

I made a post to the use-livecode list a couple years ago about the noun-verb semantics of mouse interactions with regard to double-clicks - hard to say if it will be relevant for your UI, but here it is:
http://lists.runrev.com/pipermail/use-l ... 52534.html
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

Martin Koob
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 256
Joined: Sun May 27, 2007 8:19 pm

Re: mousedoubleup

Post by Martin Koob » Sat Jan 11, 2014 4:29 pm

Thanks for that post Richard.

In my case I have two verbs I guess
clicking on a row of the data grid selects that row and causes more data from that row to be displayed in another data grid.
double clicking on a row reveals a delete button to remove the row.

I am trying to make a UI that operates in the way a touch UI would operate.
touch on a row of the data grid would select that row and cause more data related to that row to be displayed.
swipe-right on a row reveals a delete button to remove the row.

Double Click may not be the best action to replace swipe-right on the desktop.

Anyway this getting well OT for the engine contributors forum. Thanks for your insights.

Martin

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: mousedoubleup

Post by LCMark » Mon Jan 13, 2014 9:21 pm

I think that the raising of the comparison with 'touch' UIs is interesting because it does (perhaps?) suggest a shift in interaction and expectation.

As far as I can see from a logical and visual consistency point of view, if you don't want a delay in handling a click action then you have to make sure multiple click actions build on the previous click actions. A good example (beyond the Finder) is interaction in a field - first click places the caret, second click selects the word around the caret, third click selects the line around the word. In each case, visually (nor action-wise!), you don't get a discontinuity - the subsequent click actions subsume the previous ones all by extending the selection.

Now, touch UIs are different - gestures do require delays to process. The small delay which you have to endure (and we perhaps do not notice, because its how touch UIs have worked from the outset) when you do a 'touchDown', results in being able to tell the difference between a click, a swipe and a scroll action without any previous events being dispatched. A future possible engine feature is to add this idea of gestures, not just for touch but also for mouse clicks - i.e. perhaps a singleClick, doubleClick etc. message which would be subject to an appropriate delay before dispatch.

Of course, it might just be that the reason touch UIs work with the slight delay is because finger actions are quicker than mouse click actions and as such the delay can be almost unnoticeable...

RobertC
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 46
Joined: Sun Feb 04, 2007 3:43 pm

Re: mousedoubleup

Post by RobertC » Tue Mar 24, 2015 7:51 am

If you need to handle both and have them do completely different things, then typically this means there's a flaw in the UI design.
It should perhaps be avoided, but what about the OSX Finder? It has singe and double clicks (and delays before you can edit a name?
Or text editors which set the insertion point on single click, select a word on double click and a paragraph on triple click?

Of course the engine cannot predict the future, so the proposed solutions are about the only tactic that works.
Note that in OSX, even the Finder, in a window with column view, does its single-click action first (show the contents of the folder clicked), then the double-click action (open a new window with that folder) and leaves the single-click result as it is.

[No reply expected to this opinion]
The Old Rant Robert.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: mousedoubleup

Post by FourthWorld » Tue Mar 24, 2015 3:12 pm

RobertC wrote:
If you need to handle both and have them do completely different things, then typically this means there's a flaw in the UI design.
It should perhaps be avoided, but what about the OSX Finder? It has singe and double clicks (and delays before you can edit a name?
Or text editors which set the insertion point on single click, select a word on double click and a paragraph on triple click?

Of course the engine cannot predict the future, so the proposed solutions are about the only tactic that works.
Note that in OSX, even the Finder, in a window with column view, does its single-click action first (show the contents of the folder clicked), then the double-click action (open a new window with that folder) and leaves the single-click result as it is.
The noun-verb metaphor may seem abstract, but I believe it's useful here. In UIs, we can consider objects to take on the role of nouns in the interaction semantics, and commands applied to those objects as verbs. In that view, gestures are sometimes used as shortcuts to verbs, though sometimes they may alter the state of an object without invoking a command, such as the object's selected state.

With text editing, both single- and double-clicks change the selected state of the text; a single click sets the selection to an empty string at the insertion point, while a double-click set the selection to the word within which the click occurred. In both cases the gestures could be viewed as changing the state of the object, but not necessarily invoking a command that alters the object in any way.

With the Finder, renaming is actually two gestures: first is a single-click on the object to change its state to selected, and then the mouse must be hovered over the object within a certain set of bounds and for a certain duration before the combination of those gestures invokes the "Rename" command. The bounds and duration are the factors that also determine double-click, so in essence the OS is monitoring for double-click and will favor it if it occurs, but if the hover continues beyond the doubleClickInterval and the mouse hasn't left the slop rect defining a double-click, only at that point will the OS then decide to invoke a separate command, Rename.

A more fitting comparison than these two (the first alters only state and the second is a combination of gestures) might be to find examples of push buttons that invoke one command when single-clicked and another command when double-clicked. Offhand, I can't think of any.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: mousedoubleup

Post by LCMark » Wed Mar 25, 2015 1:54 am

@FourthWorld: I think that if one did find an example of such a push button, then it would be an example of a 'bad UI design experience'. The only truly logical way to handle multiple clicks is a situation where n-clicks extends the action (in the appropriate context) of (n-1)-clicks. Any other design would cause far far too many interaction faults which would frustrate users.

Locked

Return to “Engine Contributors”