My experience porting to MTASC + MX Patch

This email describes my experience in getting my project to compile with MTASC.  It covers about everything I came across.  It is my goal that people who want a better compiler environment take the effort to have one.  I hope this email can somehow assist in easing the move to MTASC.

I was hesitant to get MTASC going for my project, but I was extremely compelled to because slow MMC compile time and occasional false recompilations were hurting my project.  I read the porting notes and began compiling.  It turned out that fixes required by the compiler’s syntax checker typically uncovered poor code (such as redefined variables) and revealed actual bugs (MTASC’s stronger type checking identified misuse of numbers treated as Strings).  My time with MTASC had already paid off.

My usage of mx classes and Libraries complicates my project.  The development environment that I have now doesn’t free me from MMC entirely, but my development process is usually free of MMC, and it is clear when I need to use MMC.  Using MTASC instead of MMC is a huge time saver.

Another goal in this email is to ask for help about the MX Patch and abut how to not use the Library.

Regards,

-Bruce Allen

Porting to MTASC

1.  I Started with the MTASC document and reviewed the porting issues.  I then Began compiling my code using the “-mx” option, and made fixes, until everything compiled.  This involved the following:

I made minor syntax changes for differences such as dynamic functions.

In my case, I did not use the strong typing syntax recommendation for Arrays.

I set up my environment for compiling with MTASC.  I prefer not to set DOS environment variables or use IDEs or ant.  Instead, I keep a DOS window open, and invoke my one liner compilation script “c.bat” by typing “c”.

2.  Background

My application has the following characteristics:

Everything loads in the first frame.

The application consists of 3 .swf’s that I’ll call .swf1, .swf2, and .swf3.

File .swf1 is a Flash Form Application with Library items and requisite classes for all mx components, my shared custom code, and RadioButtons for starting the two primary applications .swf2 and .swf3.

Files .swf2 and .swf3 are Application .swf’s compiled as Flash Form Applications, but started using loadMovie from .swf1.

Files .swf2 and .swf3 compile with the “-exclude” directive to keep out mx classes and shared custom classes which are already in swf1.  Files .swf1 and .swf2 contain classed stage objects with entries I their Libraries.

I needed to add references to some of my classes that are bound to stage objects in order to get them included in the compilation.  Specifically, if a class such as “MyComponent” is loaded by its name via a call such as createClassObject, but it is not referenced directly by other code being compiled, the compiler will leave it out.  To ensure inclusion, I create simple references such as “var dummy:MyComponent”.

At this point, step 2, above, is completed, and all three .swf’s compile using MTASC.  Issues involved during the porting process were corrected such as removing multiply declared variables and adding typing to untyped variables.  In some cases, fixes resulted in the correction of actual bugs.  My time put into MTASC has just paid off by having better and corrected code.

3.  At this point, when compiled by MTASC, .swf2 and .swf3 work, but .swf1 fails to run.  I suspect that there is an ordering issue involved in initializing a Flash Form Application, having component code in .swf1 from MMC, and having the classes (except for mx) put in from MTASC.  Files .swf2 and .swf3 work because they run from being loaded from .swf1 rather than running as the initial application.

Regardless, I can compile .swf2 and .swf3 with MTASC and use them without having to use MMC unless I change the Library.  I can also compile .swf1 with MTASC until I get the syntax errors out, then compile .swf1 with MMC to use it.  Reaching this step was a big milestone.

Comment:

Compiling each .swf by MMC costs 20 to 40 seconds, and sometimes it can take a whole minute.  Sometimes some classes fail to recompile, and I need to delete the hidden “aso” directory, and recompile twice (the first compilation fails with a complaint about a naming conflict over “System.capabilities”).  With MTASC, compiling my largest .swf takes under three seconds, and the compilation result is always consistent.  Big difference.

Comment:

I avoid creating classed stage objects that have components placed in them on the stage.  Instead, I load requisite components during runtime using createClassObject.  This helps in two ways: 1) I don’t need onLoad handlers to wait until stage objects are ready (Flash doesn’t create components placed on the Stage until later, after the component’s “init” method has been called), and 2) by having an empty Stage, I can change component properties via code.  This way, changes don’t affect the Library, and I don’t have to compile with MMC to get the Library updated.

Comment:

I include this comment because I never read it anywhere:  In relation to the “with” statement, MTASC and MMC produce different code.  When inside a “with” statement, the value of the “this” property is unaffected by the value of the target of the “with” statement in MTASC, but seems to be null for MMC.  I removed usage of “this” inside “with” to be compatible with MMC.

4.  At this point, I really want .swf1 to run when I compile by MMC.  To do this, Nicolas Cannasse recommended that I install the MX Patch and get rid of the “-mx” option.

To prepare for the patch, I reviewed the MX Patch document, and began.  I 1) Started with the Flash 8 Component classes, 2) Added Macromedia’s Flash Remoting MX Components update, 3) Copied the Macromedia classes to the path where I would modify and use them, and 4) Ran the “patch” utility to install the patch on my copy.

In my case, the patch failed at first with “Can’t rename file” … “mx/remoting/Connection.as : File exists”.  Igor Sadovskiy recommended checking file permissions.  It turned out that some of the Macromedia files were read-only.  I fixed this, and the patch installed.

I modified my compilation script to not use the “-mx” directive and to obtain classes from my new patched class files, and compiled.

5.  Compiling with the Patch installed:

Initially, compilation failed because the Compiler needed to resolve classes relating to mx that my code did not currently include, such as “mx.screens.form”.  Once included, everything compiled.

At first, execution crashed with a blank screen.  I read about “trace” issues.  I removed “trace” and then things mostly worked.

Regarding trace:

My diagnostics logger has static method “trace” which unnecessarily called native function “trace” which seemed to crash the Flash player.  I removed the native “trace” and now Flash runs.  The “-trace no” compiler directive doesn’t fix this for me (possibly because I embed the native trace method inside the static trace method of my logger class?).  I don’t need the native trace anyway, so I took it out.

At this point, the application worked, but many of the Windows didn’t show content because of trouble with the UIObject “load” event.

Regarding the UIObject “load” event:

The UIObject’s “load” event does not trigger.  Many of my windows wait on this event to know that the Window is loaded so it can create components within the Window.  I rewrote the code to use the Window Component’s “complete” event instead.  This avoids the problem and, for me, results in a cleaner implementation than using “load”.

At this point, all the mx Components work correctly, but two of them render incorrectly.

Patch Rendering issue 1:

When there is not enough content to need the scroll bar, the UIScrollBar shows what looks like “SimpleButton” icons where the up and down arrows would be, and this should be blank.  When there is enough content to scroll, the UIScrollBar is rendered correctly.

Patch Rendering issue 2:

When I have multiple Buttons in the Alert component, they are drawn too wide if the cursor is not over them.  They draw correctly when the cursor is over them.

6.  At this point, I enjoy MTASC for the following:

Compiling .swf2 and .swf3 unless the Library changes, then I use MMC.

Compiling .swf1 for development.  I compile with MMC for production (because of the rendering issues) or if I change the Library.

Although I can’t deliver .swf1 to my client, my development cycle is generally pure MTASC without MMC, which was my primary goal.  No more iterative slow compilation time.  This change has made a huge impact on the progress of my project.  Many thanks to MTASC and its contributors.

7.  Future goals (with help from the community):

One goal is to get the Patch rendering issues corrected so I can use .swf1 compiled by MTASC in production.

Another goal is to reduce or eliminate dependency on the Library.  I want to be able to create classed stage objects without having to create a blank Library entry.  I have reviewed several articles on this, but I haven’t figured it out.  It seems like I should be able to take an entry out of the Library such as Symbol “MyComponent” with Identifier “MyComponent” and class “myPackage.MyComponent”, and replace it with early initialization code such as: “static var dummy=Object.registerClass(“__Packages.myPackage.MyComponent”, myPackage.MyComponent)”.  But this doesn’t work.

Another future goal might be to port everything to haXe and compile it to run AS3 on Flash9.  To do this, I would need to port my usage of mx-based components to whatever is available for haXe.  I can only do this if the structural changes relating to the usage of mx components are minimal.