Actually, no worries. I’ll wait for your fix. From: Yishay Weiss<mailto:yishayj...@hotmail.com> Sent: Thursday, March 10, 2022 9:38 AM To: dev@royale.apache.org<mailto:dev@royale.apache.org> Subject: RE: Issues with EventDispatcher in JS
Is there a way to test this quickly if I make the change? From: Greg Dove<mailto:greg.d...@gmail.com> Sent: Thursday, March 10, 2022 9:28 AM To: Apache Royale Development<mailto:dev@royale.apache.org> Subject: Re: Issues with EventDispatcher in JS I can make the IRoyaleClient change tomorrow my time, but if someone wants to do it today your time, please go for it. On Thu, 10 Mar 2022, 8:15 pm Yishay Weiss, <yishayj...@hotmail.com> wrote: > I think this needs to either be fixed or reverted before I start rc3 > > From: Harbs<mailto:harbs.li...@gmail.com> > Sent: Wednesday, March 9, 2022 11:07 AM > To: Apache Royale Development<mailto:dev@royale.apache.org> > Subject: Re: Issues with EventDispatcher in JS > > It should probably be: > if (event1.target && event1 is IRoyaleEvent) { > > > On Mar 9, 2022, at 11:03 AM, Harbs <harbs.li...@gmail.com> wrote: > > > > Sorry I missed this email before, but I don’t think this will work with > full minification. > > > >> On Mar 9, 2022, at 3:37 AM, Greg Dove <greg.d...@gmail.com> wrote: > >> > >> In the absence of anything suggesting otherwise, I have addressed this > in a > >> commit today. > >> I had toyed with the idea of trying to change all the > dispatchEvent(event) > >> sites that are redispatching to dispatchEvent(event.cloneEvent()), but > that > >> seems wrong because it is less reliable in terms and maintainability and > >> also still means that the EventDispatcher dispatchEvent method is > behaving > >> differently to how it should behave. > >> > >> > >> > >> > >> > >> On Tue, Mar 1, 2022 at 11:31 AM Greg Dove <greg.d...@gmail.com> wrote: > >> > >>> > >>> Sorry I sent that last message accidentally before finishing it... > >>> > >>> To achieve the same thing in Royale, we need to make the following > change > >>> in org.apache.royale.events.EventDispatcher: > >>> > >>> at location [1] > >>> > >>> else if ("target" in event1) { > >>> if (event1.target && "cloneEvent" in event1) { > >>> event1 = event1.cloneEvent(); > >>> } > >>> event1.target = _dispatcher; > >>> } > >>> > >>> Can anyone see issues with addressing this? There are quite a few cases > >>> where this is needed in the emulation code. > >>> > >>> > >>> > >>> > >>> > >>> 1. > >>> > https://github.com/apache/royale-asjs/blob/develop/frameworks/projects/Core/src/main/royale/org/apache/royale/events/EventDispatcher.as#L87 > >>> > >>> > >>> On Tue, Mar 1, 2022 at 11:28 AM Greg Dove <greg.d...@gmail.com> wrote: > >>> > >>>> > >>>> for any example that listens and re-dispatches an event in Royale, eg: > >>>> > >>>> > >>>> public function collectionChangeHandler(event:CollectionEvent):void{ > >>>> ... other code ... > >>>> else if (ce.kind == CollectionEventKind.RESET) > >>>> { > >>>> ... other code ... > >>>> dispatchEvent(event); > >>>> } > >>>> else if ... other code ... > >>>> } > >>>> > >>>> Currently in AVM this will work as it did before. But in Royale it > does > >>>> not, it will mutate the original event by reseting the target to the > >>>> current dispatcher. > >>>> This is because the AVM EventDispatcher (I assume) calls the clone() > >>>> method on the event, redispatching a new instance from the dispatcher. > >>>> > >>>> To achieve the same thing in Royale, we need to make the following > change > >>>> in org.apache.royale.events.EventDispatcher: > >>>> > >>>> at location [1] > >>>> > >>>> else if ("target" in event1) { > >>>> if (event1.target && "cloneEvent" in event1) { > >>>> event1 = event1.cloneEvent(); > >>>> } > >>>> > >>>> } > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> 1. > >>>> > https://github.com/apache/royale-asjs/blob/develop/frameworks/projects/Core/src/main/royale/org/apache/royale/events/EventDispatcher.as#L87 > >>>> > >>>> > >>>> > > > >
