Thanks for taking the time to explain all that! It absolutely makes sense that the compiler wouldn’t include non-referenced items. Otherwise our swf’s would be huge.

Cheers,

Ryan

its serious BS, but i’m glad there was a solution. Your a champ mate, long live AS3

A few months ago, I had stored Inventory data (for a game I’m developing) by storing the name of the item in an object (then created a save file from that). I ran into the problem with getDefinitionByName() described here. I just decided to just save the whole Inventory class I made instead, which worked.

Then here I was today, running into the same problem as I try to create classes for my Levels (and add them into an Array) by pulling the Level Class names from an external XML file (and create new classes using getDefinitionByName()). I ran into that whole “Variable is not defined” problem. I wasn’t sure what to do, as I hadn’t found a solution for this problem before, so thank you again for posting a fix for this error.

I wish there was a way to get Flash to just automatically include the definitions of my level classes (without me having to make a reference for each class), but this will work well enough for now.

This happens because the flash compiler does not compile classes into the SWF that it doesn’t think are being used. This is a space and time saving measure. It does not anticipate that you will try to retrieve the non-referenced classes via a getDefinitionByName call, however. So you need to reference the class somewhere in the application, anywhere in the application, which is being compiled.

I’ve found the cleanest solution to this is to make a class, say called IterativeClasses, and make a reference to any class which might only be instantiated after a getDefinitionByName call. Then make a reference to this inside your main document class. So for example, my IterableClasses class:

package ws.wild
{
import ws.wild.display.modules.CalendarDisplay;
import ws.wild.display.modules.CollectionsDisplay;
import ws.wild.display.modules.ContainerDisplay;
import ws.wild.display.modules.HomeDisplay;
import ws.wild.display.modules.MapDisplay;
import ws.wild.display.modules.MenuDisplay;
import ws.wild.display.modules.SettingDisplay;
import ws.wild.display.modules.StripDisplay;
import ws.wild.display.modules.WorldDisplay;

public class IterableClasses
{
public function IterableClasses()
{
HomeDisplay;
WorldDisplay;
ContainerDisplay;
SettingDisplay;
StripDisplay;
MapDisplay;
MenuDisplay;
CalendarDisplay;
CollectionsDisplay;
}
}
}

and inside Main.as:

public function Main()
{
IterableClasses;
…
}

And then all of those classes will work fine with getDefinitionByName.

Glad to help! I know that this one has gotten me a few times. Source order can definitely come into play depending on how the application is put together.

I have gotten into the habit of declaring the variables inside the method that actually makes the GetDefinitionByName() call which would eliminate the issue of where the variables are declared.

As to whether it’s a bug – I would have to agree. There is no mention of this gotcha (that I can find anyway) in the documentation and as you know it seems to be a bit of voodoo as to why things work the way they do.

Thanks for the comment and I’d love to see what the finished product is!

Ryan

I have been using getDefinitionByName to make an instance of a class that is defined in a package – very much like your getDefinitionByName(“screens.StartScreen”) example, and it has been workeding just fine.

Then suddenly it just stopped working, for no reason that I could find.

After some hair-tearing, I found your article here.

Then, I realised that, by chance, I had always been declaring a variable of the type that I was instantiating before I made the call to getDefinitionByName(). But, I had rearranged code, so that variable was no longer being declared before the call to getDefinitionByName().

By re-instating a decalraration of a dummy vraible of this type, the call to getDefinitionByName() has started being successful again.

So, I am very grateful for your help.

Methinks this is a bit of a bug in AS3 (well… at least an “unexpected limitation”).