Flash Tutorials

Flash Printing AS 3.0

Danny — Tue, 15 Jul 2008 18:08:00 GMT

Printing in Flash can be extremely simple, but also has the potential to get quite complex as your needs become more involved. Fortunately, Actionscript 3 makes it easier, and in some cases you will not be able to get a good print in earlier versions of Actionscript. So let's get started with some of the printing basics.

Print Classes

In Actionscript 3 you have 3 classes used for printing. You can include all three of them in your project with the following line:
import flash.printing.*;

That import will give you access to the following classes:

flash.printing.PrintJob: This is the workhorse for printing. This class gives you the means to pull up the print dialogue, and then add your content before actually executing the print command. The PrintJob also has information about the width and height of a printed page as determined by how the user sets up their print options. These values can vary dramatically even with the same paper size across different printers.
flash.printing.PrintJobOrientation: This is the class used to determine the print settings the user selected. It is important to note that you cannot force page orientation to be what you want. It is completely defined by what the user sets up in their print dialogue. This class exists mainly to detect if the user chose landscape or portrait layout when they printed.
flash.printing.PrintJobOptions: This class feels kind of strange to me because it basically extends the Object class and adds a single boolean property. It is used when you add pages to a print job to indicate wether or not you want to print as a bitmap. I am guessing that future updates will extend this object to include more options and tools, but at this point, it seems kind of strange to have to pass a specific object as your parameter when a boolean would suffice. We will discuss why you will want to print as bitmap, and also reasons why you may not want to.

Basic Printing

Doing really basic printing is very quick and easy. The following is code that will print a red square to your page:

var pj:PrintJob = new PrintJob();
if(pj.start)
{
     var tSprite:Sprite = new Sprite();
     tSprite.graphics.beginFill(0xFF0000,1);
     tSprite.graphics.drawRect(0,0,100,100);
     pj.addPage(tSprite);
     pj.send();
}

Page Orientation

Printing a red square is not all that exciting. Even printing an existing Sprite or MovieClip can be difficult. You may need to do something as follows (assume printSprite is the sprite we want to print and it is already defined and created):

var pj:PrintJob = new PrintJob();
if(pj.start())
{

if(pj.orientation == PrintJobOrientation.LANDSCAPE)
{

      if(printSprite.width<printSprite.height)
      {//we just detected that our printed sprite is actually portrait in it's layout.
            printSprite.rotation=90;
      }

}
else if(printSprite.height<printSprite.width)
{//we just detected that our printed sprite is landscape in nature but our page is portrait
    printSprite.rotation=90;
}
pj.addPage(printSprite);
pj.send();

printSprite.rotation=0;//reset just in case it is also displayed on screen.

}

Rather than try to force the user to use a selected page layout, you may want to just intelligently modify your printed object to work best with what they chose. Of course, you will want to consider usability when doing this because it could prove frustrating to a user if they actually want to print the flash in a way you are now prohibiting. The above example does however demonstrate some of the basics to work with page orientation.

Multi Page Printing

Printing becomes most useful when you can handle a dynamic number of items to print, and work out all the paging accordingly. Say for example you have an array of custom objects that may be part of a shopping cart or something of that nature. If you want to print a shopping cart that could have any number of items, you will have to understand how to print multiple pages. The following example assumes that a utility function has been defined and that it creates a Sprite to display a single instance of a class CartItem, and that we have an array of CartItem objects called cartItems. It is also not going to worry about page orientation for this example.

var pj:PrintJob();
var curPage:Sprite = new Sprite();
if(pj.start())
{
for(var i=0; i<cartItems.length;i++)
{

                var cItem:CartItem = cartItems[i] as CartItem;
                var printSprite = buildPrintCartItem(pj.width,cItem);
                if(curPage.height+printSprite.height <pj.pageHeight)
                {
                    curPage.addChild(printSprite);
                }
                else
               {//go with our current page then start a new page with the latest cart item in it.

                  pj.addPage(curPage);
                  curPage = new Sprite();
                  curPage.addChild(printSprite);
               }

}
pj.send();

}

Important: It is very important to note that anything that happens in the buildPrintCartItem function must finish it's visual creation without any asynchronous behavior. If for example, your buildPrintCartItem were to load an image from a url, you would print before the image load completes. It is not very safe to try and wait for those load events to complete because you have a finite time in which to call pj.send. If you need to have external images printing, you will hopefully be printing images that are already somewhere in your display tree. If that is the case you have to actually pull the image from your already loaded DisplayObject. It is then up to you to make sure that you keep a copy of the displayed item on screen while using the already created one in print.

Printing as Bitmap

For most printing needs, you can get what you need with variations of the code above. However, there will be times when you will need to set up a PrintJobOptions object and pass it into the pj.addPage function.

var pjo:PrintJobOptions = new PrintJobOptions(true);
...
...
pj.addPage(curPage,null,pjo);

The second parameter takes a Rectangle object you can create from the flash.geom package. It can be used to define a specific portion of the Sprite that will be printed. I am sure that can be useful, but I haven't had much cause to use it so far.

Why use printAsBitmap?

Transparency Support: If you have transparency in the content you are printing out, you will need to use printAsBitmap. Otherwise all areas that have less than an opacity of 100% will print as white. Gradients are supported so long as every color in the gradient has full opacity on it. If you have gradients with transparency in them you cannot print them correctly without printAsBitmap.
Blend mode support: Any blend mode other than normal will not print correctly without using printAsBitmap.

Why not to use printAsBitmap

Font quality: When you print it as a bitmap it basically converts the displayed information to a 72dpi raster image. Printers usually can work with font files to give you quality printed text. When you convert to raster, you lose the font information and your fonts will look pixilated.

Advanced Bitmap Printing

It is possible to essentially do a hybrid of the two methods, but it can be more work. There is a way to make a bitmap copy of an existing DisplayObject and use that for your printing. So you could write code that finds a target DisplayObject that won't print without being printed as bitmap. This code can basically make a raster representation of that DisplayObject and return it to be used in your print. If you do this, you won't have to use printAsBitmap because you have essentially done the work on your own. The following code will give you a raster representation of a Sprite:

//make sure to import flash.display.BitmapData and flash.display.Bitmap

private function makeBitmapCopy(sp:Sprite):Sprite
{

var bmd:BitmapData = new BitmapData(sp.width,sp.height);
bmd.draw(sp);
var bmp:Bitmap = new Bitmap(bmd);
var returner:Sprite = new Sprite();
returner.addChild(bmp);
return returner;

}

From here it will be up to your code structure and architecture to be built in a way that allows you to easily make the bitmap copies as you are building each printed page.

Final Thoughts

This tutorial should give you all the tools you will need to understand the capabilities of printing in Flash. I do recommend that you install a print driver that will print to PDF or something along those lines. That way you can print and debug your printing process without plowing through reams of paper. Make sure however to test on actual paper, preferably on a wide variety of printers to make sure you properly account for differing page sizes etc.

Using a Flash Project (flp)

Danny — Sat, 12 Jul 2008 00:32:00 GMT

With the fully object oriented nature of Actionscript 3.0, it is more important to have a means of managing multiple Actionscript files. Flash Project files are a good step in the right direction. You still have to deal with some frustrating deficiencies in the Flash authoring environment, but it is a huge improvement compared to working without. This article will walk you through setting up a Flash project, and how to set up your classes and packages appropriately. This is a pretty basic article, but it should help you get started creating and working with projects. All of the instructions are for Flash CS3 Professional, but they should be identical or similar for other versions.

Starting Out

After you have opened Flash, you will want to create a Flash project. Set up a directory where you will be working for your project. I generally keep the project file (flp) in the root directory. The flp file is nothing more than a simple file that tells the Flash environment what files to make available for easy browsing etc. It also includes any information about source control connections. An flp can connect and work relatively well with common source control programs such as Visual Source Safe. If you are used to the complete integration you get with Visual Studio and VSS, you will be slightly frustrated with Flash, but it is better than nothing.

To create your flp file, click on File->New and choose Flash Project. The dialogue will ask you where you want to create the project. Choose your directory and give the project a name.

In order for the flp to have any real meaning, you will need at least one Flash file (fla) that is set as the default. So first off, lets create a flash file (Actionscript 3.0). Save that file in the root of your project directory. Once you have created your fla file, add it to the project. To do this, you will want to make sure that the Project palate is open. To open it, click Window->Project, or press F8.

The Project palate displays the contents of your project in a tree structure.

Click on the page-like icon on the top left and select Add File. Browse to the fla you just saved and add it. Now right click on that fla file and select Make Default Document. This provides you with a nice feature, that is enough to use an flp by itself. From now on, if you have the fla file open, it will always run if you hit ctrl-enter on the keyboard. You can have your focus on an Actionscript file and still run the project immediately. Without using an flp, you have to switch focus to the fla to run it every time. I usually open the fla file and minimize it.

IMPORTANT: The file structure displayed in in the Project Window is whatever you define it to be as you create the project there. It has nothing to do with the folder structure of any location on your computer. It is best practice to create folders in your project that correspond to folders on your computer, and to keep files in your project in the same location as they are found on the computer. However, there is absolutely no connection between a file you can browse through the Flash Project palate, and its location on the computer. This means that saving a file in a directory on your computer will not make it show up in the Flash Project palate. What you can or cannot browse in the Project palate also has no bearing on what is or is not used when you publish your swf. The Project palate is basically a single convenient place to access files in flash.

Creating Classes

I like to develop flash applications more like a traditional application than a lot of developers will do. You can incorporate timeline driven behavior through symbols in the flash library etc, but I don't like to have lots of Actionscript spread around timelines etc. I usually create a parent class that basically runs the application. It utilizes child classes to then take care of each aspect of the application.

So usually, my main fla file will have a library with symbols and other resources, and a few lines of code, something like the following:

import classes.MyApplication;
var myApp:MyApplication = new MyApplication(/*parameters like a url or xml file path etc that can get the ball rolling*/);
this.addChild(myApp);
myApp.run();

A few other tricks may be neccesary to do things like read from the query string and initialize the parent application accordingly, but my fla files will rarely have more Actionscript than this anywhere in the actual fla.

In this example, you will want to create a file folder on your computer called "classes". This folder should be in the same directory as the fla and flp files. Inside that folder you would save a file called MyApplication.as. Then add a folder to your flp called the same name, and add the file inside that folder.

Your MyApplication class could look like the following:

package classes
{
   import classes.myTools.*;
   import flash.display.Sprite;
   public class MyApplication extends Sprite
   {
      private var myTool:ToolOne;
      public function MyApplication()
      {

     this.graphics.beginFill(0xFF0000,1);
     this.graphics.drawRect(0,0,100,100);
     myTool = new ToolOne("red");
     this.addChild(myTool);

   }
   public function run()
   {
      myTool.doSomething();
   }
}

}

This is a very trivial and useless class, but it demonstrates a few things. First it shows how you would extend an existing DisplayObject class such as a Sprite. About 95% of the classes that I write for a Flash application extend the Sprite class. If you need timeline functionality then you should use the MovieClip class. The Sprite is leaner than the MovieClip and provides all the functionality other than the timeline stuff you get in a MovieClip.

The second thing this leads us into is how to set up child packages. The import classes.myTools.* means that the system will look for a myTools directory inside the classes folder on your hard drive. (Remember not to confuse hard drive file location with a flash project's displayed structure.) The system will then include, and provide programatic access to all the classes defined in that directory. They do not have to be part of the flp so long as they exist in the right location on the hard drive. As has already been mentioned, it is strongly recommended to keep the flp's organization matching the file structure exactly to avoid confusion.

So let's get started by creating the ToolOne class. Create a folder inside the classes folder called myTools. Then create an Actionscript file called "ToolOne.as".

IMPORTANT: Remember that in Actionscript, the name of the file and the name of the class defined must match.

Now you could write a class as follows:

package classes.myTools
{

package classes.myTools
{
   import flash.display.Sprite
   public class ToolOne extends Sprite
   {
      private var col:String;
       public function ToolOne(c:String)
       {
           col=c;
           this.graphics.beginFill(0x0000FF,1);
           this.graphics.drawCircle(0,0,5);
       }
       public function doSomething()
       {
            trace("color passed in to me:"+col);
       }
   }

}

}

Again there is nothing spectacular here, but you see a working example how to organize your classes. Note that the package path above needs to match the directory structure on the computer relative to your project's root. It is also worth noting that general practice is to have package names be camel-case (eg myTools or myHappyDayToolForBob), and have actual classes be the same except the first letter always capitalized (eg ToolOne or MyHappyDayToolOne).

At this point, you are ready to run your project. If you either hit the test project button, or hit ctrl-enter (assuming the fla is still open), you should get a swf that has a red square and a blue circle. It will also display "color passed into me: red" in the output window.

Final Thoughts

The example here is obviously useless, but it should walk you through how to get a simple project set up, and give you the basic principles needed to set your classes up. If you apply these basic principles correctly, the Flash Project becomes a very handy tool to keep organized while building complex, enterprise-level applications that utilize a broad library of classes and tools.

Creating and Handling Events AS 3.0

Danny — Fri, 11 Jul 2008 23:13:00 GMT

Actionscript 2 uses broadcasting functionality to handle its events. In Actionscript 3 we get an upgrade in functionality to a truly event-driven model. The new event model gives us a more structured and ultimately a more powerful way to handle our events.

New Functions

DispatchEvent:DispatchEvent is a function that is available in the common classes used in Actionscript 3. Any DisplayObject already has the function included. DispatchEvent is analogous to BroadcastMessage in Actionscript 2, although I feel it is actually an upgrade. DispatchEvent takes an Event object as its parameter. This allows more refined control of how the event will behave. You can define if it will dispatch up one level, or if it will bubble up until it is caught. You can also define if you want the event to be cancelable. You then dispatch events as follows:

DispatchEvent(new Event("myEventName"));

It is a good practice to use a public static class variable for your event name. We will discuss why that is useful later on. A dispatch would look like this:

DispatchEvent(new Event(EVENTNAME));//assume EVENTNAME is a public static string.

AddEventListener: AddEventListener is analogous to addListener in Actionscript 2, but the syntax is more usable. You no longer have to define function names that will match the broadcast signal you are listening for. It is also more granular because you define every event it will pay attention too.

A simple example will demonstrate the difference. Say we have a class in Actionscript 2 that broadcasts three messages: "onCreate", "onClick", "onDelete". So you could have code as follows:

//function inside our class in Actionscript 2
myNav.addListener(this);
myHeader.addListener(this);
//bracket to end this function
}

private function onCreate()
{ }

private function onClick()
{ }

private function onDelete()
{ }

If something is listening to that class, it will potentially react to all three of those events. The control of what it does or does not listen too, is implicit by the presence or lack of the function that matches the event name. This means that you have to reserve those function names in that object for the events.

Another potential hang up is that you could very easily find other child objects in that class that will dispatch an onCreate event. For example, if the header and nav both broadcastMessage("onCreate"), then you would run the exact same function. This means that the reusability of classes you create can be hampered by potential overlap in event names.

With Actionscript 3, adding an event listener also requires that you specify which event you are listening for, and which function to fire. So you could do the following code:

     //assume we are in a class function for clean code practices
     myNav.addEventListener("onCreate",onNavCreated);
     myNav.addEventListener("onClick",onNavClicked);
     myNav.addEventListener("onDelete",onNavDeleted);
     myHeader.addEventListener("onCreate",onHeaderCreated);
     //finish off this function
}
private function onNavCreated(e:Event):void
{ }
private function onNavClicked(e:Event):void
{ }
private function onNavDeleted(e:Event):void
{ }
private function onHeaderCreated(e:Event):void
{}

The Actionscript 3 code only listens to events you explicitly tell it to listen for. If you were to omit one of those addEventListener calls, you do not respond to the event when it is dispatched. Immediately, you should recognize that this now mitigates any problems with overlaping event names. Even if the header and the nav both dispatch the same name, it will resolve to the correct function. You can have your event functions be named anything you need. It is no longer coupled to the event name.

It is common practice to define a public static string for all event names a given class can dispatch. Then you will listen as follows:

myNav.addEventListener(myNav.NAVCREATE,onNavCreated);
myHeader.addEventListener(myHeader.HEADERCREATE,onHeaderCreated);

In that example, the actual value in those variables could be exactly the same, but it doesn't matter. Using the variables provides some clarity to the event model and also ensures that you can ensure your events are correctly matched on the dispatch and listening ends. You can take advantage of the more strict compiler for Actionscript 3.0 to ensure that your events will always match. If you type the variable wrong, it won't compile. Common practice is to have these static variables written in all caps.

RemoveEventListener: This function is used to stop listening to a specific event. It has the exact same signature as addEventListener. You must define the event, and the function when it is removed.

Extending Events

This is a substantial improvement for design patterns and practices. The new methods for handling events are now in line with methods used in other languages and other environments. The new methods also present structured interfaces that you can extend and customize to create your own events. The result is a system that is virtually unlimited in the flexibility it provides you as a developer.

For example, say you have a class that does asynchronous data calls, and provides the results when they are ready. You can extend the Event class to create your own Event that includes the added information. Doing it this way, allows you to set a clearly defined methodology that you can use throughout your system for passing that information.

Example

//custom event class
package classes.dataUtils
{
    import flash.events.Event;
   public class RemotingEvent extends Event
    {
        public var results:Array;
        public var success:Boolean;
        public function RemotingEvent(t:String,r:Array,s:Boolean)
        {
            super(t);
            results = r;
            success=e;
        }
        public override function clone():Event
        {
            return new RemotingEvent(type,serverData);
        }
    }
}

//in a different file we could have the following code to do a remoting call

public function doDataCall(sParam:String):void
       {
            var responder:Responder = new Responder(onLookUpResult,onLookUpError);
            try
            {
                netCon.connect(connection_str);
                netCon.call("Project.Class.Function",responder,sParam);
            }
            catch(e:Error)
            {
                netCon.close();
                dispatcher.dispatchEvent(new RemotingEvent(MYCALL_ERROR,null,false));
                trace("error:"+e.message);
            }
            finally
            {
                responder=null;
            }
        }
        private function onLookUpResult(re:Object):void
        {
           netCon.close();
            try
            {
/*Process your return results here. This is not part of this tutorial. Suffice it to say we create an array from the returned information in the re variable.*/
                 var rEv:RemotingEvent = new RemotingEvent(MYCALL_SUCCESS,res_array,true);
                 dispatcher.dispatchEvent(rEv);

            }
            catch (e:Error)
            {
                  dispatcher.dispatchEvent(new RemotingEvent(MYCALL_ERROR,null,false));
            }
        }
        private function onLookUpError(fe:Object):void
        {
            netCon.close();
           dispatcher.dispatchEvent(new RemotingEvent(MYCALL_ERROR,null,false));
        }

This example demonstrates how you can use a defined class to package and send information in a uniform, predictable way. It is true that Actionscript 2 allowed you to add additional parameters to your broadcastMessage call, but that means that every function signature is then coupled to the broadcast specifically. Using a custom event class is a cleaner way to extend our events.

Extending EventDispatcher

If you are not dealing with DisplayObject classes but you still need to dispatch events you can usually just make your class extend EventDispatcher. That will give you all the functionality to dispatch events from the new class. However, because Actionscript 3 doesn't allow multiple inheritance, extending EventDispatcher doesn't always work. You may need to dispatch events in a class that has to inherit from something already. In those cases you can do what the above example did. You add an EventDispatcher object to the class and then wrap it with the functions to get what you need.

/*other imports needed for remoting which is outside the scope of this tutorial*/
import flash.events.EventDispatcher;
public class MyDataTool extends SomethingElse
{

private var dispatcher:EventDispatcher;
/*Other variables and items for flash remoting that are not part of this tutorial scope*/

     public function addEventListener(e_name:String,func:Function):void
        {
            dispatcher.addEventListener(e_name,func);
        }
        public function removeEventListener(e_name:String,func:Function):void
        {
            dispatcher.removeEventListener(e_name,func);
        }
//now you have some of the code like the above example that uses dispatcher.

}

Organization

A fully event driven system is great for a lot of other reasons. It provides a way for your modules to communicate to parents or siblings while being agnostic to the details. You could for example, have a navigation object that is populated dynamically. The navigation object's class can define how it builds the information, and how the object animates when rolled over or clicked. The nice thing is that the navigation object doesn't need to have any information about what logic happens when one of its choices is clicked.

The correct way to design this type of behavior is to let the navigation class code deal with its presentation and behavior, and then dispatch a click event. By doing this, you could use the same navigation class in multiple instances.

You may have one navigation that presents different products. When the user clicks on one, the system displays dynamically populated price information for that selected object. In another case, the same exact navigation class could create an object that displays a collection of greetings to begin a letter with. Clicking a choice updates the displayed letter.

By separating the functionality at this level, we now have a reusable module that can be dropped into a wide variety of uses. All we need to do is use the events it broadcasts to then do the unique behavior required in any scenario.

Bubble Events

Bubbling events allows you to have even greater flexibility. In flash, an event will not bubble by default. When an event does not bubble, it will either be caught by a declared listener or it will fizzle with no effect. If it is set to bubble, then it will be caught by any explicit listeners, but it will also move up the display tree and be caught by anything else listening for that event name.

It is very important to note that bubbling only works if you are dispatching an event from an object that resides in the display tree. If you never add something as a child to a DisplayObject (that in turn has been properly added to its parents all the way up to the stage) then bubbling will have no effect.

So you may be asking, why would I ever want to bubble events? The reason is that you often will want something at the root level (or very near that) to respond to happenings many levels deep inside the application. Rather than having to catch an event at every level and then dispatch the event yet again, you can just let it bubble up on its own. This saves you lots of code requiring you to add listeners and declare event functions that only dispatch the same event again. For an example of this in application see the tutorial on navigation control using Actionscript 3.

Final Thoughts

The robust event model introduced in Actionscript 3 is a huge improvement over the functionality that exists in Actionscript 2. We now have an event model that is consistent with the object oriented design patterns that facilitate the design and creation of more complex and robust applications.

Flash Navigation Control AS 3.0

Danny — Fri, 11 Jul 2008 21:25:00 GMT

We have already discussed how to handle mouse-mashing clicks using Actionscript 2. The more structured object oriented nature of Actionscript 3 requires an update to this methodology, but it is still pretty simple.

The challenge with Actionscript 3 is that you want to be able to trigger a lock or unlock action at any time. You no longer can define a function at _level0, and then call it from anywhere. This change is a huge improvement from a perspective of design patterns, maintainability, and modularity of your objects. It does however mean the methods outlined in the Actionscript 2 tutorial will need to be reworked.

The Solution

In order to work this out, we will want to dispatch events up to a parent listener for our locks and our unlocks. Because these events could be dispatched from classes deep within the system, you will want a predefined constant that you can use to ensure your event type is correct.

Define a Constants Class

The first matter is quite easy to handle. I like to create a Constants class that has public static variables. Then you include that class throughout your application.

package classes

{

public class Constants
{
     public static var LOCKEVENT:String = "LockNavigation";
     public static var UNLOCKEVENT:String=”UnlockNavigation”;
     //other constants may be used depending on your application needs
}

}

The code above assumes that you have a directory called classes at the root of your project. I generally like to have all my class code contained within that directory for project-specific classes.

Creating Your Fill Layer

You will need to have a display object that is at a depth higher than all other content in your application.

The following example assumes you have a parent class that is inheriting from a DisplayObject. It assumes a class variables mainContents and myClickManager. It makes use of a class we will be describing later on called ClickManager.

public function build()

{

mainContents = new Sprite();
//code to set up main contents
this.addChild(mainContents);
/*set up our click control on top. Because we are adding this after our main contents it will be in front*/
myClickManager = new ClickManager(0);
this.addChild(myClickManager);

}

That will put a click manager DisplayObject in front of the main contents of your flash application. You will however notice that we have no way at this point to detect when to lock or unlock clicks.

Listening For Lock and Unlock

We now need to just listen in for events that are dispatched from the system itself. The following update to our parent class will get it ready to go.

public function build()

{

mainContents = new Sprite();
mainContents.addEventListener(Constants.LOCKEVENT,lockClicks);
mainContents.addEventListener(Constants.UNLOCKEVENT,unlockClicks);
//code to set up main contents
this.addChild(mainContents);
/*set up our click control on top. Because we are adding this after our main contents it will be in front*/
myClickManager = new ClickManager(0);
this.addChild(myClickManager);

}

private function lockClicks(e:Event):void

{

if(myClickManager)
{
myClickManager.lockClicks();

}

}

private function unlockClicks(e:Event):void

{

if(myClickManager)

{

myClickManager.unlockClicks();

}

}

Dispatching a Lock and Unlock Commands

Actionscript 3 has introduced a different method for handling events. It is useful to note that anything that inherits from DisplayObject (MovieClip, Sprite, etc) has DispatchEvent and AddEventListener included in its inherited functionality. Rather than broadcasting a string as was done in Actionscript 2, you dispatch a full event. Further explanation of this will be covered in a later article. Suffice it to say that we have a much more flexible means for handling events in Actionscript 3.

In order to get what we want to work, we will need to take advantage of the properties on our event that will make them bubble up until they are caught. If the bubbles property is false, then an event will either be caught by the dispatcher's immediate parent, or just fizzle out. By setting the bubble value to true, we can dispatch an event deep inside our system, and catch it at the parent level.

So assume that you have a class that is an arbitrary depth inside the solution. This class then runs a Tween when a button is clicked, and we want to prevent click events while the Tween is running. We could have code as follows inside our system:

private function btnClick(e:MouseEvent):void
{

var mover:Sprite = e.currentTarget as Sprite;
navTween = new Tween (mover,"y",Regular.easeOut,myMover.y,myMover.y+100,30,false);
navTween.addEventListener(TweenEvent.MOTION_FINISH,tweenDone);
dispatchEvent(new Event(Constants.LOCKEVENT,true,true));

}

private function tweenDone(e:TweenEvent):void
{

dispatchEvent(new Event(Constants.UNLOCKEVENT,true,true));
//first boolean sets it as a bubbling event
//second boolean means you could cancel it before it bubbles all the way up if you want to.

}

Note that in order for this code to work, the DisplayObject that dispatches the event must be added to the DisplayObject. In this example, that is implicit by the fact that the user can see a button to click on it. Also note that the code above assumes navTween is a class variable for the DisplayObject we are working with. Garbage collection can be aggressive in Actionscript 3, and a Tween that is a local variable could get cleaned up before it finishes executing. Hopefully it will save you a few headaches to be aware of that going into things.

Click Manager

One of the powers of object oriented design patterns is that you have self-contained modules. At this point, you are free to have any type of behavior you want for your ClickManager class. The ClickManager as I will be showing it takes a parameter that sets the alpha of our fill so we can test it as needed during development. You can extend or customize your ClickManager class to include different behaviors and features without worrying about how it could influence other parts of your code.

package classes
{
    import flash.display.Sprite;
    public class ClickManager extends Sprite
    {
        private var lockCount:int;
        public function ClickManager(clipAlpha:Number=0)
        {
            this.graphics.beginFill(0xFFFFFF,clipAlpha);
            this.graphics.drawRect(-10000,-10000,20000,20000);
            lockCount=0;
            this.visible=false;
        }
        public function lockClicks()
        {
             lockCount++;
            this.visible=true;
        }
        public function unLockClicks()
        {
            lockCount--;
            if(lockCount<=0)
            {
                lockCount=0;
                this.visible=false;
            }
        }
        public function overRideLockedState()
        {
            lockCount=0;
            this.visible=false;
        }
    }
}

There are a few notable differences between the AS 2, and AS 3 versions here. AS 2 required that you set a click event on a MovieClip in order for it to block clicks behind it. AS 3 however does not. We can turn the lock on or off by simply changing our visible property. I also added a public function to override the locked state.

Important Reminder

Remember that this implementation requires the developer to ensure that every call to lock the navigation has a corresponding call to unlock the system. For a full review of the ideas behind this, see the Actionscript 2 version tutorial. The overRideLockedState can be useful if you have code where you know for certain that you can safely kill the locked state. Another option you could explore quite easily is using setTimeOut functionality to ensure that it is never locked beyond a set time limit.

Final Thoughts

The simple solution of covering your clickable areas to disable them is a huge time saver that can improve the stability of your flash applications quite easily. It can be a chore to ensure you have matching locks and unlocks, but even that challenge is simpler than setting up code that disables click events for all clickable items, and then re-enables them later. Migrating the solution from the Actionscript 2 version to Actionscript 3 is a good learning exercise to get oriented to the different, more structured, way of coding.

Actionscript 3 Migration

Danny — Fri, 11 Jul 2008 20:33:00 GMT

Actionscript 3 has been out for quite a while, but for some, adoption has been slow in coming. Migrating very large projects from Actionscript 2 to 3 can be a big enough job that it may not be feasible to migrate something that works fine in Actionscript 2. Often times, new projects are under tight enough timelines that introducing unknowns into the development process can discourage starting new projects in Actionscript 3. There are however a lot of good benefits to working in Actionscript 3. This article will talk about some of the benefits and challenges to migrate from Actionscript 2 to 3.

Benefits

Despite all the potential holdups that make it hard for a business to justify transitioning to Actionscript 3, it is definitely worthwhile. The following are some of the advantages:

· Performance: The new virtual machine running in Flash player 9 or later provides significant performance increases only for Actionscript 3.

· More robust and specific classes. The DisplayObject class, with all of the children that inherit from it, provides much better functionality. The ability to use a leaner class called the Sprite is a welcome optimization.

· Organization: Actionscript 3 is fully object oriented, facilitating easier management of enterprise level applications dealing with large data sets etc.

· Staying Current: For the foreseeable future Actionscript 2 is supported by the Flash player, but it naturally makes sense to spend your resources working in the current technology.

· New feature support: For some specific needs, Actionscript 3 provides new features and functionality that is really handy. Usually these new bits of functionality are discovered as they are needed. For example, we discovered that Actionscript 3 is much friendlier for printing because of features like printAsBitmap.

Challenges

In our time working with Actionscript 3, there are some challenges and differences that will require some changes in your methodology in some cases. A few things to look out for are:

· Access to global constants and functions is different. In Actionscript 2.0, you could create variables at a _level0 level from any place in code, and you could access them from anywhere. Similarly, you could have functions that could be called from anywhere. The move to truly object oriented code is welcome, but you will definitely have to change practices that used to work fine.

· Access to objects in the display tree is also different. It used to be possible to access any movie clip through its explicit path (eg _level0.myClip.myChild). Again, the fully object oriented nature of Actionscript 3 pushes you away from this method. You will be best suited by keeping class variables that point to DisplayObjects you need.

· Loss of duplicateMovieClip. The documentation indicates that you should use your display object’s constructor to create duplicates of your content. This sounds great in basic practice, but it does fall short of the old functionality.

Organization:

For Actionscript developers who came from the more structured object oriented worlds of C++, C#, Java etc, the move to true object oriented code with Actionscript is welcome. It is possible to do object oriented code in Actionscript 2.0, but the formally structured environment in 3 prevents coders (myself included) from indulging in sloppy practices in the interest of perceived time savings.

If you are not familiar with object oriented principles, you should definitely spend time studying the concepts and doing some practice projects. Applying the same principles to Actionscript is simple once you are familiar with general principles that apply to all languages.

General Tips:

· Get used to using the Sprite rather than the MovieClip. Unless you are dealing with hand created timelines and need the functionality to move from frame to frame, the Sprite will take care of your needs.

· Extend the Sprite or MovieClip class to create classes for the different concepts you need. If you are not familiar with class inheritance and polymorphism, you should read up on it.

· Make wise use of the event dispatching functionality. Quite often, a given DisplayObject will have events that need to invoke functionality that doesn’t belong to it. For example, say you have a Sprite that has a data-driven collection of choices the user can click. A well designed class for this could provide all display and interaction functionality for those choices, but would be agnostic to the logic that happens when the choice is clicked. In that case, the event for a choice being clicked would need to dispatch an event up to the parent objects that have access to the logic involved in that choice.

· Let the new display model help you. In Actionscript 2, your movie clip is created in context of the display tree. So the instant you have created a MovieClip, anything drawn on it will be displayed. In Actionscript 3, this changes. DisplayObjects like the Sprite or MovieClip are only displayed once they are added to the display tree. This is actually very handy. You can now create your DisplayObject, and perform logic on it to determine where to add it. This proves to be very useful for determining paging when you print for example.

· Make sure to add created DisplayObjects to the display tree before doing certain tasks. Every DisplayObject has a pointer to the global Stage. If you try and access that value before you have added it to the tree you will run into null pointer exceptions. Similarly, if you set an event to bubble up, it can only bubble up if the DisplayObject that dispatches it is already in the display tree.

Loss of DuplicateMovieClip

The Actionscript documentation for Actionscript 3 says that DuplicateMovieClip has been replaced by the constructor for whatever DisplayObject you are using. This however omits one of the key uses for DuplicateMovieClip.

It is not uncommon for you to have a DisplayObject that would start with a base constructor, but then be modified dramatically based on user input. DuplicateMovieClip is perfect for copying instances of the DisplayObject that have already performed logic to get it to the state it is at. However, using the constructor for that custom DisplayObject probably doesn’t get it done. Quite often you have to create your own custom clone function that will create a new version and then run any required display logic on the copy.

Final Thoughts

Hopefully this brief discussion of Actionscript 3 is useful. It is safe to say that Actionscript 3 caters more to formal development. The fully object oriented language better facilitates the use of industry standard coding practices, and makes it much easier for developers from other languages to do maintenance and updates to a Flash application. The same design patterns enable developers to tackle much larger and more complex tasks. If you are starting new projects, it is definitely best to start in Actionscript 3. If you have functioning code in Actionscript 2, a direct upgrade may be difficult enough to wait until it is time to upgrade the existing system.

Flash: Broadcasters & Listeners AS 2.0

Deborah — Fri, 02 May 2008 20:48:00 GMT

Write-Up by Danny Staten

Introduction:

Broadcasters and Listeners are one of the most powerful tools for dealing with asynchronous events in flash. Any time you have coded an onPress or onEnterFrame function, you have been listening to a broadcast event. Their true power comes when you start using them to create custom broadcasting and listening. By the end of this article, we will be discussing advanced topics like how to implement your own broadcasting and listening.

The Basics:

So what is a broadcaster, and what is a listener? Think of the broadcaster like somebody with a radio transmitter. They can speak into a microphone, and anybody tuned into their frequency can hear what they say and react as they choose. In reality, this is a simplified analogy that doesn’t accurately describe the actual implementation used for broadcasting. It is however sufficient to describe them for our purposes. So in order for the broadcaster to work, it needs to have subscribed listeners.

You might be inclined to ask why broadcasters are so important. They are very important in flash due to the order code executes. Code written in a frame starts on that frame, but a command started on a given frame often finishes many frames later. A simple example of this is the following tween:

var myTween = new mx.transitions.Tween(clip_mc,”_alpha”,mx.transitions.easing.Regular.easeOut,0,100,12,false);
trace(“object faded in”);

At initial glance, one might think that the trace saying that the object’s fade in will show up once the tween is finished. It should be obvious to any who have programmed a tween that it doesn’t work that way. All the code written in a given frame begins execution during that frame, but this tween finishes 12 frames after the code that fired it actually executed. If you want that trace to fire when the tween is done you have to use a listener.

var myTween=new mx.transitions.Tween(clip_mc,”_alpha”,mx.transitions.easing.Regular.easeOut,0,100,12,false);
myTween.onMotionFinished=function()
{
trace(“object faded in”);
}

This example is not as clear an example of a listener because it takes advantage of the fact that the tween object will hear its own broadcast events. The following example does the same thing, but is clearer for instruction:

var myTween=new mx.transitions.Tween(clip_mc,”_alpha”,mx.transitions.easing.Regular.easeOut,0,100,12,false);
var listener_obj:Object=new Object();
myTween.addListener(listener_obj);
listener_obj.onMotionFinished=function()
{
trace(“object faded in”);
}

Here we see the broadcaster-listener behavior more clearly demonstrated. I create an object that I will then subscribe to the myTween object. That means that I can then set that object up to react to any message sent by the myTween object. In this case it reacts to when the tween broadcasts “onMotionFinished”. It is important to note that a subscriber listens to just its object’s broadcasting. For example if you have two tween objects myTween and myTween2, you can consider it as if they broadcast on separate frequencies. You can have one listener listening to multiple broadcasts simultaneously if you subscribe it to both.

Another valid item to listen to for this tween is onMotionChanged
listener_obj.onMotionChanged=function()
{
trace(“fade in progress”);
}

Not all objects broadcast messages. The tween object is implemented by Macromedia and happens to be set up to broadcast several events. The two events, onMotionFinished and onMotionChanged turn out to be the most useful.

Examples:

Here I will show some interesting concepts that can be used with broadcasters and listeners. The examples will generally increase in complexity and usefulness.

One tween for multiple objects.
It is quite common to want to do something like move a clip 200 in x, 100 in y for example. At first glance it appears that you need two tweens to do this, one for the x and one for the y. In reality, it is very easy to set up one tween that drives any number of related attributes for any number of movie clips. Consider the following example:

Var tween_obj:Object = new Object();
tween_obj.cur=0;
tween_obj.move_x=200;
tween_obj.move_y=100;
tween_obj.startX=myMovieClip_mc._x;
tween_obj.startY=myMovieClip_mc._y;
tween_obj.target_mc=myMovieClip_mc;
//tween_obj is going to be the listener I use
Var myTween = new mx.transitions.Tween(tween_obj,”cur”,mx.transitions.easing.Regular.easeOut,0,100,12,false);
myTween.addListener(tween_obj);
tween_obj.caller=myTween;
tween_obj.onMotionChanged=function()
{

/*one trick to look out for is the scope inside these functions. When inside an event function for an object the ‘this’ keyword is actually the object. In this case this refers to tween_obj. */

//note that the tween object’s cur variable is being changed by the tween

            var stepX:Number=this.cur/100 * this.move_x;
            var steyY:Number = this.cur/100* this.move_y;
            this.target_mc._x=this.startX+stepX;
            this.target_mx._y=this.startY+stepY;
}

tween_obj.onMotionFinished=function()
{
/*You should always clean your own memory up. Theoretically flash has garbage clean up, but true to the rule of thumb, garbage clean up is not to be relied on. */
delete this.caller;
delete this;
}

This particular example actually is considerably more code than just using two tweens, and it likely won’t provide any real performance benefits. However the concept allows you to do advanced tweening where your code ensures that all the needed motions are synchronized across as many objects as you can keep straight in your head.

Bending a Line:
An example of using this concept in a more powerful way is to create a tween that bends a line. Click here to download the example fla file.

This is a simple example of something you couldn’t animate programmatically without using broadcasting and listening. If you were to now do a tween that actually drives both the curveX and curveY values you could get something where the line bends and stretches in any direction.

Snapping the Line Back:
Now let’s say that you want to make it so that after the line bend is complete, it then snaps back to a straight line. The example fla file is available here. The only changes to the code are in the onMotionFinished function.

An important thing to note is that the memory clean up for these animations is deferred to the second onMotionFinished event. It is also a good idea to attach any items you will want to delete to your listener object so you can make sure that you have a pointer that is in scope when you do your memory clean up. This is a better example of how you can use one tween to drive multiple parameters.

Making the Bending and Snapping Dynamic:
So you are probably thinking, “that looks like a lot of work for something I could do with a timeline animation.” You have a point, but even with the examples you have seen so far there are powerful advantages to programmatic animation.

This is mathematically very clean and precise.
This particular animation would likely be very challenging via the timeline and would require shape tweens and or lots of key frames.
Coded animations are much easier to reuse, and modify. If you take time to code them up properly, you can modify your animation in unlimited ways in seconds.

One thing that you cannot do in pure timeline animation is make an animation that interacts with any user input. The following example will demonstrate something that you couldn’t possibly do without broadcasters and listeners. Download the source file here.

There are some nifty things to notice in this code. One is that you can overwrite your listener events at any time. Use this to turn off an object’s response to one event if you still want the object to catch other events. Also be aware of the trickiness with the this keyword. Remember that it is always in reference to the variable space for the specific object whose function is being called. Many events can pass variables if your listener provides them as parameters, but I tend to move things into my function spaces by attaching them to my listening object. That way you can have whatever data you want available in an event, and not just what a broadcaster has set up to send as a parameter.

This example is also an example of how mouse clicks can cause undesired effects if the user clicks while the snapping animation is running. You will notice that if you click, drag, let go, and then click really fast your line will be permanently bent. See my other article on disabling mouse clicks to find a pretty powerful solution to most problems of that nature. With slight modifications, that technique can prevent the glitches we can create here, but that is beyond the scope for this article.

Custom broadcasters:

Up to this point, we have really been using listeners and taking advantage of broadcasters that are already implemented. Think about the cool stuff that can be done with listeners and then think that we have only begun to harness one half of the sweetness that is broadcasters and listeners. If you really want to get so you can have fun with this idea, you will want to learn how to do your own broadcasting.

The following are a few core principles to be aware of:

· Almost anything more than a simple variable can be a listener. For example you can subscribe a movie clip to a broadcaster, but you shouldn’t subscribe a number. (I never have tried to make a number a listener, so I can’t say what the results will be, but it will likely destroy the number’s data or fail to respond to events or both.)

· You can subscribe any number of items to a broadcaster.

· A listener can subscribe to any number of broadcasters simultaneously. This can be nice, but you have to be careful.

· Make sure to use broadcasting_obj.removeListener(listener_obj), where broadcasting is the name of whatever object you have broadcasting, and listener_obj is your own listener. Do this when you no longer need a listener to respond to broadcast events. Forgetting to remove a listener can cause challenging bugs when you have an old object’s listener events firing long after you are expecting them to.

· Not all objects can be set up as broadcasters, and simple variables should never be broadcasters. (I don’t think it is possible, but I also haven’t ever tried.) When you make something a broadcaster you are adding functions to the object. I have yet to find any native objects that cannot be broadcasters (I have been able to make a movie clip a broadcaster or even _level0). However, instances of 3^rd party classes may not allow you to make them broadcasters. The class describing the object either has to be dynamic (which allows its objects to have new variables and functions attached to it), or it has to already have the correct functions with the correct signatures set up in its code.

Why Use Broadcasters?

Okay so why would you want to do your own broadcasting? I have found them very valuable in the following applications.

Site animation control: My favorite application deals with large dynamic web sites or applications. In this case, the time it takes to remove a dynamically generated page can vary greatly depending on the amount of content or the style of animation or both. If you have your code to remove a section broadcast an event such as “onRemoveFinished”, then you can easily wait until any section has removed before drawing the next section to be brought in.
Advanced animation needs: Another really interesting application can be extended from the bending line examples. To see the bending line extended via custom broadcasting, check out the Martin Doors flash application, and pay attention to the light grey boxes. In this case, the code in question broadcasts when the bending line’s start and end points have changed. That allows the lines on the side of the boxes to listen to that and redraw to stay connected. The result is an animation that has all the benefits of being dynamic, extremely flexible and configurable, while still being interesting and relatively complex.
Custom class development: If you get involved in creating your own custom actionscript classes, you will find broadcasters are indispensable. Imagine how useless the Tween would be without onMotionFinished or onMotionChanged events. Sure it could probably do its basic animations, but there would be no means for code that uses a Tween object to know what is going on. Broadcasters allow custom classes to send messages to your main code. There are very ugly and unhappy ways to try and do the same thing with your custom classes, but for practical intents and purposes, broadcasting makes things possible that cannot (or at least should not) be done in other ways.

How To Use Broadcasters.
To make something a broadcaster you simply make the following call:

AsBroadcaster.initialize(myObj);

Where myObj is whatever object you wish to make a broadcaster. Keep in mind that the broadcaster has to be visible to all listeners in order for them to subscribe to it. For management of events that happens across multiple sections of a web site, you will want something that is going to be around in all areas that will need to listen for your events.

Say for example you have movie clips as follows:

Contents_mc.sectionA_mc.lots_of_child_clips
Contents_mc.sectionB_mc.lots_of_child_clips
Contents_mc.sectionC_mc.lots_of_child_clips

Suppose that you have animations that remove section A, and broadcast when that is done so code can draw either section B or C. It would make sense in this case to make Contents_mc your broadcaster.

Once you have made something a broadcaster, it is very easy to use.

AsBroadcaster.initialize(broadcaster_obj);
Var listener_obj:Object=new Object();
broadcaster_obj.addListener(listener_obj);

listener_obj.onHello=function()
{
trace(“hello event caught”);
}
broadcaster_obj.broadcastMessage(“onHello”);

The example code above is so trivial it is not inherently useful, but it demonstrates how to create your own custom broadcasting.

Making Custom classes broadcasters
For situations where you want to make your own custom class a broadcaster, there is one more thing to be aware of. The class must either be declared as follows:

dynamic class className{…….}

An object created from a dynamic class can have variables and values attached to it at run time. This can be very handy, but is not always the best idea. The other way to do it is to add the following member variables to your class:

public var addListener:Function;
public var removeListener:Function;
public var broadcastMessage:Function;

Final Thoughts

I hope this article proves useful for you. It brings me to tears to think about some of the truly painful and ugly ways I found to survive without taking full advantage of broadcasting and listening. If you are willing to spend the time to figure them out, and then start thinking about how you can use the tools they open up to you, you will be amazed at the doors they open up to your flash development.

Flash: Navigation Control AS 2.0

Deborah — Fri, 02 May 2008 18:08:00 GMT

Write-Up by Danny Staten

Introduction

Mouse-mashing users can easily break many flash pages with their click-happy ways. The ability to properly react to inputs during animations has long been a frustrating problem for flash development

The standard solution is to explicitly disable all clickable movie clips whose click events can mess up the animation, and then enable them when the animation finishes. This solution works, but has many limitations including:

For large lists of clips to disable (say a very large navigation), it has the potential to influence performance.
For dynamically generated content, it can be very difficult to determine all the clickable items to disable/enable.
For dynamically generated content, it can be very difficult to manage the state of all the clickable items for all cases.

An unobvious but very simply and elegant solution does exist. It can be used to disable all mouse clicks by region or for the entire flash stage. Generally I use it to disable clicks for the entire stage, but it can be done in other ways to disable specific regions.

The Basic Solution

The Solution can be thought of like a glass panel that you put on top of the page. It takes advantage of the fact that a movie clip with a fill drawn in clickable even if it has an alpha value of 1. I will call that clip the glass panel.

The basic solution utilizes two globally accessible functions.

disableNavigation():

This function creates a movie clip to act as the glass panel. A simple implementation is to create it at the root with a hard coded depth of 1000. Obviously, that detail of the implementation is entirely flexible. I generally try to organize my clip creations so that they are organized inside a small group of clips. If you have 1000 clips right in your root level you are probably not organizing your clips effectively.

enableNavigation():

This function basically just calls removeMovieClip on the glass panel.

Basic Solution's Code

function disableNavigation()
{
            createEmptyMovieClip(“glassPanel_mc”,1000);
            utilities.draw_box(glassPanel_mc,Number(0xFF0000),0,0,0,Stage.width,Stage.height);
            /*utilities.draw_box takes the movie clip to draw to, the color, alpha, cornerX, cornerY, width, and height as parameters. For the disable clip functionality you can either have the fill’s alpha at zero, or fill it and then set the clip’s alpha to zero. Either one works. I like to have it actually fill red for debugging purposes. You can change the alpha to 25% and get a visual identifier of when your navigation is disabled for testing. */

            glassPanel_mc.onPress=function()
            {}
            /*the empty click function is important. If you don’t give this a press event function then it won’t intercept the click event and other items that are lower in depth will still get clicked on.*/
            glassPanel_mc.useHandCursor=false;
            /*This last part is purely an aesthetic effect, but it makes the final touch to make it cool. This way the user is actually triggering a click event when they do click, but they don’t know they are because the mouse cursor doesn’t change at all.*/
}

function enableNavigation()
{
removeMovieClip(glassPanel_mc);
}

This solution is very powerful, and can be modified to disable specific regions of your stage very easily. Any time you need to disable clicks you can call disableNavigation and the mouse press events will not cause you any grief. To turn them off simply call enableNavigation.

The More Robust Solution

The basic solution is nice and all, but it doesn’t quite reach the power that I was looking for. I basically wanted to simulate event driven programming where multiple events can all have input to when to disable and enable your navigation.

Say for example, that I have a data call via flash remoting, and an animation running. I want to wait until both of those have finished. The trick is that the data call is often faster than the animation, but there are occasions where the remoting call can be slower than the animation. We need a way for the glass panel to only remove itself when both events are done. I wanted a means that could be extended to n asynchronous items as a general case.

Now suppose that every time you call disableNavigation, you are also putting a marker on the glass panel. Every time you call enableNavigation you then remove one marker from the panel. If the panel has no markers on it then enableNavigation removes the panel. You can have every event that needs to ensure the user clicking is disabled to function properly put a marker on the panel. Then when the event finishes it removes a marker. As long as every event has one disableNavigation and one enableNavigation call, then a simple counter will suffice.

We can solve this problem quite elegantly by adding a few lines of code to our functions. Basically you add a counter to the glass panel when it is created. Every call to disableNavigation will increment this counter, and every call to enableNavigation will decrement it. If the counter gets to zero in the enableNavigation call then it is removed and navigation is active again.

Robust Solution’s Code

Important Note

This solution does have some challenges too it, but its simplicity in implementation means that it is usually what I go with rather than implementing more complicated alternatives. The challenge is that it is very easy to accidentally lock your navigation. It is up to you as the developer to ensure that there is a corresponding enable for every disable. If you have too many enable calls, then your navigation can unlock too early, and if you have too few enable calls then your navigation will be permanently locked. Depending on the complexity of the logic in your code, this may not be trivial. In the first iteration of this solution, you can call disableNavigation multiple times and one call to enableNavigation will unlock the interface. That is nice for a lot of things but doesn’t solve more complex management issues. This solution allows for more complex management, but it also makes it very easy to accidentally lock your navigation.

Even more complicated versions are always a possibility, but none that I have found have had enough benefits to justify the effort.

Of course, if you want to take the time to identify segments of code where you are absolutely certain the navigation should be enabled, you can enforce that as well. Simply wrap removeMovieClip(glassPanel_mc) in a function such as masterUnlockNavigation() to abstract the details of the implementation from the main code of the program. I have never had cause to do that. Generally speaking, if you manage your glass panel properly you shouldn’t need to force it to enable.

Final Thoughts

I hope you have found this bit of information useful. For the longest time, I was busting my tail trying to manage individual clips enabled states to control user input. One day as I was trying to solve why something was clickable when I couldn’t see it, the synapses in the brain started firing and my interface management frustrations were a thing of the past. So if you have already got a better solution, I would love to hear it. Chances are that if you are reading this article it is because you have been frustrated by the same issue. So I hope this prevents a few headaches for you.