Swipe vs select on mouseDown

[theotherbassist]

Let's say I have a scrolling group that can be scrolled by "grabbing" it--not literally with the grab command but by marking the mouseLoc and changing the vscroll/hscroll according to the coordinates provided by mouseMove.

Simple enough.

But what's the best way to differentiate between scrolling and selecting in-app, if both should be triggered by mouseDown? When one happens I don't want the other to be possible. This is pretty normal behaviour in apps--should I use a short time delay that checks whether the user has swiped away from the loc of the mouseDown? Or should there be a minimum "swiping distance" required before the app switches from treating the action like a selection to treating it like a swipe? I get the feeling there is a more intuitive method.

[jmburnod]

Hi,
What do you think about using a timer ?
Best regards
Jean-Marc

[theotherbassist]

A timer that, say, checks whether the user has moved farther than 10 px away from the starting mouseLoc before sending the scrolling command?

[theotherbassist]

What I settled on is something of a hybrid solution I guess. I did implement the timer--"click and hold" will trigger an action after .75 seconds. In this case it does something if any of a list of predefined words in a field is the target. But I cancel the "selection" action in lieu of scrolling if the cursor moves away from the clickLoc by more than 5px. It also immediately triggers the selection action if the cursor hasn't moved out of the 10x10 box around the clickLoc between mouseDown and mouseUp (e.g. if the user hasn't "swiped" more than 5px vertically or horizontally).

Code: Select all

local sScrolling, sInitialMouseX, sInitialMouseY
local sInitialHScroll, sInitialVScroll, sCanceled, sNav

on mouseDown
   put true into sScrolling
   
   put item 1 of the mouseLoc into sInitialMouseX
   put item 2 of the mouseLoc into sInitialMouseY
   put the vScroll of me into sInitialVScroll
   put the hScroll of me into sInitialHScroll
   
   put false into sCanceled
   put the clickText into sNav
   send navChk to me in .75 seconds
end mouseDown

on navChk
   if sCanceled then
      exit navChk
   end if
   
   switch sNav
      case Keyphrase1
         //do some actions related to this, but for now...
         answer "Doing keyphrase1"
         break
      case Keyphrase2
         //do some actions related to this, but for now...
         answer "Doing Keyphrase2"
         break
      case Keyphrase3
         //do some actions related to this, but for now...
         answer "Doing Keyphrase3"
         break
      case Keyphrase4
         //do some actions related to this, but for now...
         answer "Doing Keyphrase4"
         break
      case Keyphrase5
         //do some actions related to this, but for now...
         answer "Doing Keyphrase5"
         break
      case Keyphrase6
         //do some actions related to this, but for now...
         answer "Doing Keyphrase6"
         break
      default
         //do nothing
         break
   end switch
end navChk

on mouseMove mouseX, mouseY
   if sScrolling then      
      put mouseY - sInitialMouseY into tVChange
      put mouseX- sInitialMouseX into tHChange
      
      if tVChange > 5 or tHchange > 5 or tVchange < -5 or tHChange < -5 then
         put true into sCanceled
         put empty into sNav
      end if
      
      lock screen
      set the vScroll of me to sInitialVScroll - tVChange
      set the hScroll of me to sInitialHScroll - tHChange
      unlock screen
   end if
end mouseMove

on mouseRelease
	send mouseUp
end mouseRelease

on mouseUp
   	put false into sScrolling
   send navChk
end mouseUp

I know it's odd to essentially turn specific chunks of field text into buttons like this. But the field is a running event log, so simplicity is the name of the game here when calling additional actions from the information in the log.