For whatever reason, it appears Macromedia shipped FlashMX04 with the classPath order mixed up. Thankfully, we can fix it – and I REALLY urge you to do so, right now!
As with any system of this sort, the order in which Flash should search for class files should be explicit to implicit, local to global. This should translate into Flash searching classPaths in this order:
- Paths you explicitly set in the publish settings of a project (FLA)
- The implicit project path (ie. the path of the FLA)
- The implicit global path (ie. the built in global classPath)
Unfortunately, by default F04 searches in this order: explicit, global, project. This can really throw you through a loop if you try to override the built in classes for a project.
Fortunately, you can fix this problem:
- In preferences, under the ActionScript tab click the “ActionScript 2.0 Settings…” button
- In the Classpath listing, you should see two entries. The first should be something like “$(UserConfig)/Classes” (this is the global path). The second will just be a “.” (this is the project path).
- Click on the first entry, and click the down arrow button to swap its position with the second (“.”).
- Click OK to exit the dialogs
There, now Flash will act logically when searching classPaths. Thanks to Phil for noticing the “.” (project path) – I really gotta clean my monitor! 🙂
Luckily, I had modified the settings since the early days in the order, myCustomPath, then the project Path and then the global path.
Well, they’re correct as shipped in as much as we didn’t anticipate that folks would want to override the built in class structure in favor of having the classes in your project (for the built in classes…)
—
Regards,
Bentley Wolfe
Senior Support Engineer, Macromedia
Flash Senior Escalation Engineer
Announcing MX 2004. New versions of Dreamweaver,
Flash, Fireworks, Studio and the new Flash Pro. http://www.MX2004.com
No offense intended Bentley, but that’s kind of a naive statement. If developers didn’t want to override built in classes, they simply wouldn’t replicate those package/class names in their local project. As is, the default settings will only serve to confuse people (myself included) when they try to override existing classes.
I expect this was just an oversight, but fortunately it is easily corrected – however, I do anticipate it will cause some confusion as people start sharing enhanced versions of the built in classes (such as the enhanced versions of EventDispatcher and UIEventDispatcher I will be releasing shortly).
Anyway, useful post. It is better for developers to understand these nuances %)