how do you prevent propogation of an event from a button?
Return true from onPress, onRelease, onEvent does not work.
how do you prevent propogation of an event from a button?
Return true from onPress, onRelease, onEvent does not work.
Why not use “removeEventListener()” after the item has been touched ?
Hi Jack,
It’s working for me with “return true” in the handler function. Perhaps you’re not using the correct handler mode? Remember that the “onEvent” mode reports ALL phases, while “onPress” reports only “began” and “onRelease” only reports “ended”. If you use “onEvent” you need to manually filter out which phase you want… with the others, that’s handled internally.
Hope this helps,
Brent
> It’s working for me with “return true” in the handler function.
Which handler? There are 3 in the pastebin.
> Perhaps you’re not using the correct handler mode?
I have no idea what this means.
> Remember that the “onEvent” mode reports ALL phases, while “onPress” reports only “began” and “onRelease” only reports “ended”.
I have 2 examples in the pastebin. One uses onEvent, the other is onPress + onRelease. In the windows emulator, both cases pass on the event to the underlying image display object, regardless of the “return true” at the end of each.
Hi Jack,
I’m not sure which is causing the multiple touch events, since you’re making custom buttons with their own touch and tap handlers, along with widget buttons.
So, in terms of simply the widget-based buttons… these support 3 “modes” of touch interaction: “onEvent”, “onPress” and “onRelease”. These modes allow you to customize the behavior of the button, and what is considered “interaction” with it. “onEvent” will return all four possible phases based on Corona’s core system: began, ended, moved, and cancelled. If you use this mode, you’ll need to conditionally filter out which phase(s) to handle. With “onPress” and “onRelease”, you don’t need to conditionally handle the phase, as it’s done internally. “onPress” will return a response only when the touch begins (finger touched down). “onRelease” will only return a response when the touch ends (over the button).
In any case, it probably makes sense to use one handler function for all buttons. Do “return true” at the end of it, and things should work as expected.
Brent
Remember touch events generate multiple phases. You should always get at least two calls to your event listener for touch events: A began phase and an ended phase. You are not testing for that in your touch handlers, they will therefore fire twice.
’
> I’m not sure which is causing the multiple touch events, since you’re
making custom buttons with their own touch and tap handlers, along with
widget buttons.
Display order should determine the event originator. The buttons (on top of the images) should get them first, then catch them and not propagate them, regardless of phase, to the underlying display elements.
What is going on here that you guys are talking about phases? I’m not filtering by phase. I only have 3 handlers to work with and they are all returning true. I don’t understand how this is confusing. Buttons are simply not working to prevent propagation using default handlers.
Why not use “removeEventListener()” after the item has been touched ?
Hi Jack,
It’s working for me with “return true” in the handler function. Perhaps you’re not using the correct handler mode? Remember that the “onEvent” mode reports ALL phases, while “onPress” reports only “began” and “onRelease” only reports “ended”. If you use “onEvent” you need to manually filter out which phase you want… with the others, that’s handled internally.
Hope this helps,
Brent
> It’s working for me with “return true” in the handler function.
Which handler? There are 3 in the pastebin.
> Perhaps you’re not using the correct handler mode?
I have no idea what this means.
> Remember that the “onEvent” mode reports ALL phases, while “onPress” reports only “began” and “onRelease” only reports “ended”.
I have 2 examples in the pastebin. One uses onEvent, the other is onPress + onRelease. In the windows emulator, both cases pass on the event to the underlying image display object, regardless of the “return true” at the end of each.
Hi Jack,
I’m not sure which is causing the multiple touch events, since you’re making custom buttons with their own touch and tap handlers, along with widget buttons.
So, in terms of simply the widget-based buttons… these support 3 “modes” of touch interaction: “onEvent”, “onPress” and “onRelease”. These modes allow you to customize the behavior of the button, and what is considered “interaction” with it. “onEvent” will return all four possible phases based on Corona’s core system: began, ended, moved, and cancelled. If you use this mode, you’ll need to conditionally filter out which phase(s) to handle. With “onPress” and “onRelease”, you don’t need to conditionally handle the phase, as it’s done internally. “onPress” will return a response only when the touch begins (finger touched down). “onRelease” will only return a response when the touch ends (over the button).
In any case, it probably makes sense to use one handler function for all buttons. Do “return true” at the end of it, and things should work as expected.
Brent
Remember touch events generate multiple phases. You should always get at least two calls to your event listener for touch events: A began phase and an ended phase. You are not testing for that in your touch handlers, they will therefore fire twice.
’
> I’m not sure which is causing the multiple touch events, since you’re
making custom buttons with their own touch and tap handlers, along with
widget buttons.
Display order should determine the event originator. The buttons (on top of the images) should get them first, then catch them and not propagate them, regardless of phase, to the underlying display elements.
What is going on here that you guys are talking about phases? I’m not filtering by phase. I only have 3 handlers to work with and they are all returning true. I don’t understand how this is confusing. Buttons are simply not working to prevent propagation using default handlers.