You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Kessler CTR Mark J <ma...@usmc.mil.INVALID> on 2019/04/01 11:33:28 UTC
Re: CreationComplete event question
I had a little time over this weekend to try to catch up on some things. This is a follow up to that issue I was having about the reference comparison. It was a timing issue on our part that we resolved by moving up how quickly we store a reference.
Here's an example of what I mean. The "initComplete" event handler that is inside the "MyClass" was being called before the "addReferenceToList". The instance was getting to its "initComplete" called faster and was attempting to call a method that uses its stored reference from a list before the "myMethod" method could store the reference. We are not talking about a lot of prep either. Interesting problem to have; no invalidation or heavy lifting before its fully completed.
public function myMethod():void
{
var newInstance:MyClass = new MyClass();
...do some prep for the new instance...
addReferenceToList(newInstance);
addElement(newInstance);
}
Changed to:
public function myMethod():void
{
var newInstance:MyClass = new MyClass();
//swapped
addReferenceToList(newInstance);
...do some prep for the new instance...
addElement(newInstance);
}
-Mark K
RE: CreationComplete event question
Posted by Kessler CTR Mark J <ma...@usmc.mil.INVALID>.
>That said, based on the code snippets provided, I'm not sure why "initComplete" fired before addElement, which is what I think you are trying to point out. I would expect it to be called in addElement, so further investigation is needed there. Put a breakpoint in your "initComplete" handler and see what the call stack is. addedToParent() should be on the call stack.
Correct I wasn't being clear enough. Yes the "initComplete" was firing before the addElement from our original problem. After setting up a new test application I couldn't produce it again. Manually deleted the debug folder of the other test app and rebuilt it, it was working fine. I think that quick compile/debug combo leaves debris sometimes. I checked the call stack anyways for the event handler "initComplete" and it had addedToParent in it. So well just blame the bin/output and the guy failing to manually cleaning it out (me) .
Thank you for taking the time to respond. Sorry for the confusion.
-Mark K
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com.INVALID]
Sent: Monday, April 1, 2019 12:29 PM
To: dev@royale.apache.org
Subject: [Non-DoD Source] Re: CreationComplete event question
I haven't really followed this thread in detail so apologies if I'm missing the point.
Hopefully, FlexJS/Royale has never promised 100% backward compatibility with Flex. That's because there are some fundamental differences in the runtimes/platforms. In Flash, if you change properties of a DisplayObject, the effects show up after all other code runs. In the browser, if you change properties on an HTMLElement, it shows up right away in many cases. So lifecycle events and invalidation are not being promised to work exactly as they did in Flex. It would add a lot of overhead to try to emulate the deferred rendering of Flash in the browser.
"initComplete" in Royale isn't quite the exact same as "creationComplete" in Flex. Both give you a place to run some code as the component is initialized, but there may be subtle differences if you depended on deferred validation in Flex.
That said, based on the code snippets provided, I'm not sure why "initComplete" fired before addElement, which is what I think you are trying to point out. I would expect it to be called in addElement, so further investigation is needed there. Put a breakpoint in your "initComplete" handler and see what the call stack is. addedToParent() should be on the call stack.
HTH,
-Alex
Re: CreationComplete event question
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I haven't really followed this thread in detail so apologies if I'm missing the point.
Hopefully, FlexJS/Royale has never promised 100% backward compatibility with Flex. That's because there are some fundamental differences in the runtimes/platforms. In Flash, if you change properties of a DisplayObject, the effects show up after all other code runs. In the browser, if you change properties on an HTMLElement, it shows up right away in many cases. So lifecycle events and invalidation are not being promised to work exactly as they did in Flex. It would add a lot of overhead to try to emulate the deferred rendering of Flash in the browser.
"initComplete" in Royale isn't quite the exact same as "creationComplete" in Flex. Both give you a place to run some code as the component is initialized, but there may be subtle differences if you depended on deferred validation in Flex.
That said, based on the code snippets provided, I'm not sure why "initComplete" fired before addElement, which is what I think you are trying to point out. I would expect it to be called in addElement, so further investigation is needed there. Put a breakpoint in your "initComplete" handler and see what the call stack is. addedToParent() should be on the call stack.
HTH,
-Alex
On 4/1/19, 4:33 AM, "Kessler CTR Mark J" <ma...@usmc.mil.INVALID> wrote:
I had a little time over this weekend to try to catch up on some things. This is a follow up to that issue I was having about the reference comparison. It was a timing issue on our part that we resolved by moving up how quickly we store a reference.
Here's an example of what I mean. The "initComplete" event handler that is inside the "MyClass" was being called before the "addReferenceToList". The instance was getting to its "initComplete" called faster and was attempting to call a method that uses its stored reference from a list before the "myMethod" method could store the reference. We are not talking about a lot of prep either. Interesting problem to have; no invalidation or heavy lifting before its fully completed.
public function myMethod():void
{
var newInstance:MyClass = new MyClass();
...do some prep for the new instance...
addReferenceToList(newInstance);
addElement(newInstance);
}
Changed to:
public function myMethod():void
{
var newInstance:MyClass = new MyClass();
//swapped
addReferenceToList(newInstance);
...do some prep for the new instance...
addElement(newInstance);
}
-Mark K
Re: CreationComplete event question
Posted by Carlos Rovira <ca...@apache.org>.
Hi Mark,
I think Alex could bring more on this initialization issue than myself
since he's the person how designed it. Maybe he can help on that
El lun., 1 abr. 2019 a las 13:33, Kessler CTR Mark J
(<ma...@usmc.mil.invalid>) escribió:
> I had a little time over this weekend to try to catch up on some
> things. This is a follow up to that issue I was having about the reference
> comparison. It was a timing issue on our part that we resolved by moving
> up how quickly we store a reference.
>
>
> Here's an example of what I mean. The "initComplete" event handler
> that is inside the "MyClass" was being called before the
> "addReferenceToList". The instance was getting to its "initComplete"
> called faster and was attempting to call a method that uses its stored
> reference from a list before the "myMethod" method could store the
> reference. We are not talking about a lot of prep either. Interesting
> problem to have; no invalidation or heavy lifting before its fully
> completed.
>
>
>
> public function myMethod():void
> {
> var newInstance:MyClass = new MyClass();
>
> ...do some prep for the new instance...
>
> addReferenceToList(newInstance);
>
> addElement(newInstance);
> }
>
>
> Changed to:
>
>
> public function myMethod():void
> {
> var newInstance:MyClass = new MyClass();
>
> //swapped
> addReferenceToList(newInstance);
>
> ...do some prep for the new instance...
>
> addElement(newInstance);
> }
>
>
> -Mark K
>
>
--
Carlos Rovira
http://about.me/carlosrovira