[mtasc] 1 frame delay

[Nicolas Cannasse]

> If classes are exported on frame 1 (which is really before frame 1), then
> they are ready by frame 1 & registered so I don't understand; was someone
> having problems with their classes taking more than 1 frame to register?
>
> Could you elaborate on how you weren't getting a reference to the loaded
> clip before?  If I override _root's __proto__, and run my own class, he's
> immediately available.  Naturally, components utilized within him that are
> created at authortime take a frame before they can be utiliized, but that
is
> why we have onLoad.  If our SWF is loaded into another one, we can still
use
> onLoad.

The problem is the difficulty for MTASC to correctly order the classes when
used with -mx or -keep.
The class order must be preserved since with any class B "extending" A , you
need to define first A and then B. Is is easy to do for MTASC when it
compiles all the program and have all the classes, but is tricky when
updating an already generated SWF. Currently then MTASC try to insert the
classes it compiled at the "best place", so some classes already present in
the SWF might be defined after MTASC ones. We could also add a call to
"main" before the Nth Frame is displayed, as a normal action, but if there
is already an action in the SWF, how is MTASC supposed to choose where to
put -main ? before or after ? Hence the choice to have it executed on the
onEnterFrame event which is convenient : it will not depend where the "main"
is put into the SWF since it will be delayed until enterFrame event.

Nicolas