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 »