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
send "mouseSingleUp" to me in the doubleClickInterval millisecs
put the result into sMouseClickMessageId
put empty into sMouseSingleUpMessageId
-- handle the single-click (definitely not part of a double-click)
put empty into sMouseClickMessageId
-- handle the double-click
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.