Sorry there was an unfinished sentence above:

The Royale bindings implementation does not run

was supposed to be
The Royale bindings implementation does not run in exactly the same way as
Flex, and this remains true after the changes. So legacy code that depends
on the order of execution of Flex bindings probably won't magically start
working with this. But it at least means that all the bindings from the
original code should be possible to run.







On Fri, May 22, 2020 at 11:02 PM Greg Dove <greg.d...@gmail.com> wrote:

>
> Just an explanation of various binding improvements that have been added.
> (I'm waiting for one of the builds to complete, but it has worked
> locally for a week in copious testing.)
>
> The major change is a fix to something that has never worked : mxml
> binding 'inheritance'.
> This is usually where the class ancestry chain cycles in and out of mxml
> and actionscript - and is a relatively common pattern in legacy code.
> The implementation does what you would expect - ancestor bindings are
> run before subclass bindings.
> The Royale bindings implementation does not run
> There are also fixes for conflicting names for generated event handlers
> (js) and generated ids (swf and js). This was happen with mxml ancestors.
>
> I have fixed the above and tested in both swf and js. Code that doesn't
> need the fix continues to work as before. Binding unit tests continue to
> pass as before.
>
> SDK Bindings code has a tidy up and should now be lighter weight for most
> cases because of reduced duplication. More tweaking here might see the
> possibility to reduce it further using @royalesuppressexport but that can
> come later. Functionality first...
>
> I also needed to address some other binding issues, so I think Piotr will
> be pleased that I finally fixed a bug he logged last year (sorry it took so
> long). And I know Harbs has mentioned issues with the use private bindings.
> I fixed the getter/setter usage for private bindings (and matched how Flex
> does it - it simply uses the plain name for the propertyName in the event,
> in the same way it would if it were public). These were previously
> dispatching the long 'private' property name from the setters but watchers
> were listening for the plain (short) name. That is fixed now.
>
> All changes were implemented and tested for swf as well as js. Swf is
> generally a little trickier to work on for this stuff, but in this case it
> was relatively straightforward (the function bindings work I did a few
> months back was more challenging).
>
>
>

Reply via email to