This post is for my own future reference because I have forgotten about this problem until a recent reinstall of Windows 7.

After a clean install of Windows 7, trying to use compc and/or mxmlc from the Flex SDK through command line may yield a “System Error” message:

It seems like Microsoft somehow forgot to ship this Microsoft C Runtime Library DLL in Windows 7. When installing some programs, this DLL may be installed by the respective installers. If you encounter this missing DLL problem, the only way to fix it is to install one of these programs, or otherwise grab hold of the DLL from somewhere and place it in the correct folder:

For Windows 7 32-bit, place the DLL in
C:\Windows\System32

For Windows 7 64-bit, place it in
C:\Windows\SysWOW64

WARNING: Do not install DLL obtained from untrusted sources. You can actually copy the DLL from one of your old Windows OS installations. If you want to use my copy, here it is.

This is quite an obscure, little known, hidden-by-default feature, but the FlashDevelop IDE actually has a built-in Flash tracer. The plug-in is unfortunately not enabled by default, and new users of FlashDevelop often get frustrated wondering where to look for the output of their trace statements.

To get the tracer to work:

1) Go to Tools -> Program Settings (F10).

2) In the Plugins list on the left of the dialog box, look for FlashLogViewer and click on it.

3) On the right panel, look for the “Start Tracking” property, click on the drop down box and select “OnBuildComplete” (it is set to “Manually” by default).

The output of your trace statements are now shown in the Output Panel after you build your project.

The technique discussed below is fairly easy to implement and will cost nothing other than a few minutes of your time. You can use this method in conjunction with code obfuscation, encryption or whatever other protection methods – this just adds another layer of protection. While this isn’t going to be a 100% foolproof protection, it is nevertheless better than no protection at all, and should help to deter most if not all casual decompiling.

Continue Reading »

UPDATE: You may also refer to Hiding the Built-In Native MenuBar (And ContextMenu Items).

In my opinion, the native right-click context menu is an odd legacy from the Flash Movies days. It may be useful when Flash is used as a video player, for animations and cartoons, in the absence of any proper custom UI.

If you are developing Flash applications, you should consider always hiding the native right-click Flash Player context menu’s built-in items. Sure, you cannot get rid of the context menu completely, but you should at least hide the built-in items. It makes the application look a lot more professional because the long list of built-in items are mostly irrelevant.

Continue Reading »

Breaking a large application down into modules allows the application to be loaded in more manageable chunks. A “module” is simply a term borrowed from Flex to refer to a child SWF that is loaded into a main (host) SWF – in our context, a “module” is just like any other SWF. But, if built correctly, it should be a “stripped down” SWF – it will not contain classes that already exist in the host SWF that it is going to be loaded into. This usually means that modules cannot run standalone (which is the desired outcome in most cases, considering that the modules are intended to be loaded into the main application).

When using FlashDevelop, building a Project (pressing F8 or CTRL-ENTER) compiles a single SWF using the AS class file that has been flagged as “Always Compile”. If you are building an application that consists of a host SWF and multiple module SWFs, FlashDevelop does not automate the job for you.

Continue Reading »