Event.RENDER fires before all on stage objects are instantiated???

[abeall]

I have an application that has several "view states", and I made the mistake of approaching the project the way it was done in AS2: I put each view on its own frame. It was too late when I discovered that gotoAndStop() no longer is immediate -- a staggering problem on many levels.

So, since I need to add event listeners and such to many(several dozen) interface elements on those frames, I've attempted to use the RENDER event to ensure the objects have all been instantiated on the frame before I access them. In other words, something like this(not actual code, there is a lot of code in my project):

function MyApp extends MovieClip(){
  stage.addEventListener(Event.RENDER,onRender);
}
function changeView(viewState){
  gotoAndStop(viewState);
  stage.invalidate();
}
function onRender(evt){
  myMovieClipOnStage.x = 5;
}

The problem is that onRender is called before myMovieClipOnStage has been instantiate by Flash. I know because Flash throws a "Cannot access a property or method of a null object reference." error, and trace(myMovieClipOnStage) outputs "null." The problem is also intermittent -- it seems that if I change states rapidly or the player window is large(so I guess render times take longer) is when it happens most often. What should I do?

And although I'm not keen on rebuilding this thing, how should have I approached multiple view states in a Flash AS3 project? There are some shared elements and some not shared.

I've also noticed that if I addEventListeners to on stage objects, even when I navigate off the frame so they no longer exist, the event keeps firing, even though I set them as weakReferences.

[senocular]

This is a big problem that was not given enough attention during development. a) AS3 was catered to Flex (no frames). b) AS3 is still fairly new and see point a).

I have found that the RENDER event (what should be our savior for these related gotoAndPlay issues) is not dependable. Two cases include RENDER firing prematurely as the result of other events, such as CLICK or COMPLETE and the fact that (bug) if you use ref.removeEventListener(Event.RENDER, ...) you will in fact remove all RENDER event listeners. Since Flash CS3 components do this... you're in a bit of a pickle.

Solutions: For basic display object usage, you can work on using the ADDED event instead of render to determine class instantiation - checking specifically in ADDED for the instance(s) you're looking for. If timing is not a super big deal, you can also use the ENTER_FRAME event to wait a frame to where you know you can be sure your instances are created. You can also go Flex-esque and not use frames for states (as inconvenient as that can be sometimes). Then you are in specific control of instantiation and would know when each instance is available and not. So instead of having something happening on different frames in your main timeline, each state would be its own movie clip symbol in the library and you would just add/remove them to the main timeline when needed or navigated to.
: )

[abeall]

Interesting. I hope this gets ironed out a little bit more in the next version. At any rate, the multiple frame route was providing no joy after a lot of tinkering, so I decided to just scrap that approach altogether and now I'm just doing a hide-and-seek routine with all interface elements on one frame -- switching views in my app simply sets the visibility to be appropriate for all display elements involved. That's quite dirty, though, as now my stage in the IDE looks like a mess with all elements visible(trying to organize layers, but still), and all the hidden display elements at runtime are still consuming resources, though invisible. It would be a lot involved to change the structure so elements are added/removed at runtime, and putting everything in a container clip poses some challenges with the current architecture. It's a small enough app I'm willing to say "it works" but I'm definitely going to have to come up with a different workflow in the future. I'll probably make each view state a MovieClip with a base class of "ViewState" and handle it from there... designing is not going to be as fun, but I might be able to put instances on the stage at design time just for reference, perhaps on a guide layer.

I wish I could get into Flex. :-/

[Flash Gordon]

Originally Posted by abeall

It was too late when I discovered that gotoAndStop() no longer is immediate -- a staggering problem on many levels.

Interesting. What do you mean by that?

[abeall]

Originally Posted by Flash Gordon

Interesting. What do you mean by that?

Imagine a timeline in Flash, where on frame 1 you have a preloader, on frame 2 you have "alpha_mc," and on frame 3 you have "bravo_mc." In AS2 you can do this:

// after preloader is done on frame 1
gotoAndStop(2);
alpha_mc._x = 55;
gotoAndStop(3);
bravo_mc._x = 100;
// etc 

In AS3, you get this:

// after preloader is done on frame 1
gotoAndStop(2);
trace(alpha_mc); // outputs "null" 

In other words, after you gotoAndStop(2), alpha_mc is not yet instantiated by Flash, so alpha_mc is null, so you can't modify its x value. You have to set up some sort of asynchronous(uuggh how I loathe asynchronous events that should be synchronous) to try and catch when the on stage elements have been instantiated. In my case I was using RENDER, which to my understanding was supposed to happen at the end of a frame when Flash is about to draw everything. Yet somehow, RENDER was firing before everything on the frame instantiated. Apparently its buggy, as senocular pointed out in several ways.

[Flash Gordon]

Alrighy, thank you for taking the time to explain what you meant.

Cheers

[abeall]

No problem. And by "a staggering problem" I just meant that the way Flash apps were almost always done(placing different major view states on separate frames and navigating between them at runtime) is no longer a reasonable way to do things.

[senocular]

Originally Posted by abeall

No problem. And by "a staggering problem" I just meant that the way Flash apps were almost always done(placing different major view states on separate frames and navigating between them at runtime) is no longer a reasonable way to do things.

I've heard of a few projects that started off as AS3 but went back to AS2 because of this, and this is something I've been continuously struggling with for my Mii Editor. I have a couple of hacked solutions, but nothing is really ironed out yet.

[Flash Gordon]

So this this something adobe plans on addressing or is it just a way of life now?

[Mazoonist]

Help me out here... is it my imagination, or....

It seems like in AS2 you could say:
gotoAndPlay('label");

and even if there was a stop() on that frame, the player would go to that frame and start playing.

Now, however, with AS3, when you say gotoAndPlay("label"), if there's a stop() command on that frame, it'll go there and stop.