setFocus preventing multi-touch events? (bug? - sample code attached)

Hi Greg,

As far as I know, there’s no way you’ll ever get an “ended” phase when sliding a finger completely off the screen, since the device simply can’t read any signals there (obviously). I’m not sure any SDK does this, and perhaps not even natively can it be done (although if somebody knows for sure that this can be done, I’d be curious to hear so).

For something like you describe, with multiple fingers sliding all over the screen, over different “organ keys” and such, you may need to construct a fairly complex system that uses the “moved” phase instead of began and ended (or it uses both). Start simple… try building two “keys” and testing different methods. Then build two more keys, and test multitouch. If you get that going, keep expanding and see what happens. I maintain (stubbornly) that this is possible in Corona, but you’ll have to keep testing. :slight_smile:

Brent

thanks Brent - I can’t really see how it would be possible in Corona.  I thought of setting a timer for each individual touch but then the problem  is you don’t really know if the finger slid off the edge, or whether the user is still holding down the key for a long time.  

It seems to be the “slide” feature of the organ that triggers the road block I think.   If I drop this feature requirement I think it might be achievable then, as each key could be it’s own display object then…I’ll have to test…

I assumed that each “key” would be its own display object. Were you thinking of doing one giant object, and then somehow “mapping” touch events on it?

For the screen edge, why not just have the overall key region tucked in slightly? Then put a slim border around it which detects touches? If that receives a moved phase, then you know the user’s touch is off the keyboard, but not yet off the screen.

The top and bottom organ keyboards are their display object so as to be able to support sliding the finger from left to right but getting a constant frequency change for the notes, not step changes in frequency. So yes detects which key a new touch is in based on position. Actually this is probably possible using separate display objects per key isn’t it then thinking about it?

Re putting some margin: tried this but it didn’t work if you swipe really fast. So the setfocus seemed to be the only solution for this.

Hi Brent/all

As an update I think I have things working with the “have to use separate display objects” approach (code below).  So to achieve my “slide” requirements I’ll just have to use this and build a bit more intelligence into the listeners as the slide moves across keys (i.e. which key, at what distance from the center of each key etc).  

Couldn’t get the “ended” events to act reliably (without dropping “ended” events) in the case of using a single display object, with multiple touches on that one display object.   So the feature request here is valid I believe:  

Code for using separate display object:

system.activate( "multitouch" ) local displayW, displayH = display.contentWidth, display.contentHeight local noteObjects = {} local function touchListener(event) local uniqueTouchId = event.id local note = event.target local id = note.id if event.phase == "began" then display.getCurrentStage():setFocus(event.target, uniqueTouchId); -- display.getCurrentStage():setFocus(event.target); -- Did not work note.isFocus = true; print(event.id, note.id, "began") elseif event.phase == "moved" and note.isFocus then elseif note.isFocus then -- only ended and cancel should have remained as phases display.getCurrentStage():setFocus(event.target, nil); note.isFocus = nil; print(event.id, note.id, "ended/cancelled") end end -- create notes for i=1,3 do local tempNote = display.newRect( (i-2)\*displayW/4+displayW/2,displayH/2, displayW/4,displayH/2) tempNote:setFillColor( 0.9, 0.9, 0.9 ) tempNote.strokeWidth = 1 tempNote:setStrokeColor( 0, 0, 0 ) tempNote.id = i tempNote:addEventListener("touch", touchListener) noteObjects[i] = tempNote end