Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat
stopPropagation - am I understanding this? - Gideros Forum

stopPropagation - am I understanding this?

snookssnooks Member
edited August 2017 in General questions
I am making a navigation drawer, but am having difficulty with even propagation. It is arranged, in parent to child order...

Container -> Transparent touch handler -> ListView -> Elements

They all have event listeners for touch except the Container. Even when I call stopPropagation immediately on entering the touch callbacks for the touch handler, the events still get to the child views/sprites (it feels a bit wrong calling them sprites non-game contexts*).

Could somebody please explain what should happen with events getting to child sprites/views when stopPropagation is called?

* it might be an idea to have a View = Sprite or something somewhere


  • i think the propagation order is the opposite. child is above parent on screen, that's why it receives first the event.
  • piepie Member
    edited August 2017
    I don't know if this still applies but from gideros docs:
    When a touch or mouse event occurs, Gideros dispatches an event object into the event flow from the root of the scene tree.

    I can't say if my way to deal with this is the best possible, however to avoid strage behaviours I used a global "focusmanager" to understand where the focus is: each element with a touch listener has a focusname property, and it responds only when the focusmanager variable matches; after that I stopPropagation().

    Each element when opened (created/added to stage/shown) has to declare its existence with focusmanager:setFocus("self.focusname")
    then when it's closed it has to declare
    to remove itself from the "focus list"

    In the function handling the touch event of every object I have something like
    function onTouch(event)
    if focusmanager:getFocus() == self.focusname then
    --do things
    FOCUSMAN = Core.class()
    function FOCUSMAN:init()
    	self.foci = {} --table to save focuses in order
    --if there is f (focus name as in "popupMenu") add it. f = nil removes the last focus added
    function FOCUSMAN:setFocus(f)
    	if not self.foci then 
    		self.foci = {} --sometimes the empty storage table is removed by gc?
    	if f then
    		self.foci[#self.foci+1] = f
    		self.foci[#self.foci] = nil
    		print("FOCUS TABLE DEBUG: current focus - ", self.foci[#self.foci])
    		for i,v in ipairs(self.foci) do
    --return current focus
    function FOCUSMAN:getFocus()
    	local f = self.foci[#self.foci]
    		print("FOCUS TABLE DEBUG")
    		for i,v in ipairs(self.foci) do
    	return f
  • Yes, it does seem as though it is the other way around. I have made the transparent overlay a child of the ListView and it mostly works as expected.

    But... the ListView is this one... https://github.com/pykaso/Gideros_ListView

    It is arranged like this....

    ListView -> List Items -> Buttons

    Now that the overlay layer is a child of ListView, events do not propagate to ListView or List Items, but they still get to the Buttons.

    I think some form of FocusManager might well be the way forward, thanks.
Sign In or Register to comment.