Project File heirarchy help - you architects out there!!! 2004-03-19 - By ryanm
Back
> What is the best way to wire up the button actions to the Class that will
> handle the logic.
>
I often have the class attach the button from the library (as a movie
clip) and then assign the event functions to it from the class. That keeps
the code in the class and off the timeline, which makes the FLA file even
more like an asset library rather than a code library. I try to keep my
class names, library object names, and linkage names the same for a single
object, and that makes it pretty simple to break your project down into
several functional objects. Once you have the empty object created in the
library with the class and linkage name assigned, then you never need to
touch the FLA again, you just have to make code changes in the AS files and
test publish.
> Can a Class attach a movieclip?
>
Yes, if it inherits from MovieClip or is a MovieClip in the library with
a class assigned to it. Otherwise it won't have the attachMovie or
createEmptyMovieClip methods available.
> Does a Class exist as a reference on a movieclips timeline?
>
If it is a class assigned to a movie clip in the library, then it is a
movie clip, even if it doesn't inherit from MovieClip. Where this gets
confusing is when you have a class that draws it's assets in the
constructor, because then the assets are children of the class, but the
class itself has no physical presence on the stage.
> How does one Class reference another class, or it's parent (Class)?
>
Within the class it can refer to itself as this, which should return an
object reference to the instance of the class of the same type as the class.
So, obviously, this._parent will be the parent of the class, which is
usually a movie clip and contains all the properties and methods of a
MovieClip. From there you can use the usual object model to find other
objects.
What I often do is put an empty movie clip in the library with a linkage
name and a class definition. Then I drag that onto the stage and align it to
the top-left corner. Then I use the constructor and init functions of that
class to draw or attach all of the other needed assets, some of which will
be other classes that draw or attach even more assets. Sometimes, instead of
dragging it to the stage, I'll build a simple (old school, frame based)
preloader that loads in any external data I need, and then when the
preloader is finished I'll simply attach the main movie clip, which gives
the same result as above, only with a preloader first. When you attach a
movie clip with a class assigned to it, you can use the initObj to
initialize any properties of the class with a value, or even complex
datatypes. I used something like this for an image gallery:
// from within a class that inherits from MovieClip
// and is a movie clip in the library with the class attached
// and GalImage is another movie clip in the library with a
// class attached, which has a property called ImagePath
aImageArray = new Array(array of images);
for(var i=0;i<aImageArray.length;i++){
this.attachMovie("GalImage","img"+i,100+i,{_x:xPos, _y:yPos,
ImagePath:aImageArray[i]});
}
This sets the initial position of the attached movie and passes it the
path to the image being loaded. The GalImage class then loads the image,
using a preloader/progress bar, resizes it, and displays it, as well as
assigning button events to it as needed. It keeps the gallery image object
and functionality abstracted from the main GUI functionality, and keeps the
classes short. I will often have a separate class/library object for each
major functional object in the gui as well, so the main class ends up just
attaching and positioning all of the gui elements, which build themselves
and set up their own event functions and stuff. And I mean more than just
the usual components (scrollbars, modal windows) are abstracted out to their
own classes, I'll often go so far as to have something like the application
title information be it's own class, which knows how to reposition it's
child elements on the stage to adjust for long names or other elements that
may not be there all the time. Or if the gui changes layout with state
changes, the title info class may watch an event and reposition its child
elements based on application state. Stuff like that. I've found that
keeping the classes short and the hierarchy deep gives you better
performance than the other way around.
ryanm
=-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --
Supported by Fig Leaf Software
=-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --
Be sure to check the archives and the wiki:
http://chattyfig.figleaf.com/
=-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --
http://chattyfig.figleaf.com/cgi-bin/ezmlm-cgi?1:mss:107493
=-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --
To unsubscribe send a blank e-mail to:
Normal Mode: flashcoders-unsubscribe@(protected)
Digest Mode: flashcoders-digest-unsubscrive@(protected)
|
|
