Escape Theory Gaming For Life… views are mine, and not affiliated with The White Agency or Nomad

9Feb/100

Finding the base URL of your Flash

One of the most useful 'basic' tools of a Flash developer is to be able to find the URL of your Flash application, and it is very simple:

//in timeline
trace(loaderInfo.url);
//this returns the path of the Flash application
stop();

The reason it is useful is because you can make your application behave differently depending on which environment it is in.

Your application may be expecting a flashvar which is only available if the Flash was embedded in an HTML. In order to test your functionality within the Flash IDE instead of creating two separate projects, you create some logic based on the URL of the movie:

//in timeline
import flash.display.LoaderInfo;
var myVar:String;
<pre>var paramObj:Object;</pre>
if(loaderInfo.url.indexOf('file://')==0){
//if the URL begins with 'file://' it means we're working locally
//locally, flashvar is not going to be available
//we'll give it a default value
myVar = 'foo';
}else{
//we assume that not working locally means we're working live
//get flashvar from HTML
paramObj = LoaderInfo(root.loaderInfo).parameters;

//set myVar to equal myLiveVar from the flashvar
myVar = paramObj.myLiveVar;
}

stop();
6Jan/100

Class Constructor Parameters

When instantiating a class, we may supply some default values to its variables – these are known as parameters. For example:

class Castle{
    var numOfTowers:Number;
    function Castle(towers:Number = 4){
        numOfTowers = towers;
    }
}

The above supplies any new instances of Castle with a default number of four towers.

When instantiating a new Castle, we can alternatively supply arguments to the class in place of the default values. The code below creates a castle with the number of towers set to five:

var myCastle = new Castle(5);

If we do not supply parameters with default values, they will become compulsory arguments; forgetting to supply the argument will throw an error!

22Dec/090

Packages and Access Modifiers

When creating a program with several classes, we will potentially encounter conflicts between our classes and the adobe classes (and even between our own classes!). If we choose to implement frameworks and other prepared classes, the risk will only increase.

The simple solution is to simply rename your classes, but this forces you to create an elaborate naming system, resulting in unintuitive class names and confusion.

We can avoid these conflicts by smart usage of Packages.

Package definitions are declared at the start of the .as class file, signified by the keyword package.

package myPackageName{
}

Now, if we decided to create a Button class with specific behaviour in a hypothetical package called game, it will not conflict with the Button class of the Adobe suite.

package game{
    public class Button{
        //this class will not conflict with the Button class of the Adobe suite!
    }
}

Access of variables among classes from different packages depends on a function’s access modifier. The only way a variable from one package can be accessed from another is if the function’s access modifier is set to public.

The chart below will explain how access modifiers affect classes.

5Aug/090

Using the AS3 Debug Console

Unlike the examples given in the tutorials and example files, it is very likely that you'll encounter errors at some point of your Flash programming journey.

Most of the time, the errors would be straightforward - for example, you have supplied an incorrect number of arguments in yourFunction(), or you have forgotten to close some parentheses in line XXX.

Sometimes, however, you may receive an error that is a bit cryptic, and the compiler error output doesn't pin-point the line where it all went wrong - that is when you use the in-built Flash debug console.

Download today's files here.

Look into the code at frame 6:

button0.addEventListener(MouseEvent.CLICK,handleClick0);
button1.addEventListener(MouseEvent.CLICK,handleClick1);

var flyingPig:TextField;

function handleClick0(evt:MouseEvent):void{
        trace('handling button click');
        trace('i wonder if this exists: '+ flyingPig);
}
function handleClick1(evt:MouseEvent):void{
        flyingPig.text = 'piggy!';
        stage.addChild(flyingPig);
}

When the code is run, everything seems fine- when you click on button 1, you receive the following error:

TypeError: Error #1009: Cannot access a property or method of a null object reference.

Disaster! Not only do we not get 'piggy' written on the top of the stage, but the error says nothing about where the problem is!

We can simply use trace messages to solve our bug in small bits of code like this, but let's imagine that this bit of code was part of a large project for now.

Let's run the in-built debugger by selecting 'Debug > Debug Movie' from the top menu or by using the shortcut: Ctrl + Shift + Enter. Make sure you enable the Debug Console and Variables windows from Window > Debug Panels.

Flash now runs the movie in Debug Mode. When you hit button 1 now, you get the same error with some extra information:

TypeError: Error #1009: Cannot access a property or method of a null object reference.
at flash_debugger_fla::MainTimeline/handleClick1()
[flash_debugger_fla.MainTimeline::frame6:11]

Amazingly, now Flash will tell you the exact line where the error happens!
Ok, so this means that something's wrong with our flyingPig constructor... hey what constructor? That's right, we declared the variable, but neglected to construct the TextField with new TextField().

The Flash debugger will stop executing code when one of two things happen:

  1. Flash has hit an error
  2. Flash has hit a breakpoint.

In the above case, the debugger runs into the error only when the user clicked on the button. Sometimes, we may want to debug our code even though there is not an error - that is when we put breakpoints into our code.

We can do this by clicking on the far left hand side of our code, in the column next to the line number. This must be done next to executable code, and you will see a red dot appear. Clicking again will remove the breakpoint.

Back to our example. Let's say, we've forgotten how to construct a new object - we're completely convinced that simply declaring the variable will be sufficient. /eyeroll.

We'd prove it by looking at the Variables window. Expand 'this', and you will find all the variables available to the Stage (which is 'this').

Debug Console Variables

Debug Console Variables

Scrolling down we'll find 'flyingPig' as a variable, but its value is a big fat NULL.

Of course! We got a null object error because the object was null - it all comes together so perfectly.

To solve this, we simply add the following line before 'flyingPig.text = 'piggy!';'

flyingPig = new TextField();

The Variables window also has some cool features we haven't used - for example, all the read-only variables are greyed out, but some values can be tweaked during the debug session so that you can see its effects before writing the code.

Since we fixed our code, the debugger may not stop for us again, so we'd want to put a breakpoint in our code. Simply click on the blank column next to line 1 of our code. This will stop our code from running further in the debugger, and let us play with the variables.

Breakpoint

Breakpoint

We can try this by looking up button1's alpha variable (currently at 1.0). We can change this to 0.5 and see its effects by clicking the 'continue' button in the debugger.

Often, the actual movie can get hidden below all your windows when the debugger executes a prompt. When this happens, you can see the movie by minimising all your windows, but you won't be able to interact with it until you give permission to the debugger to continue executing code.

31Jul/090

Branching Logic (Boolean Logic)

In the depths of Shabbyway Valley, arcane rituals are being performed by old and wrinkly mages in search for Flash Grandmastery. All of a sudden, they discover Boolean Logic, and open a rift to a parallel universe.

We've seen how simple conditionals have been able to help us make loops and smarter programs that behave differently when given certain, well, conditions.

Booleans are all about true's and false'ses, it helps to know what values to expect when. It's like working out the double negatives in maths.

Logical OR

The OR operator (represented by ||) is used when you want to return 'true' if at least one of a set of conditions is met.

For example, if I need a sword OR a shield, I'll go to the armoury. If I don't need anything, I won't go to the armoury.

true || true //returns true, although just one true would be sufficient
true || false //returns true
false || true //returns true
false || false //returns false, neither values are true
false || false || true //returns true, because at least one value is true
false || false || false || false // returns false

When we try to insert non-boolean values in the expression, Flash will first convert everything to boolean values, and return the first value that converts to 'true'. If nothing converts to 'true', then the last value is returned.

10 || 11 //returns 10. Both convert to true, but 10 came first
false || 'blart' //returns 'blart'. The nonempty string converts to true
NaN || undefined //returns undefined. All values are false, but
                       //undefined is the last value
undefined || false// returns false. All values are false, which means
                       //the last value is returned- it happens to be false

Logical AND

Represented by '&&', an expression with the Logical AND operator returns true when all its values are also true.

For example, if I have a longbow and I have an arrow, then I can shoot the troll. If I have anything less, then I cannot.

true &amp;&amp; true //returns true, because all values are true.
true &amp;&amp; false //returns false, because not all values are true.
false &amp;&amp; false //returns false, but just one false value is sufficient.

Logical NOT

Represented by '!', the Logical NOT operator returns the Boolean value opposite of the expression. It behaves differently to the OR and AND operators because it only acts on a single operand.

Logical NOT is helpful for testing what isn't as opposed to testing what is, making it useful to detecting unexpected errors.

For instance, instead of saying:

"If it is Monday, OR Tuesday, OR Wednesday, OR Thursday, OR Friday, OR Saturday - go questing"

We use the NOT operator instead:

"If it is NOT Sunday - go questing"

var today:String
if(today != 'Sunday'){
    goQuesting();
}

The NOT operator is also useful for toggling:

//when event is triggered - toggle flamingArrows
flamingArrows = !flamingArrows
if(flamingArrows){
    //light the arrows
}else{
    //extinguish the arrows
}