Quick Links: Gideros Home | Download Gideros | Developer Guide
stopPropagation - am I understanding this?
  • snooks +1 -1
    Member
    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.
  • pie +1 -1
    Member
    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.
    http://docs.giderosmobile.com/reference/gideros/EventDispatcher#EventDispatcher

    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
    focusmanager:setFocus()
    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
    event:stopPropagation()
    end
    end
    FOCUSMAN = Core.class()
     
    function FOCUSMAN:init()
    self.foci = {} --table to save focuses in order
    end
     
    --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?
    end
     
    if f then
    self.foci[#self.foci+1] = f
    else
    self.foci[#self.foci] = nil
    end
     
    print("FOCUS TABLE DEBUG: current focus - ", self.foci[#self.foci])
    for i,v in ipairs(self.foci) do
    print(i,v)
    end
    end
     
    --return current focus
    function FOCUSMAN:getFocus()
    local f = self.foci[#self.foci]
    --[[DEBUG
    print("FOCUS TABLE DEBUG")
    for i,v in ipairs(self.foci) do
    print(i,v)
    end
    ]]

    --
     
    return f
    end
  • snooks +1 -1
    Member
    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.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Login with Facebook Sign In with OpenID

In this Discussion

Top Posters