Yeah I'm reading Essential Actionscript (Moock) right now, and he does
somewhat reduce confusion. Part of the problem is that older methods
that have sort of been practically deprecated by AS 2 are still given
out by others (#initclip and registerObject() ) are confusing as they
appear completely reduntant to extending MovieClip).
That's true. Since I started writing AS2 code I have never used
#initclip, and registerClass only rarely. The trend is definitely
toward a more standard OO programming style.
The load order still confuses me. More precisely than my first post, I
am wanting in general to be able to develop applications where ALL
actionscript is in external .as files (which I generally edit in
better editors than the Flash IDE, and then the FLA file simply
#include's some main code, or creates a single instance of class Main,
and calls Main.main(). The FLA file is then used solely for media
assets.
If I do this, how can I be sure, for instance, that class Main is
actually initialized before any other classes and can then control the
initialization order from Main? I suppose I could simply avoid static
initializers, but I don't like running away from a supported language
feature simply because I'm unclear about its runtime behavior.
It sounds like you might be confusing initializing with loading. When
you set your classes to load on a frame other than frame #1, in my
experience anyway, it's so that you can make sure that your whole app
is loaded in the browser before it starts executing. This is an issue
because Flash loads progressively.
For example, you could have your preloader code (checking
_framesloaded against _totalframes, say) running in frames 1-10, and
have your classes set to export to frame 11. When your preloader
determines that all frames have loaded, it can gotoAndPlay() to, say,
frame 20, where your app code is. I would bet that static classes are
initialized as soon as they are loaded, but they are only
instantiated when you tell them to, as in
var foo:MySingleton = MySingleton.getInstance();
That's just a prediction though; I'd verify it with trace statements.
Hmm so I could change the export frames for classes to explicitly
order their loading, but this forces a multple frame main movie ( a
minor annoyance). Still, does a static property get initialized when
the class loads? E.g:
class MySingleton {
static private var instance = new MySingleton();
private function MySingleton() { // whatever init code
}
public function getSingleton() { return instance; }
}
I am wondering exactly when does the instance come into existence. For
that matter, with the default loading of classes at frame 1, are
classes then loaded only after all exported library assets are loaded?
I believe your app loads and executes in timeline order. I usually do
like I describe above: have preloader code on frames 1-10 or so,
export classes and symbols to load at frame 11, and start the app on
frame 20.
You are smart to keep as much of your AS code in external class files
as possible. But this being Flash, a little bit of timeline setup is
usually necessary. Moock has a good bit about this in EAS2.
In general, 'this' refers to the object of current scope. When used
in a class, it refers to the class; when used on a frame in the Flash
editor, it refers to the current timeline; when used in a callback,
it refers to the object that owns the callback.
This has been my understanding, but it seems I've run into a few
situations where the behavior is different, and one case where "this"
turned out to be undefined! Unfortunately I cannot remember the case,
but it still bothers me. When would this == undefined? I believe it
was within a class method that was given as a callback from code
running on the main timeline, and I had assumed this would refer to my
class, or at least to the main timeline.
Yeah, scope is a recurring problem for me too, like with callbacks
and event listeners. Not sure when this would return undefined
though. One thing that sometimes helps is using Delegate.create() in
your addEventListener statements; it lets you scope the event to a
class instead of to the thing generating the event, which is a pain
in the ass.
This does seem the way to go, when the attached stuff is generating
multiple attached clips. Would be nice if AS had some way to
*actually* attach to to the next depth. Could easily write a function
to do this I suppose, by checking subsequent depths for the presence
of a clip... Just seems like not having to specify any depth would be
good, where you could assume that all subsequently added clips stack
above previous ones.
Sometimes you want to control this manually though. If it's a few
clips that are unlikely to change, I often hardcode the depth; if
it's a dynamic number, like from an array, I key the depth to an
array iterator, and if it's more chaotic than that I use
getNextHighestDepth.
While thinking about it, what is the rationale for attachMovie() both
returning a movie clip instance and taking a name for a variable as a
string? I always end up storing the return variable (if I need it
later), and sending something like "foo" as the variable string. It
seems clunky to be giving a variable name as a string. Are there any
differences in the object assigned to the passed variable name and the
returned object? It's confusing.
This is an excellent question. Let's take a look at an example:
var mypanel:MovieClip = target.attachMovie("menuPanel",
"menuPanel_mc", 0);
Maybe the easiest way to think of this is that the variable myPanel
is for YOUR benefit and menuPanel_mc is for FLASH's benefit. myPanel
holds a reference to the movieclip object that Flash identifies as
menuPanel_mc in its hierarchy. Assigning variables to what is
returned by attachMovie() is an easy way to refer to an mc in a class
file, especially if your app is complex and has a lot of mc's, as
most apps are and do.without myPanel, above, you'd have to know
exactly where menuPanel_mc is in the whole Flash depth system if you
ever wanted to refer to it again. This can get hairy real fast if
you're using components like scrollPanes. But by assigning it a local
var in your class, you can manipulate it by using that var, instead
of trying to keep track of _level0 and _root and what clips you've
attached where.
That's my understanding anyway.
Thanks for the other book recommendations. I'm always mystified how
authors like Moock get the information they include in their books,
that does not seem to exist in Flash's documentation...
I know Moock works directly with members of the Flash development
team in writing his books. But yeah, he's a good writer, and he makes
clear what would otherwise be very confusing. I have also heard
recommendations for Joey Lott's new Advanced ActionScript 3 book:
http://www.amazon.com/Advanced-ActionScript-3-Design-Patterns/dp/
0321426568
Good luck,
OK
DAH
_______________________________________________
[email protected]
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
