Sep 20, 2011
Posted on Sep 20, 2011 in Hints and Tips | 10 comments
In this Quick Tip, we’ll take on run-time Error 2044, the un-handled IO error. It’s actually very simple, but it plagues even experienced developers, so we’ll go in-depth and turn everyone here into IO error ninjas.
Step 1: Setting up the Problem
Let’s start by setting up some code in a Flash file that produces error 2044. Create a new AS3 Flash file, and enter this code into the Script panel:
var loader:Loader = new Loader();
loader.load(new URLRequest("some-non-existant.url"));
Go ahead and run the SWF, and you should see this error:
Error #2044: Unhandled IOErrorEvent:. text=Error #2035: URL Not Found.
You will see the same error, with a slight variation if we just change Loader to URLLoader, as in below:
var loader:URLLoader = new URLLoader();
loader.load(new URLRequest("some-non-existant.url"));
You should see something like this, only with the file path reflecting your environment:
Error #2044: Unhandled ioError:. text=Error #2032: Stream Error. URL: file:////Volumes/Mac%20Pro/Users/dru/Library/Caches/TemporaryItems/non-existant.url
at Untitled_fla::MainTimeline/frame1()
Step 2: The Accused
As you might be able to surmise from the fact that Error 2044 crops up with Loader and URLLoader in use, this error has something to do with the loading of external files.
In fact, the error has something to do with the failure to load an external file. As the fake URL in my code snippets would suggest, the file we are trying to load is having a problem of some sort. Most likely it’s a case of the file being unreachable; this might simply be a mis-spelled URL, or a URL being created dynamically resulting in a bad location, or because the server or network is down at the moment.
However, Error 2044 is not accusing you loading a bad file. That’s going to happen. We can’t control the network, so a load failure is bound to happen at some point. Error 2044 is accusing you of not being prepared for when that happens.
Step 3: Good Boy Scouts
Both Loader and URLLoader are event dispatchers, as you should know from working with them. You need to utilize the Event.COMPLETE event in order to know when a load is ready for you to work with it. If you’re reading this, though, you might not realize that these loading classes also dispatch other events, notably the IOErrorEvent.IO_ERROR event.
When a Loader or URLLoader encounters a failure, such as described in the previous step, it will dispatch an IOErrorEvent.IO_ERROR event. This is a specialized event for cases such as this. It carries a text property that describes the nature of the error, as seen in the errors we created in the first step; both code snippets produced Error 2044, but the text of each was different (even though it was semantically the same).
Unlike most events, though, when IOErrorEvents are dispatched, the dispatcher checks for the existence of at least one event listener. If it doesn’t find any, it throws the un-handled IO error.
So the solution is simple: simply add a listener for the IOErrorEvent.IO_ERROR event to your loader(s). Even if the listener doesn’t do anything, it will at least suppress the Error 2044, by virtue of merely existing.
var loader:URLLoader = new URLLoader;
loader.load(new URLRequest("some-non-existant.url"));
loader.addEventListener(IOErrorEvent.IO_ERROR, onError);
function onError(e:IOErrorEvent):void {
// Do nothing
}
Remember that you add events to the contentLoaderInfo property of Loader objects, not to the Loader directly:
var loader:Loader = new Loader();
loader.load(new URLRequest("some-non-existant.url"));
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, onError);
function onError(e:IOErrorEvent):void {
// Do nothing
}
However, you should be better prepared than this, like a boy scout; you would ideally determine what an appropriate action to take would be, then start that action in the event handler function. You might decide to load an “image not found” image or a default XML file instead. You might present an alert to the user notifying them that a required resource could not be loaded, and should try again later. Perhaps you also disable parts of your SWF because the required data couldn’t be loaded. You might even fire off a message to a server-side log with details, so that you can look into the situation.
That Is All
As I mentioned, this one is pretty easy, really. It’s just a matter of getting in the habit of adding that event handler in the first place, so that you never see Error 2044 again. It won’t prevent resource loading from failing, but it can let you degrade gracefully and recover from the failure as best as you are able.
Thanks for reading. I’ll see you again shortly in another Debug Quick Tip.
View full post on Activetuts+
Sep 5, 2011
Posted on Sep 5, 2011 in Hints and Tips | 10 comments
It’s time for another debugging Quick Tip. We’ll continue our focus on specific (and common) errors that tend to stymie less-experienced ActionScripters. In this case, we’ll cover Error #1063, the argument count mismatch error.
Step 1: Being Bad
First, let’s create a situation where the error occurs. Open up a new Flash document (assuming you’re following along with Flash Pro CS3+, otherwise this sample is easily adapted to a Flex project). Open the Script Editor and enter the following code:
import flash.events.MouseEvent;
function onClick():void {
trace("click.");
}
stage.addEventListener(MouseEvent.CLICK, onClick);
You can probably spot the problem already; if you’ve spent any amount of time writing ActionScript 3 you’ll have found yourself writing event handlers. If not, don’t feel bad — we’ll go over it all in due course.
If you run the Flash file as is, and then click on the stage, you’ll produce the following run-time error message:
ArgumentError: Error #1063: Argument count mismatch on Untitled_fla::MainTimeline/onClick(). Expected 0, got 1.
And we never get to the trace statement that should have run after clicking.
Step 2: Breaking It Down
So what’s going on? In this case, Adobe’s verbiage for the error is actually not so bad, and if you’ve gotten used to parsing a run-time error message, its meaning might be pretty clear. But not everyone is as smart as you, so here’s the breakdown for everyone else.
ArgumentError — This is someone inconsequential information, but it shows the specific Error class that was thrown. We’ve got something that’s not as general as a simple Error, and we’ve entered a specific categorization of error associated with arguments (to functions and methods).
Error #1063 — Here we’re just giving the formal error number, like all good run-time errors. You can use this code to more easily locate it in Adobe’s run-time error documentation.
Argument count mismatch… — In more proletarian terms, there were the wrong number of arguments sent to a function. Which function? It’s…
…on Untitled_fla::MainTimeline/onClick(). — This simply identifies the function that received the wrong number of arguments.
Expected 0, got 1. — We get a bit of extra information in this error description. This details the count mismatch. This phrase will change according to the nature of the specific error, but in our case it’s saying that the function was written without any arguments in the signature, but a single argument got sent to it anyway.
Flash likes its ducks in a row. So, it notices this discrepancy and decides to throw a tantrum error, because it would rather you (the developer) figured out what went wrong than that you simply ignored the problem. This is good, because if the count mismatch went the other way (expected 1, got 0), then we’d be stuck without an argument for a required parameter, and the function would do Dog knows what.
Step 3: The Root of the Problem
The nature of the error should be clear at this point, but you may still be wondering why it occurred at all. Where did that superfluous argument come from?
The argument isn’t exactly superfluous. It’s expected, actually, since we’ve hooked up our function to be an event listener. The event system in Flash has the notion of an event object that encapsulates aspects of the event that occurred. This object gets passed to the listener function as the sole argument. So, we expected 0 because we wrote our function without any parameters, but we got 1 because the event dispatcher sent along an event object.
Now you may be wondering why the compiler didn’t catch this error. It’s true: if you wrote this:
function sayClick():void {
trace("click.");
}
sayClick(42);
Then the SWF won’t even compile, because you’ll get this error:
1137: Incorrect number of arguments. Expected no more than 0.
The difference is that in the latter example, we have actual code that calls the function with the wrong number of arguments. That is, we wrote the line down that calls the function incorrectly. The compiler can look at the line that defines the function, and the line that calls the function, and compare them for discrepancies, and sound the alarm when they occur.
However, in the original example, there is no line of code written down that literally calls the function by name. Instead, the function is called by reference. When we add the event listener, we pass in the function, and at that point it’s a variable, not a function call. This reference gets stored by the event dispatcher, and then executed dynamically when the event occurs (that’s a real high-level overview of how the event system works, but we don’t have time to go deeper). So, the line of code that ultimately calls the error-causing function is a rather generic line of code that uses indirection to get the job done, and therefore something much harder for the compiler to catch.
(In my opinion, Adobe could at least register the addEventListener line at compile time, and go looking for the function reference by name. If it finds a match, it could check the function signature for a proper event argument, and produce errors accordingly. It still couldn’t be done in a foolproof way, but it might go a long way to catching these errors before actually running the SWF.
The main point, though, is that this run-time error has a compile-time counterpart, but that the run-time error occurs when the function is called by reference and not directly by name.
Step 4: Fixing the Hole
The rain is getting in when we call the function by reference, and have a discrepancy in the number of arguments. We generally have two options: we can modify the call, or modify the function’s arguments. In this particular example, we can’t modify the call, as that happens inside EventDispatcher, code to which we don’t have access. That leaves us with modifying the arguments.
This, again, has two options. First, we can simply add the argument. This lines up the number of arguments and from here on out, everything will be copacetic. We don’t need to use the argument, we just need to have the function “catch” it when it’s called.
function onClick(e:MouseEvent):void {
The second option is to, again, add the argument (no way around that, I’m afraid). However, if you originally wrote the function as a regular function and not an event listener, and are calling it from elsewhere in your code without arguments, you may appreciate this variation. Make the argument optional, and default it to null:
function onClick(e:MouseEvent=null):void {
This will work well with the event system: it gets sent an event object and can catch it. It also works well with your existing code; if no argument is sent, the parameter default is used and the function proceeds.
Step 5: Callbacks
Note that this error is not limited to event listeners, although that’s probably the most common context where you’ll experience it. Ultimately it’s the using of functions stored in variables, as opposed to called by name, that leads to the error. This is how the event system works. We can rework the original example to produce more or less the same error, only without the click:
function sayMyName(name:String):void {
trace("Hello, " + name);
}
var funcRef:Function = sayMyName;
funcRef();
Again, we get past the compiler error because we have a layer of indirection between the function definition and the function call. Thus, we get the run-time error (expected 1, got 0).
It’s not always this cut and dry, though. If you utilize callbacks in your code, you might fall prey to error 1063. Callbacks are sort of like event listeners, only there is no formal, built-in mechanism for implementing them. They’re basically just functions you pass around by reference, which are stored (either temporarily or long-term) by some other process, which then calls the callback function at the appropriate time.
Tweening engines typically implement these. Some go for a more formal event-driven system, but TweenLite, for example, utilizes callbacks for receiving notifications about the tween progress. This line:
TweenLite.to(someClip, 1, {onComplete:tweenFinished, onCompleteParams:[42, "answer"]});
…would call a function named tweenFinished at the end of the tween, passing in two parameters to the function. This technique is ultimately more flexible then events, as you are not limited to just the single event object as a parameter. But it does yield itself to similar vulnerabilities to error 1063 due to the nature of passing functions around by reference.
That Is All
That wraps up another Debugging Quick Tip. Thanks for reading, and I hope you learned something along the way!
View full post on Activetuts+
Aug 20, 2011
Posted on Aug 20, 2011 in Hints and Tips | 10 comments
In this Quick Tip you’ll learn a technique of conditional enemy movement, based on a classic enemy from an awesome game. Face the ghost and he freezes; look away and he comes for you.
Final Result Preview
Let’s take a look at the final result we will be working towards:
Use the left and right arrow keys to move. Walking movement has been simplified for the sake of this Quick Tip.
Step 1: Brief Overview
A player and an enemy will be placed on screen, the player will be controlled using the left and right arrow keys and the enemy will react to the player’s position and orientation.
Step 2: Set Up Your Flash File
Launch Flash and create a new Flash Document, set the stage size to 320x200px and the frame rate to 24fps.
Step 3: Interface
This is the interface we’ll be using, simple shapes and colors to recreate this behavior.
Convert the characters to Movie Clips and name them ghost and player.
Step 4: ActionScript
Create a new ActionScript Class (Cmd+N), save the file as Main.as and write the following lines, please read the comments in the code to fully understang the class behavior.
package
{
import flash.display.Sprite;
import flash.events.KeyboardEvent;
import flash.events.Event;
public final class Main extends Sprite
{
public final function Main():void
{
addListeners();
}
private final function addListeners():void
{
stage.addEventListener(KeyboardEvent.KEY_DOWN, movePlayer);
stage.addEventListener(Event.ENTER_FRAME, follow);
}
private final function movePlayer(e:KeyboardEvent):void
{
if(e.keyCode == 37) //move left if left arrow key is pressed
{
player.x -= 4;
player.rotationY = 180; //rotate to match direction
}
else if(e.keyCode == 39) //move right if right arrow key is pressed
{
player.x += 4;
player.rotationY = 0; //rotate to match direction
}
}
private final function follow(e:Event):void
{
/* Right side */
if(player.rotationY == 0 && player.x > ghost.x)
{
ghost.x += 0.4;
ghost.y += 0.4;
ghost.alpha = 1;
ghost.rotationY = 0;
}
else if(player.rotationY == 180 && player.x > ghost.x) //if the player looks at the ghost
{
ghost.alpha = 0.5;
}
/* Left side */
if(player.rotationY == 180 && player.x < ghost.x)
{
ghost.x -= 0.4;
ghost.y += 0.4;
ghost.alpha = 1;
ghost.rotationY = 180;
}
else if(player.rotationY == 0 && player.x < ghost.x) //if the player looks at the ghost
{
ghost.alpha = 0.5;
}
/* Stop Y if ghost is near floor */
if(ghost.y >= 165)
{
ghost.y = 165;
}
}
}
}
Step 5: Document Class
Add the class name to the Class field in the Publish section of the Properties panel to associate the FLA with the Main document class.
Conclusion
You’ve learned a simple and useful technique of enemy movement, try it in your own games!
I hope you liked this tutorial, thank you for reading!
View full post on Activetuts+
Aug 18, 2011
Posted on Aug 18, 2011 in Hints and Tips | 10 comments
One of the more common questions I see on forums and get from colleagues is how to debug Error 1009, also known as the “Null Object Reference Error.” Or, as I call it, the “Annoying Mosquito Error From Hell.” It crops up a lot, and unfortunately the error itself does not contain much information about the source of the error. In this quick tip, we’ll take a look at some steps you can take to track down this mosquito and squash it good.
Introduction
This piece is the first followup to the more general “Fixing Bugs in AS3” tutorial. If you wish to better understand some of the techniques in this tip, you may wish to read that in full first.
Step 1: Understand the Error
It’s too bad that Adobe doesn’t (or can’t) provide more information about the root of this error. First of all, it’s rather obtusely worded (much like all of their errors, but this more so than most):
TypeError: Error #1009: Cannot access a property or method of a null object reference
Let’s try to put this in everyday terms. Error 1009 means that you’ve tried to do something with a variable that you assume has a value, but really does not. Flash doesn’t like that. You wouldn’t like it either; imagine you had a glass that you assumed was full of the tasty beverage of your choice, but really was empty. You grab the glass, expecting a refreshing swig, but you feel the disappointing weight of an empty glass instead. That’s your own personal Error 1009.
In ActionScript, if you do this:
var s:String;
trace(s.toUpperCase());
Flash will bum hard (a technical term for “produce an error”) when you run the code. The variable s may have been declared, but its value is null (we never set the value, just declared the variable), so calling the toUpperCase method on it is troublesome.
To be clear, because s is declared as a String, the compiler takes no issue with the code: there is a variable called s, it’s a String, and toUpperCase is a valid method to call on Strings. The error we get is a run-time error, which means we only get it when we run the SWF. Only when the logic is performed do we now get to see how this turns out.
Step 2: Permit Debugging
As with any run-time error, sometimes it’s pretty easy to tell what’s going on without any extra information. But other times it’s helpful to narrow this down further. At this point, try turning on “Permit Debugging.” When this is enabled, you get errors that also give you line numbers. Alternatively, you may be able to “Debug Movie” by pressing Command-Shift-Return / Control-Shift-Enter.
To do so, see the general debugging tips article, “Fixing Bugs in AS3”
Sometimes this is enough. Knowing the specific line might be all the information you needed. If not, we’ll dig a little deeper in the next step.
Our dear editor, Michael James Williams, encapsulated the point of this step in a limerick, which I’m happy to present to you now with his kind permission:
AS3 error one-oh-oh-nine
Is never a very good sign.
No need for concern,
Hit Ctrl-Shift-Return
And it’ll pinpoint the cause (well, the line).
Step 3: Start Tracing
If you’ve located the offending line but are still unsure what’s going on, pick apart the line. Take every variable in that line and trace them out prior to the error.
Because the error comes when accessing a property or calling a method on a null variable, to cover your bases you should trace any variables and properties that are immediately followed by a dot. For example, take this line of code:
myArray.push(someSprite.stage.align.toLowerCase());
Admittedly, that’s a rather contrived piece of code that I can’t imagine a practical use for, but you should identify four total possible null values that are being accessed with the dot:
myArray: we are calling the push method on this variablesomeSprite: we are accessing the stage propertystage: we are accessing the align propertyalign: we are calling the toLowerCase method
So your debugging code might look like this:
trace("myArray: ", myArray);
trace("someSprite: ", someSprite);
trace("someSprite.stage: ", someSprite.stage);
trace("someSprite.stage.align: ", someSprite.stage.align);
Order is important; if someSprite is the null object, but you test for someSprite.stage.align before testing for someSprite, you end up with less definitive results.
Now, common sense also plays into this. In my example, if stage exists, then align will most assuredly have a value; the Stage always has an align setting, even if it’s the default value.
Typically, you’ll see something like the following:
myArray: [...stuff in the array...]
someSprite: [object Sprite]
someSprite.stage: null
Error #1009: ...
Which should clue you in that the stage property is null, and now you can go about fixing it.
Step 4: Finding a Solution
The easiest solution is to wrap up the offending statement in an “if” block, and only run the block if the variable in question is not null. So, assuming that in our previous example, it was in fact stage that was null, we could do something like this:
if (someSprite.stage) {
myArray.push(someSprite.stage.align.toLowerCase());
}
This test — if (someSprite.stage) — will return true if there is a value (regardless of the value), and false if it’s null. In general this notation works; you can always use if (someSprite.stage != null) if you prefer. Numbers present a slightly different situation, though. If the Number has a value of 0, then technically it has a value, but testing if (someNumberThatEqualsZero) will evaluate to false. For Numbers you can use the isNaN() function to determine if a valid numeric value is stored in a given variable.
At any rate, this technique is a simple way to sidestep the error. If the variable we want to perform an operation on is not set, then don’t do the operation. If there is no tasty beverage in our glass, don’t pick up the glass. Simple enough.
But that approach is only feasible if the logic is optional. If the logic is required, then perhaps you can provide a default value to the questionable variable before the error-ing operation. For example, if myArray has the potential to be null, but it’s imperative that it’s not, we can do this:
if (!myArray) {
myArray = [];
}
myArray.push(someSprite.stage.align.toLowerCase());
This will first check to see if the array is null. If it is, initialize it to an empty array (an empty array is a valid value. It may be empty, but it’s an array, and not null) before running the contrived line of code. If it’s not null, skip straight to the contrived line of code. In real-life terms, if our glass is empty, then fill it with a tasty beverage before picking it up.
In addition, if myArray is an instance property of the class in which this line of code is running, you can pretty safely ensure a valid value by initializing your properties when the object initializes.
What if the logic is required, but the variable in question is not so readily under our control? For example, what if our contrived line of code is required, but the questionable variable is someSprite.stage? We can’t just set the stage property; that’s controlled internally to DisplayObject and is read-only to us mere mortals. Then you may need to get crafty, and read the next step.
Step 5: Dealing with a null stage
There are probably an infinite number of scenarios where a given variable or property could be null. Obviously, I can’t cover them all in a Quick Tip. There is one specific situation, however, that crops up again and again.
Let’s say you write some code that looks like this:
public class QuickSprite extends Sprite {
public function QuickSprite() {
stage.addEventListener(MouseEvent.MOUSE_MOVE, onMove);
}
private function onMove(e:MouseEvent):void {
var color:ColorTransform = new ColorTransform();
color.color = stage.mouseX / stage.stageWidth * 0xFFFFFF;
this.transform.colorTransform = color;
}
}
Another contrived bit of code (which might induce seizures — consider yourself warned), but basically the idea is that you have a Sprite subclass and you set this as the class for a clip on the stage, using the Flash IDE.
However, you decide you want to work with these QuickSprites programmatically. So you try this:
var qs:QuickSprite = new QuickSprite();
addChild(qs);
And you get the accursed Error 1009. Why? Because in the QuickSprite constructor, you access the stage property (inherited from DisplayObject). When the object is created entirely with code, it is not on the stage at the point that that line of code runs, meaning stage is null and you get the error. The QuickSprite gets added the very next line, but it’s not soon enough. If the instance is created by dragging a symbol out of the library and onto the stage, then there’s a little bit of magic at work behind the scenes that ensure that the instance is on the stage (that is, the stage property is set) during the constructor.
So here’s what you do: you test for the existence of a value for stage. Depending on the result, you can either run the set up code right away, or set up a different event listener for when the QuickSprite does get added to the stage. Something like this:
public function QuickSprite() {
if (stage) {
init();
} else {
this.addEventListener(Event.ADDED_TO_STAGE, init);
}
}
private function init(e:Event=null) {
this.removeEventListener(Event.ADDED_TO_STAGE, init);
stage.addEventListener(MouseEvent.MOUSE_MOVE, onMove);
}
If we move the stage line to a different function, and only call that function when we have a stage, then we’re set. If stage exists from the start, go ahead and run init() right away. If not, we’ll use init() as an event listener function for ADDED_TO_STAGE, at which point we will have a stage value and can run the code. Now we can use the class for either connecting to IDE Sprite or completely programmatically.
This works well in document classes, too. When you run a SWF by itself, the document class has immediate access to stage. If you load that SWF into another SWF, though, the code in the document class’s initialization stack gets executed before the loaded SWF is added to the display. A similar stage-checking trick will allow you to work with the SWF as both a standalone piece and as a SWF loaded into a containing SWF.
That Is All
Thanks for reading this Quick Tip! I hope you are enlightened a bit about how Error 1009 occurs, and how you can debug it. Stay tuned for more Quick Tips on other common errors.
View full post on Activetuts+
Aug 13, 2011
Posted on Aug 13, 2011 in Hints and Tips | 10 comments
Moving items to top and bottom of the display list can be very useful when developing games and applications. Learn to easily manage depth using this QuickTip.
Final Result Preview
Let’s take a look at the final result we will be working towards:
Click an icon to select it and bring it to the top of the display list, then use the two buttons to move it lower in the hierarchy.
Step 1: Brief Overview
Using ActionScript 3 we’ll learn how to manage top, bottom and intermediate levels of depth.
Step 2: Set Up Your Flash File
Launch Flash and create a new Flash Document, set the stage size to 320x200px and the frame rate to 24fps.
Step 3: Interface
This is the interface we’ll be using, a series of buttons in stage that will activate the depth change.
Convert the characters to Button and name the Tuts+ logos like this: nt, at, pt. For the other buttons the instance names are bottomB and oneB.
Step 4: ActionScript
Create a new ActionScript Class (Cmd+N), save the file as Main.as and write the following lines, please read the comments in the code to fully understand the class behavior.
package
{
import flash.display.Sprite;
import flash.events.MouseEvent;
import flash.filters.GlowFilter;
public final class Main extends Sprite
{
private var lastItem:Sprite; //stores the last clicked sprite
private var glow:GlowFilter = new GlowFilter(0xFF9900);// a glow filter to highlight the last item
public final function Main():void
{
lastItem = nt; //the top item at start
addListeners();
}
private final function addListeners():void
{
at.addEventListener(MouseEvent.MOUSE_DOWN, up);
pt.addEventListener(MouseEvent.MOUSE_DOWN, up);
nt.addEventListener(MouseEvent.MOUSE_DOWN, up);
oneB.addEventListener(MouseEvent.MOUSE_UP, downOne);
bottomB.addEventListener(MouseEvent.MOUSE_UP, bottom);
}
private final function up(e:MouseEvent):void
{
lastItem.filters = []; //remove last filter if any
lastItem = e.target as Sprite; //stopre last clicked item
lastItem.filters = [glow]; //apply filter
setChildIndex(lastItem, numChildren - 1);//get next highest depth
}
private final function downOne(e:MouseEvent):void
{
if(getChildIndex(lastItem) != 0)//prevent out of bounds
{
setChildIndex(lastItem, getChildIndex(lastItem) - 1);//down one level
}
}
private final function bottom(e:MouseEvent):void
{
setChildIndex(lastItem, 0);//bottom
}
}
}
Step 5: Document Class
Add the class name to the Class field in the Publish section of the Properties panel to associate the FLA with the Main document class.
Conclusion
Use what you learned in this QuickTip in your games and applications!
I hope you liked this Quick Tip, thank you for reading!
View full post on Activetuts+
