Is there a reason you can't use capture phase listeners?
________________________________ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Troy Gilbert Sent: Tuesday, April 15, 2008 10:19 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Letting parents handle drag events > Troy - drag events are dispatched to what _you_ attach them to. If you want > the event to spawn from a child - but be handled by the parent... you > should > override addChild in the parent and attach the listener there. Your handler > will be in the parent and each child will announce whatever event you > attach > to it at that level. For my case, I can't actually do that because they're not direct child components, their actually grandchildren, created and managed by the container (which is the child). Sure, I'd still the get the addChild events, and I could look for children of a specific type (since they're a specific custom type in my case), but that's not very robust. And it doesn't fundamentally fix the problem. The problem is that Adobe derives the DragEvents from the MouseEvent class but doesn't dispatch it according to the same logic. If add a mouseDown event on a grandparent component and the user clicks on a grandchild component, unless the grandchild stops the event propogation the grandparent will get a notification, and it can identify the grandchild through the event.target property. With drag events, they aren't dispatched through the DisplayList like a MouseEvent, they're dispatched by hand by the DragProxy class. And because they're dispatched by hand, the event's target and currentTarget properties are always identical. Which is not like MouseEvents at all... Hmm... looking again at the DragProxy's event dispatch... we could make it work by changing the constructor for the DragEvent, passing in true for bubbles. This will actually fix the problem, and is probably how it should work since mouse events bubble. I could also use capture-phase event listeners, because even though the event doesn't bubble, it should always go through the capture phase (or at least that's the impression I get from the docs). This hadn't even occured to me because I was using MXML and the event attributes on components are not capture-phase event listeners, they are target and bubbling-phase listeners (useCapture=false in their addEventListener calls). So, I guess I've fixed my problem.. I've already got a monkey-patched DragProxy so that I could (properly) test for mouseEnabled when finding drop targets. I'll just add the above fix so that the DragEvents bubble. Adobe guys, is my reasoning here sensible? Troy.
