In looking at the Google code, it appears that all we need to do in our EventDispatcher.dispatchEvent override is set the event.target on the event object to the wrapper. Do you see the same thing?
I didn't try that, but yes I do see that now. well spotted! :) that sounds good if all our events are descendants of goog.events.Event I saw all the other parts except for this: e.target = e.target || target; On Thu, Sep 1, 2016 at 5:44 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 8/31/16, 9:51 PM, "Greg Dove" <greg.d...@gmail.com> wrote: > > >Yeah, I guess that is not 'simple' in terms of an example but it was > >easier > >to show it with what was already there. > > > > "I thought that folks who created custom IEventDispatchers without > >extending > >EventDispatcher wrapped an EventDispatcher and passed in a reference to > >the instance to that EventDispatcher." > > > >yep, I am definitely one of those folks too :). That's what I am doing. > > > >"Are you saying it didn't work atall in JS?" > > > >I did not see it work, and based on the eventtarget code, I can't see how > >it can. > > Hmm, looking at this case again, I agree that it couldn't work. I must > have had my head on sideways that day. > > The exception we hit in the test case is because we've set the > actualEventTarget_ to the wrapper instead of the wrapped EventDispatcher, > which causes the code to look in the wrong place for the fireListeners > method. But we don't really want to do that at all. It doesn't matter > which object manages the list of listeners to call. t think all we really > want is to set the event.target to be the wrapper instead of the wrapped > EventDispatcher. > > In looking at the Google code, it appears that all we need to do in our > EventDispatcher.dispatchEvent override is set the event.target on the > event object to the wrapper. Do you see the same thing? Then we don't > need the other patches to Google's code you have proposed. > > Of course, I could be wrong. > > Thanks, > -Alex > >
