Nope. Didn’t figure it out. It looks like Crux listens on the ancestor and is relying on bubbling.
I’m guessing bubbling is not working, but I have no idea why that would have changed with my commit. > On Dec 23, 2019, at 10:06 PM, Piotr Zarzycki <[email protected]> > wrote: > > Harbs, > > I feel like Carlos has started his Christmas time ;) I'm glad that you > figured it out! :) > > pon., 23 gru 2019 o 21:01 Harbs <[email protected] > <mailto:[email protected]>> napisał(a): > >> The asconfig file did not include the necessary metadata. Fixed that… >> >> OK. I’m not getting any errors, but UserForm is dispatching an event not >> listened to by anyone. >> >> Where is the listener supposed to be attached? Maybe it’s listening to the >> wrong object? >> >> >>> On Dec 23, 2019, at 9:35 PM, Harbs <[email protected]> wrote: >>> >>> I’m getting an error that UserForm.user is null. >>> >>> I have no idea where that should have been set, and I have no idea how >> my commit could have possibly effected that. I don’t see anything that >> would initialize the user variable. >>> >>> If you want my help on this, I’m going to need some direction. >>> >>> Thanks, >>> Harbs >>> >>>> On Dec 23, 2019, at 9:28 PM, Harbs <[email protected] >>>> <mailto:[email protected]> <mailto: >> [email protected] <mailto:[email protected]>>> wrote: >>>> >>>> I fixed this, but I have no idea what Crux is supposed to do. >>>> >>>> What am I looking for? >>>> >>>>> On Dec 23, 2019, at 8:30 PM, Harbs <[email protected] >>>>> <mailto:[email protected]> <mailto: >> [email protected] <mailto:[email protected]>>> wrote: >>>>> >>>>> I can’t compile Jewel right now. >>>>> >>>>> I’m getting an error: >>>>> >>>>> [java] >> /Apache/royale-asjs/frameworks/projects/Jewel/src/main/royale/org/apache/royale/jewel/IconButton.as(104): >> col: 13 Access of possibly undefined property classSelectorList. >>>>> [java] >>>>> [java] classSelectorList.toggle("icon", (_icon != >> null)); >>>>> [java] ^ >>>>> >>>>> >>>>>> On Dec 23, 2019, at 7:17 PM, Carlos Rovira <[email protected] >>>>>> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>>>>> >>>>>> Compilation is ok. The problem is that example is not really working. >>>>>> In that example you should be able to fill the form and push the >> button. >>>>>> After that a JS Alert should be show with the ID of the user record >> saved. >>>>>> That Alert is not show anymore. >>>>>> If you revert locally that commit and recompile Core and then the >> example >>>>>> and run you'll be able to see it again. >>>>>> We have a client complaining about the app stopped to work today >> since they >>>>>> are using Crux. >>>>>> After investigation I was able to trace the problem to that commit. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Carlos >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> El lun., 23 dic. 2019 a las 17:59, Harbs (<[email protected] >>>>>> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>) escribió: >>>>>> >>>>>>> I compiled CruxQuickStartBasic and I don’t see anything wrong. >>>>>>> >>>>>>> Can you give me more clues? >>>>>>> >>>>>>> FWIW, I used Ant, is the problem specific to Maven? >>>>>>> >>>>>>> >>>>>>>> On Dec 23, 2019, at 6:26 PM, Carlos Rovira <[email protected] >>>>>>>> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Harbs, >>>>>>>> >>>>>>>> seems recent changes break Crux library >>>>>>>> (commit: f50c9990a3190cf681364905525656984ab2e9c5 - Cleaned up >>>>>>>> ElementWrapper and HTMLElementWrapper) >>>>>>>> I'm trying to see what could be the problem. I suppose that is the >> change >>>>>>>> of HTMLElementWrapper now extending ElementWrapper. >>>>>>>> Tried to change one for the other in Crux library, but with no luck >>>>>>>> I'm using /examples/crux/CruxQuickStartBasic to test >>>>>>>> Can you see what could be wrong? >>>>>>>> Thanks >>>>>>>> >>>>>>>> Carlos >>>>>>>> >>>>>>>> >>>>>>>> El dom., 22 dic. 2019 a las 17:24, Harbs (<[email protected] >>>>>>>> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>) >>>>>>> escribió: >>>>>>>> >>>>>>>>>> There is lots of what looks like shared code, so could >>>>>>>>> HTMLElementWrapper extend ElementWrapper? >>>>>>>>> >>>>>>>>> Totally. Excellent idea. >>>>>>>>> >>>>>>>>>> On Dec 22, 2019, at 5:46 PM, Alex Harui <[email protected] >>>>>>>>>> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> In a quick look at history, HTMLElementWrapper's override logic >> was the >>>>>>>>> same as ElementWrapper's. >>>>>>>>>> >>>>>>>>>> Maybe as you upgraded HTMLElementWrapper's logic, ElementWrapper >> should >>>>>>>>> have changed as well but didn't? >>>>>>>>>> >>>>>>>>>> There is lots of what looks like shared code, so could >>>>>>>>> HTMLElementWrapper extend ElementWrapper? >>>>>>>>>> >>>>>>>>>> My 2 cents, >>>>>>>>>> -Alex >>>>>>>>>> >>>>>>>>>> On 12/22/19, 1:00 AM, "Harbs" <[email protected] >>>>>>>>>> <mailto:[email protected]> <mailto: >> [email protected] <mailto:[email protected]>>> wrote: >>>>>>>>>> >>>>>>>>>> We found a weird bug with events and currentTarget. >>>>>>>>>> >>>>>>>>>> I traced the problem to the following: >>>>>>>>>> >>>>>>>>>> The app loads both HTMLElementWrapper and ElementWrapper. The >> lstener >>>>>>>>> overrides in the two are stepping on each other. Here’s what >> happens: >>>>>>>>>> >>>>>>>>>> 1. HTMLElementWrapper is loaded first. It replaces >>>>>>>>> goog.events.fireListener with its fireListenerOverride function >> (which >>>>>>>>> calls the existing one when it’s done). >>>>>>>>>> 2. ElementWrapper is loaded next and it replaces the existing >>>>>>>>> goog.events.fireListener function — which was already changed to >> point >>>>>>> to >>>>>>>>> HTMLElementWrapper.fireListenerOverride with the one from >>>>>>> ElementWrapper. >>>>>>>>>> 3. When an event is actually dispatched, >>>>>>>>> ElementWrapper.fireListenerOverride first changes the event to a >> royale >>>>>>>>> BrowserEvent instead of a goog one. >>>>>>> HTMLElementWrapper.fireListenerOverride >>>>>>>>> is then called and where it expects a goog BrowserEvent, it in fact >>>>>>> gets a >>>>>>>>> royale BrowserEvent. This causes the wrappedEvent to be the wrong >> type >>>>>>> and >>>>>>>>> messes things up down the line. >>>>>>>>>> >>>>>>>>>> I’m not sure of the best way to fix this. >>>>>>>>>> >>>>>>>>>> * We could check the event type in >> HTMLElementWrapper/ElementWrapper, >>>>>>>>> but that’s just-in-case code. >>>>>>>>>> * I’m not completely sure why we need this logic in both >>>>>>>>> ElementWrapper and HTMLElementWrapper. Is there something that can >> be >>>>>>>>> changed there? >>>>>>>>>> * Maybe there’s some way for ElementWrapper to know that some >> other >>>>>>>>> class is installing an override? >>>>>>>>>> >>>>>>>>>> Thoughts? >>>>>>>>>> Harbs >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Carlos Rovira >>>>>>>> http://about.me/carlosrovira <http://about.me/carlosrovira> >>>>>>>> <http://about.me/carlosrovira <http://about.me/carlosrovira>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Carlos Rovira >>>>>> http://about.me/carlosrovira <http://about.me/carlosrovira> >>>>>> <http://about.me/carlosrovira <http://about.me/carlosrovira>> >>>>> >>>> >>> >> >> > > -- > > Piotr Zarzycki > > Patreon: *https://www.patreon.com/piotrzarzycki > <https://www.patreon.com/piotrzarzycki> > <https://www.patreon.com/piotrzarzycki > <https://www.patreon.com/piotrzarzycki>>*
