Long story short
I have an onclick event for a container
If I click on a child(with background) of this container the event is fired.
trace(event.bubble) is false
Is there a way to avoid it ? AM I doing something (logically speaking) wrong ?
I guess I’ve found something similar to my issue here : TableView with more headerrows - #6 by ianharrigan
You can cancel the event so it won’t bubble. With event.cancel(); if I remember well.
Yeah, as rationaldecay mentioned, i think event.cancel() is what you are after, assuming im understanding what you mean ofc.
Cheers,
Ian
Well … in fact I didn’t explained it very well 
the problem is that I have this situation
VBOX -> onClick event handler
|__IMAGE (no event handler)
If I click on IMAGE, the VBOX handler fires
So actually I cannot event.cancel it or at least not as it is, I should add an onclick handler on IMAGE
I would like the VBOX handler to fire only clicking on the container (empty) body
without having to add event.cancel() to all the other children, updating or creating an onClick handler
@ianharrigan
Just an additional info (pretty obvious … to be fair )
When I release the Slider handle, the the Container’s onClick handler fires, trying to use event.cancel() inside a onDragEnd handler doesn’t seem to prevent the onClick to fire
testing this I’ve also found a slider glitch.
The onclick handler hides the container. If this happen while dragging, the slider looks like this once shown again
the value is set but the handler is on “0” position
will look at these, and some of the sidebar ones, tomorrow
Ian
So, ignoring the slider issue (for now), and back to the original issue:
Why do you have an onclick handler in your vbox? Can you explain your use case? Or even better a small sample showing what you are trying to do and how its not working?
Cheers,
Ian
@ianharrigan
You can check the project I shared some days ago.
Clicking the green bg should open a detail view
If you click on the red dot or on the switch (that should be disabled) it opens the detail view too, and it shouldn’t imho.
The problem is that when the switch is enabled, clicking on it to select/deselect open the detail view too
the image (red dot) doesn’t have any onclick handler, so I cannot .cancel()
the switch, of course has it
Hope I explained a bit well
gotcha… ill have a play… thanks, that makes it much more clear (sorry, forgot there was an example already 
)
EDIT: i wonder if slider (and image etc) should “consume” the click - ill have a think
You need to pull it as I’ve sent the “onclick” changes today
well, generally speaking, I don’t expect the event to be inherited by the children
Just a note.
There’s a paradox here. 
If you remove the “background-color” from the container (vbox) the handler runs only clicking on the children 
You need to pull it as I’ve sent the “onclick” changes today
Its fine, i understand the issue completely now, so i can always roll out my own test app
well, generally speaking, I don’t expect the event be inherited by the children
That sounds sensible, but wonder if there are edge cases, i dont think cancelling all events makes sense (maybe it does???)
There’s a paradox here.
Thats an openfl thing… its modeled after flash, and there you dont get mouse events for things that dont have backgrounds, so to get a mouse event, you’ll need to have a drawn something into it… … … … this actually infuriates me tbh, its caught me loads of times - i think (personally) the original flash behaviour is… … strange, though i guess i get it
Anyways, the original issue is deeper than that, i guess (though not confirmed) that it would also happen on any backend as it is (i feel) a haxeui “thing”
Yep, I know, that’s in fact a design decision.
Maybe the event “cloning” can be avoided if the child already has an handler for the same event (like the switch)
Or maybe, adding a property in the xml to avoid bubbling if not needed ? I don’t know, just brainstorming here
Yeah, im sure there is an easy “elegant” solution… we just need to try to think of one that isnt really a compromise - thankfully this is all haxeui-core, so it should be something that, as a lib, we have total control over. The simple fact is that, as you have noticed, a click on a button in a box with a click handler shouldnt trigger the click on the box… … actually, now i think about it… im pretty sure itemrenderers dont do that. Ill check them out.
EDIT: hmmm, ok, they work a little differently
Can you pull latest and let me know if that fixes it, ive come up with something but im not sure if its ill conceived or not.
Dont bother…
Ive reverted the change, it was a bad change - ill keep thinking about it 
(I think) I’m trying to do something similar, trying to “consume” the MouseEvent.CLICK so that other components can’t use it. I tried e.cancel() but I couldn’t figure out if it was doing anything – is e.cancel() meant to be the “consume” type function that prevents other components from using it?
Or if I’m going about this all wrong, any clues on how to get a mouse click to affect only the top-most component layer, and nothing underneath?
EDIT: so to try to explain it better – I’m on Heaps / HashLink backend
I have two buttons, the small one is in front of a bigger one, and I want the mouse click to only affect the small one. The bigger button is not a parent of the small button, I’m using absolute positioning to overlap them.
But it seems like both buttons are in hover state at the same time, independently, so they probably each get their own separate mouse click events.
Right now I’m doing hacks to disable the bigger button if the small button is clicked, but (I think) I’m wondering if there’s a more elegant way to tell HaxeUI to only process the front-most click event for any interaction or something.
EDIT 2: ok I found a new workaround for this – I just added my small button “overlay” to the app / Screen.instance root, instead of some other component, similar to a dialog modal, and now mouse clicks don’t get shared anymore! sorry to bother everyone lol
Cool - glad you worked it out. The original one post is still an issue that i need to come back to… and the overlapping absolute buttons is interesting too. Ill keep that in mind when revisiting the original issue.
Cheers,
Ian
Just a note about this issue, related to a non trivial side-effect
A click in a text box to update the value, fires the parent click event
It’s pretty obvious and “expected” but unseen (by me) till today 
the e.cancel() workaround does its job