I hide the overlay all the time from a button on the overlay. This should be working. Perhaps you can post some code?
my issue that is either the same thing I think, or closely associated was raised as Case 25818 ( http://forums.coronalabs.com/topic/38763-listener-bug-why-does-a-2nd-listener-pick-up-this-event-in-this-code/?hl=25818#entry201604 )
I’ll see about posting some code in the next couple of days but having just seen this note I should mention that the storyboard page I’m “showing” the overlay on has a scrollView widget spanning the entire content area…
I think part of the problem with this is how touch events work. If you just “tap” (not touch, move, let up), Corona SDK generates both a series of “touch” events _ **AND** _ a “tap” event. The touch event may get absorbed by people setting up touch handlers to catch the leaking event but they don’t set up a trap for the tap event that goes with it. If your underlying layer has things looking to be triggered by tap’s that tap falls through.
With regards to the touch and tap handlers leaving the overlay and making it to the underlying scene: This is without a doubt a usability bug. It however is not a program bug. It’s not a program bug because a scene, be it an overlay or regular scene is just a Corona SDK display.newGroup() holding display objects. You can stack groups on top of groups and by definition, tap and touch events that are not handled by an object (and return’s true) keeps propagating through the display hierarchy. This is an important design pattern for our apps.
Where it becomes a usability bug is that you expect your scene’s to be modal when you set the .isModal flag. And while I’ve not seen the Storyboard 1.0 code, it’s probably trapping touch but not tap. This is fixed in Storyboard 2.0 which is getting close. In the mean time, you can drop both a touch and tap handler on your overlay’s background that just returns true and it should fix this for you.
Hi Rob - would be great if this workaround worked, but I’m finding it doesn’t. Using:
workAroundRect:addEventListener("touch", blockBackgroundTouches) workAroundRect:addEventListener("tap", blockBackgroundTouches) local function blockBackgroundTouches(event) return true end
Remember in my case the issue is:
a) no issues if you haven’t scrolled the tableview, but
b) if you scroll the table view a bit => go to overlay => then click on overlay & return to underlying => then the tableview cell you were pressing over gets triggered when it shouldn’t
c) also can confirm in this case (from b) that in the overlay you can either “tap” or “touch” (hold it down longer) and it has the same effect of once back in the underlying screen
d) so overall completely different thing happens (one correct, one not correct) just depending upon whether you have scrolled the table view a bit prior to going into overlay
Hi Greg. I understand your problem, but this thread is about .isModal overlays.
Regardless:
workAroundRect:addEventListener("touch", blockBackgroundTouches) workAroundRect:addEventListener("tap", blockBackgroundTouches) local function blockBackgroundTouches(event) return true end
is likely not going to work because of scope issues. When you define the touch and tap listeners, blockBackgroundTouches is undefined and therefore will try to call a nil function. The local function… block needs to come first.
sorry - they’re in the correct order in my scene, I’d just copy/pasted them in incorrect order - anyway I’ve sidetracked the thread so sorry about that…
I am using the 2014.2511 public build and I am still seeing that overlays are not properly trapping “tap” events. They are trapping “touch” events. This is what I did to workaround the issue:
-
Create a rectangle that covers the entire screen, make it invisible, but still able to listen for events (isHitTestable), and then had it listen to both events and have it call the same function
local bg2 = display.newRect(sceneGroup, display.contentWidth/2, display.contentHeight/2, display.contentWidth, display.contentHeight) bg2.isVisible = false bg2.isHitTestable = true bg2:addEventListener(“touch”, onTouchEvent) bg2:addEventListener(“tap”, onTouchEvent)
-
I noticed that the “touch” event always occurs first then the “tap” event. Consequently I only hideOverlay if I detect the “tap” event
local function onTouchEvent(event) print("instructionsWorkout {event = " … event.name … “}”) if (event.name == “tap”) then composer.hideOverlay(“zoomOutInRotate”, 1000) end end
Of course this fragile because it is depending on the “touch” events occurring before the “tap” events. But this workaround appears to be working well and my app is in the App Store. I am using the overlays as my instructions page.
I am using the 2014.2511 public build and I am still seeing that overlays are not properly trapping “tap” events. They are trapping “touch” events. This is what I did to workaround the issue:
-
Create a rectangle that covers the entire screen, make it invisible, but still able to listen for events (isHitTestable), and then had it listen to both events and have it call the same function
local bg2 = display.newRect(sceneGroup, display.contentWidth/2, display.contentHeight/2, display.contentWidth, display.contentHeight) bg2.isVisible = false bg2.isHitTestable = true bg2:addEventListener(“touch”, onTouchEvent) bg2:addEventListener(“tap”, onTouchEvent)
-
I noticed that the “touch” event always occurs first then the “tap” event. Consequently I only hideOverlay if I detect the “tap” event
local function onTouchEvent(event) print("instructionsWorkout {event = " … event.name … “}”) if (event.name == “tap”) then composer.hideOverlay(“zoomOutInRotate”, 1000) end end
Of course this fragile because it is depending on the “touch” events occurring before the “tap” events. But this workaround appears to be working well and my app is in the App Store. I am using the overlays as my instructions page.