negush blog

There are a lot of cases when your Flash animation is quite large in terms of file size. It contains images, perhaps some smaller .flv movies or a few “heavy” components.

In this case, if you publish your project somewhere on the web, you might have to wait a little, some times a little more, until the clip loads and starts playing. In this case it is very common (and quite frankly, necessary) to display something while your clip loads so the viewer knows there’s something going to happen and wait until your clip is completely loaded. In AS2 this wasn’t so hard. All you had to do was to move your animation to start from the third frame (but not necessarily), deactivate the “Export on first frame” setting from your symbols and components in the Library, place them on the second frame of your movie so they would load their assets (not necessary for all of them) by the time they would be instantiated, change the frame onto which classes were loaded from frame 1 to frame 2 and finally write some code on the first frame that would set an onEnterFrame event handler to display a preloader clip according to the size of your clip loaded so far. Lee Brimelow has made a nice video tutorial on how to preload flash clips, posted here: http://www.gotoandlearn.com/play?id=18. Again, this part isn’t necessary if you don’t want to display the amount of downloaded data and you only have a nice animation instead.

For ActionScript 3.0, the same thing is possible, only with the code changed to the AS3 syntax. You can download the example file from the link at the end of the post. However, this not always works. I’ve tried this with several components and looks like the method described earlier does not fully work. This is the case when using JumpeyeComponents’ TxEff or FlashEff. Even if you un-check the “Export in first frame” option from the Linkage Properties dialog box, there still is a considerable amount of data loading on the first frame. Don’t know why, yet… probably it has to do something with the embedded text (remember that TxEff and FlashEff need embedded characters for text effects). If this is the case, then you’ll probably have to wait a while until even your preloader shows up.

A workaround I’ve been using for this problem is to create the animation clip normally, without considering any preloading and then create a second clip I would use to load the first clip. This second loader clip would have all the preloading capabilities implemented into it. So, now I’m preloading an external .swf file. There’s also an item in JumpeyeComponent’s Knowledge base that addresses this issue: http://www.jumpeyecomponents.com/knowledgebase/TxEff-AS3.0/Preload-TxEff-animations~439/.

However, this arises another problem: in case of timeline animations, if that animation is in the external .swf file that you’re preloading, it so happens that the animation would start before the preloader is gone (while the preloading action is still going on). In this case, there’s a simple solution: move the entire timeline animation so it starts on the second frame and on the first frame place a stop() function. This way, your swf will not start the animation. Finally, after all the external .swf is loaded, just access the content in your loader object and instruct it to start playing from the second frame by using a gotoAndPlay(2) or gotoAndStop(2), if that’s the case.

You can check out these examples I’ve made.

Adobe just announced their Flash Platform, which now includes both Flash Player and Adobe AIR, the tools for developing content for the players, the Flex framework (not the builder… that’s the tool), all sorts of servers to be used with Flash and third party stuff… From now on, this all this will be referred to as Flash Platform. Also, the diagram representing the entire Flash Platform shows the design tools (After Effects, Illustrator, Fireworks and Photoshop) that can communicate with he development tools of the platform, through the FXG format. The development tools of the platform are of course Adobe Flash and Flex Builder and a new tool for those who tend to be more design centric than code centric in their work – Flash Catalyst (formerly known as Thermo).

Catalyst will be announced by Adobe at the Max conference (which is going on these days). Also, the newest version of AIR is out – AIR 1.5 – which has been much improved from the previous version (better performance, Flash Player 10 and Webkit support) – go on and download it, if you didn’t already. Gumbo (the new Flex Builder 4) will also be available for preview and presented at Max. It seems that the new Flex Builder will have lots of improvements that will be followed (hopefully) by a new lightweight and scalable framework.

(Didn’t know what other title to give it, so this is what I came up with)
I came upon a strange problem a few days ago. I was trying to create a simple function that would take a String value and return that value in a simple data type (String, Boolean, Number, int or uint), based on a parameter specifying the type to return. So the easiest way was to use a switch test for all five of the types and return the value accordingly. When trying to return a Number, int or uint data type, I wanted to use a try..catch statement, just for making sure that the function would not break when using the parseFloat() and parseInt() functions. So, my function looked like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

function getValue(value:String, type:String):* {
 
	switch(type) {
 
		case "String": {
			return value;
		}break;
 
		case "Boolean": {
			return (value == "true");
		}break;
 
		case "Number": {
			try {
				return parseFloat(value);
			}
			catch(e:Error) {
				return NaN;
			}
		}break;
 
		case "int": {
			try {
				return parseInt(value);
			}
			catch(e:Error) {
				return NaN;
			}
		}break;
 
		case "uint": {
			try {
				var num3:int = parseInt(value);
				if (num3 >= 0) return num3;
				else return NaN;
			}
			catch(e:Error) {
				return NaN;
			}
		}break;
 
	}
 
	return null;
}

With the function in this form, it seems that the player simply breaks down and displays a whole bunch of error messages in the Output panel. Besides those, it also displayed the entire application into compiled code, looking something like this:


verify test_switch_fla::MainTimeline/getValue()
exception[0] from=42 to=52 target=56 type=Error name=e
exception[1] from=78 to=88 target=92 type=Error name=e
exception[2] from=117 to=153 target=157 type=Error name=e
stack:
scope: [global Object$ flash.events::EventDispatcher$ flash.display::DisplayObject$ flash.display::InteractiveObject$ flash.display::DisplayObjectContainer$ flash.display::Sprite$ flash.display::MovieClip$ test_switch_fla::MainTimeline$]
locals: test_switch_fla::MainTimeline String? String? * *
0:getlocal0
stack: test_switch_fla::MainTimeline
scope: [global Object$ flash.events::EventDispatcher$ flash.display::DisplayObject$ flash.display::InteractiveObject$ flash.display::DisplayObjectContainer$ flash.display::Sprite$ flash.display::MovieClip$ test_switch_fla::MainTimeline$]
locals: test_switch_fla::MainTimeline String? String? * *


It also had a few dozen lines more of this kind. Pretty strange problem, I told myself and tried to find out why was this happening. It turns out the problem were those return NaN statements from the try..catch blocks. If I would only use the return statement, without the value to return, that would turn out to be ok (except that the function would still have to return a value and would not be correct from the application point of view).

Also, when testing the try..catch block separately, not inside the switch statement, it seems that there is no problem when the return statement is found in the catch part of the block, including the value to return. So the next code throws no errors:

1
2
3
4
5
6
7
8
9
10
11

function testing():Number {
	try {
		var test:Number = parseFloat("kdhk");
		return test;
	}
	catch(e:Error) {
		trace("catch");
		return NaN;
	}
	return NaN;
}

In conclusion, do not place return value statements in the catch blocks if those blocks are placed in switch statements. Anyway, in my case, there’s no need for the try..catch blocks, since parseFloat() and parseInt() always return a value (NaN if the source string cannot be converted), so it makes no sense using the try..catch block. After reviewing my code, here is the simple conversion function:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

function getValue(value:String, type:String):* {
 
	switch(type) {
 
		case "String": {
			return value;
		}break;
 
		case "Boolean": {
			return (value == "true");
		}break;
 
		case "Number": {
			return parseFloat(value);
		}break;
 
		case "int": {
			return parseInt(value);
		}break;
 
		case "uint": {
			var num3:int = parseInt(value);
			if (num3 >= 0) return num3;
			else return NaN;
		}break;
 
	}
 
	return null;
}
 
 
trace(getValue("test", "String"), getValue("test", "Boolean"), getValue("test", "Number"));
//    test false NaN
trace(getValue("12.34", "String"), getValue("12.34", "Boolean"), getValue("12.34", "Number"));
//    12.34 false 12.34
trace(getValue("-23", "Number"), getValue("-23", "int"), getValue("-23", "uint"));
//    -23 -23 NaN

Finally managed to install this neat syntax highlighter plugin for Wordpress. I wanted to do that for some time but didn’t really have the time for that. Now, it’s done… I’ve installed it… See the proof below.

import fl.controls.Button;
 
/**
 * This is a simple function that creates a button on the stage. Really, there's
 * nothing interesting about it.
 */
function foo():void {
	var newButton:Button = new Button();
	this.addChild(newButton);
	newButton.x = 100;
	newButton.y = 100;
	newButton.label = "Hit me!";
	newButton.addEventListener(MouseEvent.CLICK, clickHdl);
}
 
// This is when you know that the button was clicked.
function clickHdl(evtObj:MouseEvent):void {
	trace("Can you read this ?");
}
 
// Calling the main function.
foo();

Maybe I’ll find some time to customize it a little