So I must not be understanding this. If you want something to happen on mouseup and something else to happen on mousedoubleup, then how do you do it?
If I put this into a button script: on mousedown put "mousedown" & cr after fld "text" end mousedown on mouseUp put "mouseup" & cr after fld "text" end mouseUp on mousedoubledown put "mousedoubledown" & cr after fld "text" end mousedoubledown on mousedoubleup put "mousedoubleup" & cr after fld "text" end mousedoubleup and I then do a doubleclick, I get mousedown mouseup mousedoubledown mousedoubleup in fld "text". So far so good. if I comment out the actions in the mousedown and mouseup handlers, so they are effectively blocking those messages, I get mousedoubledown mousedoubleup in the field. But how do I get mousedown mouseup on a single click and *only* mousedoubledown mousedoubleup on a doubleclick? It seems to me that if a doubleclick always produces both a mousedown/up and mousedoubledown/up set of messages, there is no way of preventing the mousedown/up actions happening in addition to the mousedoubledown/up actions. To make it clearer: on mouseup show grc "test1" end mouseup on mousedoubleup show grc "test2" end mousedoubleup the mousedoubleup action will always show both graphics, but I want it to only show grc "test2". ??? -- Peter Peter M. Brigham pmb...@gmail.com On Aug 3, 2016, at 7:55 PM, Mark Waddingham wrote: > 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 ~ m...@livecode.com ~ http://www.livecode.com/ > LiveCode: Everyone can create apps > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode