Re: Binding to private variables

[Bindable] Private/public/protected var someVar; Always results in generated code to convert the var into a getters/setter so we can detect writes. A JS setter results in: Object.defineProperty("someVar",... // if private it would be "MyClass_someVar" And that prevents the getter/setter

Re: Binding to private variables

I did a sweep on some of the less common bindings a couple of years ago. I think a few things that were working then may no longer be working after various changes. I need to check the test project for that. I'm happy to revisit that if people send me their binding bugs (better still add an issue

Re: Binding to private variables

What I’m not sure is how any of this worked in minified code. I’ve used [Bindable]private quite a lot… I’m not sure how to best fix this, but it does seem like a problem which needs fixing. > On Dec 6, 2018, at 9:59 PM, Greg Dove wrote: > > The other thing to consider is the ValueChangeEvent

Re: Binding to private variables

The other thing to consider is the ValueChangeEvent that is being dispatched for automatically generated private [Bindable] vars It keeps the undecorated name in terms of what it dispatches. so for [Bindable] private var test:String you get

Re: Binding to private variables

Hi Andrew, I just had a quick go at doing this locally. I *think* it should be able to be done in MXMLRoyaleEmitter with minor changes. I have not tested extensively, so I will just describe what I did and you can see if it works, and if it is universally applicable. The following is what I did:

Re: Binding to private variables

Hi Andrew, Thanks for looking into this. One of the things to keep in mind about the compiler that isn't immediately obvious is that the JS compiler can be thought of almost as a subclass of the SWF compiler. It isn't truly that way in the code, but the way it is now, even if you don't want

Re: +configname=flex

Hi Josh, I rebuild all in the branch and can confirm your fix worked :) Thanks for taking the time check this and showing the way to fix it! :) Carlos El jue., 6 dic. 2018 a las 19:10, Carlos Rovira () escribió: > Hi Josh, > > thanks for looking at it, I'll going to check now and report >

Re: +configname=flex

Hi Josh, thanks for looking at it, I'll going to check now and report El jue., 6 dic. 2018 a las 19:03, Josh Tynjala () escribió: > Carlos, > > I wish that you had included the list of problems that you are seeing, as > I requested. I wanted to be completely certain that I'm seeing the exact >

Re: +configname=flex

Carlos, I wish that you had included the list of problems that you are seeing, as I requested. I wanted to be completely certain that I'm seeing the exact same ones that you are. Regardless, here's my initial attempt to reproduce and fix your issue. In

Re: +configname=flex

Hi Harbs, you're right, sorry. I thought I already pushed it. Just did now. El jue., 6 dic. 2018 a las 12:26, Harbs () escribió: > I don’t see the branch. Are you sure you pushed it? > > > On Dec 6, 2018, at 12:05 PM, Carlos Rovira > wrote: > > > > Remember to use

Jenkins build is back to normal : royale-asjs_MXTests #235

See

Build failed in Jenkins: royale-asjs_MXTests #234

See Changes: [yishayjobs] Fix launch.json -- [...truncated 2.34 MB...] [mxmlc] using source file:

Binding to private variables

Hi all I found recently that binding had stopped working when we were using private variables, for example: where we declare: private var _model : Model = Model.getModel(); However it works with protected/public variables.. The reason is clear when you look at the generated _bindings array,

RE: [royale-asjs] branch develop updated: Fix launch.json

Maybe I should be more precise, this fixes VSCode not launching a debug session. Did I break some other use case? From: yish...@apache.org Sent: Thursday, December 6, 2018 2:51:01 PM To: comm...@royale.apache.org Subject: [royale-asjs] branch develop updated:

Re: +configname=flex

I don’t see the branch. Are you sure you pushed it? > On Dec 6, 2018, at 12:05 PM, Carlos Rovira wrote: > > Remember to use "feature/refactor-config-name-changes" branch where my > commit is reverted and things are set up like Alex want.

Re: +configname=flex

Hi Harbs, El mié., 5 dic. 2018 a las 18:42, Harbs () escribió: > Just to examine these steps and try to communicate how I would have > handled them: > > When I run into a similar problem while using “bleeding edge” code, my > first step is to write the problem to the list ASAP. I’ll spend the

Re: +configname=flex

Hi Josh El mié., 5 dic. 2018 a las 17:59, Josh Tynjala () escribió: > Carlos, can you include more details about your issue? > > > MX RO test with Jewel > > Can you mention the exact project inside royale-asjs that I can load with > VSCode to see this issue? I'm guessing that it might be one of