I found that, as we had seen before, classes (hence, global defs) are linked
in by the flex linker (compc) on an
as-needed basis, where 'as needed' means the first time the definition is
encountered lexically
in the app file(s). For example
MyClass.as:
package {
import flash.display.*;
import flash.events.*;
public class MyClass extends Sprite {
public function MyClass () {
trace('starting MyClass');
trace('fooC', fooC);
trace('fooB', fooB);
trace('fooA', fooA);
trace('fooCount', fooCount);
}
}
}
fooA.as:
package {
public var fooA:int = fooCount.inc();
}
fooB.as:
package {
public var fooB = fooCount.inc();
}
fooC.as:
package {
public var fooC = fooCount.inc();
}
fooCount.as:
package {
public class fooCount {
public static var val:int = 0;
public static function inc () {
return val++;
}
}
}
In the code above, the app executes as:
[trace] starting MyClass
[trace] fooC 0
[trace] fooB 1
[trace] fooA 2
but if I change the code to refer to the globals in this order, the
execution order changes to match
trace('starting MyClass');
trace('fooC', fooC);
trace('fooB', fooB);
trace('fooA', fooA);
executes as:
[trace] starting MyClass
[trace] fooA 0
[trace] fooB 1
[trace] fooC 2
So the classes are linked in based on where they first lexically occur in
the app code being
compiled. So we are in somewhat good shape with regards to the order in
which globals are being executed,
except since all our LFC code is in a .swc library, the code will get linked
in an order dependent on the
app. So maybe we need to do like I started before, and have a function at
the start of the app execution
which touches all the LFC classes and globals in the order we want them to
execute.
BTW, I tried writing the globals classes as files
package {
var fooCount:int = 0;
}
package {
public var fooA:int = fooCount++;
}
package {
public var fooB:int = fooCount++;
}
that compiles into library code, but gives a player verifier error when
linked with the app.
I am filing a bug report on that to adobe.
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
