Hi I'm sorry to say that the Josh's fix I commented is not fixing the thing I suggested. The problem of labels removed is still there as you can see in the following image (I had it today again):
https://imgur.com/a/NEiUZXH The labels or icons that are removed change, so I think this could be some thread problem since happens un one compilation from around other 15 or so... If someone could take a look at this, would be great, since I think is an important problem. I think we should detect what's happening if we can before 1.0 Thanks > > On Thu, Apr 2, 2020 at 9:23 PM Carlos Rovira <carlosrov...@apache.org> > > wrote: > > > >> Hi Josh, > >> > >> many thanks for this report to see what changed: > >> > >> Although all is impressive, I think the second point is really > important, > >> if is what I think it's. > >> > >> From always, I had "false compilations" in TDJ (and other real apps) > that > >> make string labels in menus, list, and icons, be blank sometimes and > >> randomly. I think is 1/20 compilations. So that change seems to fix that > >> if > >> I'm understanding correctly. > >> > >> I'll be watching that the following days to see if that's finally solved > >> or > >> I still can get a false compilation. > >> > >> If is solved, I think this change is key, since until now I think an > user > >> getting that behaviour will think not so well about Royale stability. > >> > >> Thanks!! :) > >> > >> Carlos > >> > >> > >> El mié., 1 abr. 2020 a las 21:04, Josh Tynjala (< > >> joshtynj...@bowlerhat.dev>) > >> escribió: > >> > >> > Good news! I was able to expand on what Alex suggested to provide a > >> > solution that prevents public variables from being renamed by Google > >> > Closure in release builds. A few key points: > >> > > >> > - You can set public variables in MXML, and they will work > correctly > >> in > >> > release builds. Previously, only properties with setters worked in > >> > release > >> > builds. > >> > - I've also determined how to prevent Google Closure from creating > >> > multiple copies of static public variables, which caused some > values > >> > (numbers, boolean, strings) to get out of sync if changed at > runtime. > >> > This > >> > was a closely related issue. > >> > - I added prevent-rename-public-symbols and > >> > prevent-rename-protected-symbols compiler options. They are true by > >> > default, but you can set them to false to go back to the old > behavior > >> > (which would include reporting a warning for public vars). > >> > - No changes were required to the MXMLDescriptor, so my changes > won't > >> > mess with debugging workflows that require inspecting that data > >> > structure > >> > at runtime. > >> > > >> > The process of implementing a better solution for this gave me some > >> ideas > >> > related to adding more control over exports, so I plan to give that > >> another > >> > try too. Thanks again to Alex for the suggestions that helped make > this > >> > happen. > >> > > >> > -- > >> > Josh Tynjala > >> > Bowler Hat LLC <https://bowlerhat.dev> > >> > > >> > > -- Carlos Rovira http://about.me/carlosrovira
