Re: [Asunit-users] MovieClip utility ?!

[Luke B. <lb...@gm...>]

Hey There,

You're absolutely right to be confused, this matter is very confusing...

I'm going to try to separate this problem into smaller peices if I can.

Basically, what we're talking about is MovieClips.

Because of the rendering Engine built into Flash, we can logically
break up any objects in a Flash Application into 2 types:

1 - MovieClip 
2 - Non-MovieClip.

The only major difference between MovieClips and Non-MovieClips is
that you must use the MovieClip Factory
(MovieClipInstance.attachMovie(args); ) to actually instantiate a
MovieClip and have it render on Stage. *You CAN instantiated classes
that extend MovieClip without using this factory, but they won't
render because they're not a member of the composite MovieClip
structure that begins at Stage.

Within the MovieClip type, there are actually 2 subtypes based on
their definition.

1 - MovieClips that exist in a .FLA library as a Symbol
2 - MovieClips that exist only as an ActionScript file that extends MovieClip

MovieClips that exist in a .FLA library, do not need any linkageId,
classRef or serializable properties as they will be imported when the
.FLA is compiled.

In order for MovieClips that exist only in ActionScript to be imported
into a Library and registered as a valid "attachable" (and actually a
"serializable") element, one must call
Object.registerClass(someUniqueLinkageId,
theConstructorOrClassDefinition)...

We provide access to this "hack" using relatively elegant (methinks)
solution by storing the result of the registration in a static member
named, "serializable"... This registration can also apply to
non-MovieClip classes that you would like to store in
LocalSharedObjects, RemoteSharedObjects and LocalConnectionObjects...

There are at least two reasons to extend MovieClip in your Class definition:

1) You want the compiler to not fail when you try to access the
Methods and Properties of the MovieClip object.
2) You want your IDE (PrimalScript) to provide code hinting for member
methods and properties that exist on MovieClip.

Basically, what we're trying to expose in our "Create Class" command
is the ability for people to:

1) Create Classes that are NOT MovieClips
2) Create Classes that are MovieClips and exist in the Library
3) Create Classes that are MovieClips and don't exist in the Library

Unfortunately, our Template code is very simple and inelegant and we
have a priority to try and keep it that way. So our auto-created
TestCase does not actually instantiate MovieClips properly - hence the
example to show folks how that might be done using a more efficient
factory. (Found on TestCase)

I agree wholeheartedly that our User Interface should show some
exclusivity on these selections, and would be glad to see your
suggested improvements. It's a little difficult because Macromedia did
not give us a complete "XUL" implementation, they just gave us a XUL
"Dialog" - but in spite of that, I think that what you're asking for
could be implemented.

Please let me know if this does or does not answer your question.


Thanks,


Luke Bayes
www.asunit.com