referencing a loaded clips class

[ericflash]

If I post the files can someone tell me why this is not working as its driving me mad. Maybe it might help someone else that may run into the same problem.

Please let me know if someone can take a look at the files and I will post them.

Thanks,

[5TonsOfFlax]

If the files are .as files, I can take a look. But I can't open/edit .flas

[ericflash]

The files are all AS files but if you make a change or try to do a test then you won't be able to run them without been able to publish the fla. So not sure how you will be able to figure it out without been able to test.

I can still send you the as files if you like.

[5TonsOfFlax]

Gimme.

[ericflash]

Here you go thanks again for looking at this.
ZIP FILE

[5TonsOfFlax]

Okay, I had to add several classes to get it to compile: Tab, TitleText, IconMask, Textholder, and of course BoxAnimation. I'm assuming that you have all of those in the fla library. Did you make sure that BoxAnimation has the whole export for actionscript stuff set?

[ericflash]

I mentioned in an earlier post it would throw an error for any added assets from the library. So that's why you were getting errors for all the others as they are all assets from the library of the Home.swf been loaded into the Main.swf

[5TonsOfFlax]

Actually, I think I get it now. First, the explanation of the problem:
When you compile Home.swf, the generated class for BoxAnimation is embedded in the swf, but no actual BoxAnimation.as file is created. This is fine for Home.swf, but when trying to compile Main (which uses the Home class, and therefore must compile it too), those assets are not in the FLA, and can't be found.

Now, an answer:
Go back to the Interface idea. Define an interface that Home will implement, and use that instead. This will prevent Main from trying to compile Home, and things should be cool. Note that you might have to fiddle with the ApplicationContext when loading Home to be sure that the class definitions are the same between the two swfs.

[ericflash]

Actually, I think I get it now. First, the explanation of the problem:
When you compile Home.swf, the generated class for BoxAnimation is embedded in the swf, but no actual BoxAnimation.as file is created. This is fine for Home.swf, but when trying to compile Main (which uses the Home class, and therefore must compile it too), those assets are not in the FLA, and can't be found.

Correct in all the above thinking.

I got it to work using the Interface Class. It didn't complain at all.
I still don't understand why it would not work the other way. I used to do it the other way all the time with AS2 with no complaints. I would have a controller reference on the main timeline that I could reference as my Main class.

Thanks for all the help.

[5TonsOfFlax]

I could be wrong, but I don't think AS2 is compiled to bytecode. All the references and things are interpreted/evaluated at runtime, which allows for some tricks/abuses like that.

Personally, I like that AS3 ensures that things are defined in a non-ambiguous way before they blow up at run time, but I can see the appeal of the fast and loose AS2 behavior if you never run into the situations where things aren't well-defined.

[ericflash]

So my last question so I can learn something new and wonderful from all this abuse to my head for the past 6 hours . Can you explain how does Interface allow the Main class to reference the external class without throwing errors for children of the external class.

[5TonsOfFlax]

Sure. The reason it threw the errors before came down to the fact that Home was referenced in Main, and therefore had to be compiled. If you remove the direct reference to Home and replace it with an Interface, only the Interface needs to be compiled for Main to work. Home can then be compiled separately, and as long as it implements the interface, it can slip in later.

An interface is exactly what it sounds like - a way of specifying that something will have certain methods without worrying about what the implementation of those methods is. Main can compile with just enough information to know that something with a startAnimation method will be in later, but it doesn't have to worry about what that something is at compile-time.

[ericflash]

Thanks for the explanation I see how it works with the startAnimation method because I have it in the Interface as a method also but what about all the other methods like BoxAnimation that were throwing errors when referenced by Home in the Main.as?

[5TonsOfFlax]

Those are not referenced in Main, and Home is not referenced in Main either. So they don't need to be compiled in order for Main to compile. It is up to Home how it wants to implement startAnimation, including any and all things that it depends on.

[ericflash]

Ah ok starting to make sense now. Thanks so much for sticking with this thread and helping me understand this. I hope this helps other people who need to reference external classes.

Thanks so much again

[ericflash]

I just realized there is an easier way and a more efficient way of dealing with this problem.

Instead of using the Interface which is still a great way to get around this. I used a dispactEvent and listener instead.

So in my Main class I dispatch an event.

	public function onChangeSlide( evt : TabEvent) : void{
			
			var slide : Sprite = arrSlides[evt.arg.ID];
			slide.dispatchEvent( new Event( 'onStartSlide' ));
		}

Then in my Home Class

		public function Home( ) 
		{
			this.addEventListener('onStartSlide', startAnimation);
		}

Works like a treat so far but might be an even easier solution to someone out there. The Interface idea is still a great option too and one I would have never know about without 5TonsOfFlax

[5TonsOfFlax]

The event dispatch is a great solution in your case. In the case where you wanted to pass parameters to the method or return a value from it, rather than just kick it off, an Interface would be more well-suited.

There's definitely room for both approaches.

[ericflash]

I totally agree.