In order for you to be able to do completely different things on click and double click you need to wait and see if a double click occurs before the doubleClickInterval and if it does not *then* do the single click action. After all, the engine is not clairvoyant.
This is why click then double click should always be an incremental and related action - unless you want a pause in processing the single click. Mark. Sent from my iPhone > On 4 Aug 2016, at 03:14, Peter M. Brigham <pmb...@gmail.com> wrote: > > 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 _______________________________________________ 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
