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]> 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]>> 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]>> 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]>>) 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]>> >>>> 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]>>) >>>> 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]>> >>>>>> 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]>> 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> >>>> >>>> >>> >>> -- >>> Carlos Rovira >>> http://about.me/carlosrovira <http://about.me/carlosrovira> >> >
