package {

	import fl.controls.TextInput;
	import fl.managers.IFocusManagerComponent;

	/**
	 * Extends the TextInput component in order to set the default width and
	 * height, and sets the focusRectPadding to 0 (so the focus rectangle lies
	 * directly on top of the grey text input border skin.
	 */
	public class TextInput2 extends TextInput implements IFocusManagerComponent {

		/**
		 * @constructor
		 */
		public function TextInput2() {
			super();
			textField.width = 1;
			textField.height = 1;
			width = 64;
			height = 18;
			setStyle("focusRectPadding", 0);
		}

		/**
		 * The UIComponent class, when the component is in focus, creates the
		 * uiFocusRect and sets it at childIndex 0. Unfortunately, the text input
		 * skin is then above the focus rect, and so the focus rect disappears
		 * when the focusRectPadding is 0. This calls the parent implementation,
		 * then ensures that the focus rect is visible by changing its
		 * child index.
		 */
		override public function drawFocus(draw:Boolean):void {
			super.drawFocus(draw);

			if (uiFocusRect != null) {
				setChildIndex(uiFocusRect, numChildren - 1);
			}
		}
	}
}

UPDATE: I updated the above script to set the size of the TextField in the TextInput component to be 1x1. This also fixes the problem that the TextField is created as 100x100 pixels when it is first created (as are all dynamically generated text fields). This matters if you wish to use any customized layout (such as the Yahoo astra layout managers), and don't want to have to call drawNow() or wait a frame to finalize layout settings in a UI.

Regardless of whether or not a shape, such as a rectangle, is drawn in Flash with a hairline border line, or a borderline of 1, the result on an unscaled shape is essentially the same. The crisp outline of the shape is drawn with a pixel width of 1. The downside of this occurs when trying to create pixel perfect UI's, and especially those using shapes with a scalenine grid assigned to them.

Using the AS3 drawing API, you can create a rectangle that has a lineStyle with a width of 1, and some fill, which would look something like this:

var sh:Shape = new Shape();
sh.graphics.lineStyle(1, 0xFF0000);
sh.graphics.beginFill(0xFF6600);
sh.graphics.drawRect(0, 0, 100, 100);
sh.graphics.endFill();
addChild(sh);
trace("Size: " + sh.width + " x " + sh.height);

The code above so draws an orange rectangle with a red border that is 201 pixels wide and 101 pixels tall. If you don't know why, the reason is because flash draws the line on the pixel width and height of the rectangle with a line size of 1. This makes your shape 201 x 101; thankfully, Flash will report the width and height correctly as 201 x 101.

This gets stickier if you have a shape that is used as a component skin, and has a scale9Grid applied to it. In this case you will likely be working with a component that you expect to take up 200x100 pixels on the stage when you tell it to be that size. However, if the skin used features "line" outlines at its borders, your component will get drawn on the stage with extra pixels. If you dig into the Flash component skins, you will notice that most of the skins use fills for any borders on the shapes (even 1 pixel wide borders) so that the scale9Grid enabled shapes will scale correctly to the pixel. That being said, the proper way to draw the simple skin shape in this case, programmatically, would be:

var sh2:Shape = new Shape();
sh2.graphics.beginFill(0xFF0000);
sh2.graphics.drawRect(0, 0, 200, 100);
sh2.graphics.beginFill(0xFF6600);
sh2.graphics.drawRect(1, 1, 198, 98);
sh2.graphics.endFill();
addChild(sh2);
trace("Size: " + sh2.width + " x " + sh2.height);

Incidentally, this also often cleans up some anti-aliasing at the corners of rectangular shapes which I believe is cause by some weirdness in the way the "caps" are drawn on the shapes. (but don't quote me on that...)

Update: the chumby widget can be found at http://www.chumby.com/guide/widget/Japanese Syllabary Flash Card. Enjoy!

The implementation of the interface method doesn't match its definition.

Despite the fact that MTASC has no problem with it.

*I believe* that it is acceptable according to ECMA script standards to define functions in interfaces by supplying the types of the parameters, rather than the names and types. Compare:

public function moo(Object, String):Void;

vs:

public function moo(cow:Object, foo:String):Void;

The former is handled fine by MTASC; however, when compiled in the Flash IDE, the error "The implementation of the interface method doesn't match its definition." is returned for every function defined in the interface that has input parameters. The solution is to define the methods is in the latter example; however, for the Flash IDE to compile without errors, not only do the parameter types have to match, but also the parameters names have to match.

Hopefully that will help someone searching for this error...

In most flash projects, interfaces are a bit convoluted and require thoughtfully building out to what amounts to an extra class. Most of the time in smaller projects, subclassing "default" classes pretty much gets the job done. To backtrack slightly for those unfamiliar with the term, an interface is an abstract type which is used to designate how classes can be accessed and manipulated. To use the terminology, an interface specifies the interface that must be implemented by a set of classes.

Utilizing Interfaces

Interfaces in actionscript are particularly useful when creating a set of classes that all have the same methods; the interface strictly defines the guidelines that must be followed when creating a new class of this type.

As an example, let us suppose that we are creating a set of shape classes; we will be creating a circle class and a square class. Let us suppose for now that the only method that we want to implement is the getArea() method. Here are our classes:

View as Plain Text

View as Plain Text

So, both implement the same methods here. We can define an interface for all new shapes that get created, which must all allow for the calculation of their area (note that by convention, interfaces usually begin with the letter "I"):

View as Plain Text

You must then go back and change your class definition line in each of the two classes to

View as Plain Text

and

View as Plain Text

The interface defines how we can interact with shapes. The big advantage of this when working on projects is that when using environments such as Eclipse with FDT, you can specify that something is an IShape without knowing what shape it is specifically, thereby allowing you to build more flexible projects. In addition, rather than the alternative, which would be to type them as Object, you have a way of typing them that works with syntax checking and code hinting, which saves you time in the long run.

Combining Interfaces with Inheritance

Another handy trick to help when coding is to combine the use of interfaces with inheritance. Let's suppose we want to create a Shape superclass as such:

View as Plain Text

So, our definitions would change as such:

View as Plain Text

Now we have a few added benefits. Our shapes are now subclassed as MovieClips and Shapes, which means that they can inherit methods from the Shape class. All of our shapes have a __type and all are now MovieClips, so all of them can inherit toString() and setColor().

The cool part about this is that in this case, we now can implement the IShape interface (remember, all classes that implement an interface are required to implement the designated methods) without declaring ones inherited from the superclass unless we choose to do so. This means that we don't have to add toString() and setColor() unless we want to override the ones in the superclass. This is really great when you have several private variables with getters and setters that you want required by the interface, but don't want to have to duplicate and comment in every single subclass.

Another advantage of using interfaces is that, unlike extending superclasses, classes can implement as many interfaces as you want. For example, you could have a set of Shapes that implement an IAnimation interface as well as the IShape interface. Other types of objects could also implement this same IAnimation interface, so you could call the method pulse(cycleDuration) the same way on both types of class, and your code hinting would tell you that the method pulse requires a number input. This is probably the biggest advantage -- being able to type an object as an interface when passing it to another object that wants to treat it as something that has the methods that the interface requires.

As for the code below, it is a simple drawing class that allows you to easily draw a generic box, a hairline box, and a filled rectangle. The main reason, however, that I created the class, is for those occasions where you may need a box that is not filled and is not made up of flash lines. If you've used Flash enough, you know that if you draw a 3 pixel line box, the corners are often rounded looking, which doesn't fly unless that is what you want in your design. I have worked on several projects that were to use photos that needed a "frame" of a certain width. The drawing class drawFrame method basically draws 4 filled boxes to create a rectangular "frame" of a certain thickness, made entirely of "fill" rather than lines, so the corners are nice and sharp. Of the instances where I have used this class, I have used the drawFrame method 90% of the time. Enjoy.

View as Plain Text

The scenario: I have been recently working on a project in which I am loading a sub-menu represented by a swf into the main flash movie. I am then dynamically assigning a sub-menu class to that new swf upon the onLoadInit call that is fired from the MovieClipLoader class.

The problem: once the .swf was loaded, I wanted to call the init() function that resides in the submenu class. Unfortunately, if init() was called when onLoadInit() was triggered, init() was fired before linked library items in the .swf were available.

Two solutions: One solution that worked was ridiculous. If I used an interval to delay the init() call for a half second (or less even), this was enough time. The other more sensible solution was to put this.init() in a frame of the timeline of the loaded .swf. This worked. My intuition said to put the this.init() call on frame 2, but it actually worked in frame 1. I develop in OSX.

The result: On windows machines, frame 1 was too early to have the this.init() call as well. The init call had to be moved to frame 2 in order for the symbols that were being exported in frame 1 to be available, particularly on windows machines. Frame 1 was fine for OSX.

I should have followed my intuition on this one. Having used Director for many years and Flash since Flash 3, I've come to distrust the fact that published Macro-dobe "movies" will actually perform properly on the first frame. Its not a huge work around, but I thought that this difference between the way the player performs in OSX and Windows (among others) was important to note.

Originally, the way that I had been doing this was to first create a class that extends MovieClip such as this ::

View as Plain Text

Then, I would create an empty movieclip symbol in the library of my .fla file, and give it a linkage id, and then in the linkage associate it with the AS 2.0 class of my choosing, or in this case, com.plasticstare.SpaceInvader.

There are a few problems with this beyond the fact that it seems a bit laborious to have to do this. When compiling code in MTASC, for example, you have to create a special little class to make sure that any .swfs that you are publishing as shared libraries actually get the newly compiled code and make a reference to it in your .fla files (or there is probably some other way to do this as well). Otherwise, if you make a change to your class for that linked symbol, you have to publish back out of the Flash IDE again. (And if you have a bunch of them, its a real pain.)

I stumbled upon another way of doing this today when checking out something else in the Flash LiveDocs. Someone had contributed the code below in its original form, and I've since made a couple of tweeks - one to fix a major flaw.

View as Plain Text

The idea would be to use this in your Main.as class or some utility class -- some class that you can reach universally. So, supposed that I have it in my Main singleton class. I would call the function this way

Main.getInstance().createExtendedMovieClip(SpaceInvader,_root);

in order to create a new SpaceInvader clip in the _root. _constructor is simply the name of the class that you want to instantiate, and _parent and _depth are the clip you want it to reside in and at what depth. (the latter 2 parameters as you see are optional) Using this code, you can just create any new Class that extends MovieClip and instantiate it as a MovieClip instance on the stage on the fly, without creating any special linked symbols in the library.

First, change the template to what you want it to be in the template editor. Then, copy everything except for the last 2 lines (which should be something like:

class ${enclosing_package_and_type} ${cursor}{
}

(To get to the editor, go to preferences/FDT/Editor/Templates) Now, go into your eclipse/plugins/com.pf.fdt_1.0.4/templates folder.

Open the file code codeTemplates.xml, and in the typecomment node, paste the text that you copied into the node value where it should currently say ::

/**
* @author ${user}
*/

I replaced it with the code (for example)::

/**
* ${enclosing_type}
* @author - Ryan Todd
*
* AUTHOR :: Ryan Todd
* AUTHOR SITE :: http://www.plasticstare.com/
* CREATED :: ${date}
* DESCRIPTION ::
*
*/

The @author is in there for the javadocs, and the ${date} is nice for inserting the creation date...

Now save codeTemplates.xml, quit and restart Eclipse. I'm not sure it this messes anything else up, but this is what I had to do in order to make the template I wanted to show up when creating a new class through the class creation wizard.

On the other hand, if you do change the class template and create a new class, like I said above, you can delete the inserted code and then use the code completion to insert the new class code and it will insert the template text that you put in using the template editor (which changes that text in the templates.xml file).

As an added note, you can also set FDT to overwrite the default ${user} variable in your templates in the FDT templates preference panel.

• In Eclipse, choose File-Preferences
• Next, in the prefs window, select ActionScript 2
• Open the Editor sub menu, and choose Templates
• The first template should be "class" - select it.
• Click the edit button on the right.

You can now edit your header template for all new class files. I took out "${user}" first, because my user short name on my powerbook is not the author name I wanted to use in my project classes. The "Insert Variable" button is pretty handy as well, as it allows you to choose from a variety of things to add into the template, including the current date and time. This is also handy for adding in any sort of licensing information you might want to throw in there.

After editing, hit the "OK" button and then the "Apply" button in the prefs window, and you should be good to go.

Phase 2 will be launching later this month, which will introduce a flash-based "community" that is built on top of a customized phpBB bulletin board system.

• Open the map in Illustrator
• Find and select an example of text you want to remove
• Choose Select :: Same :: Fill and Stroke
• Delete selected
• Now Choose File :: Save for Web...
• Select your save settings (.swf) and save
• Now import into your Flash movie

Of course, its not quite that simple -- there is always a bunch of other lines and artifacts that end up in there so you have to be patient, and selecting all those outlines in Flash can be painful (which is why I recommend clearing out everything you don't want in Illustrator first. Once you get the map into flash, you can then make adjustments to the fills, lines, and optimize the curves more. Once again I stress - be patient...and you shall be rewarded...

Using the example below, you can see that the trick is to include a private static variable in your class file that assigns that particular class ("InjectionMold" below) to the movieclip symbol ("ExportedSymbol" below) to which you would like it linked. This assigns the class for you at runtime.

View as Plain Text

The BIG advantage, however, is this -- if you have attached the code class to the symbol in the library, every time you change the code, you have to re-export the movie from the Flash IDE in order to compile the code. If you have jumped on the open source band-wagon and are using Eclipse with MTASC, you can in this way edit the file in Eclipse and use your favorite method of re-compiling through MTASC to re-"publish" the movie. My development machine is a 1gHz 12" Powerbook (I'm working on a tutorial for using Eclipse and MTASC with OSX - its not quite day in the park to set it up, but it works great once you're there), so re-publishing from the Flash IDE can be excruciatingly slow sometimes; re-compiling using MTASC is supposedly 1000 times faster, so you can imagine the time saved during the course of a project (its almost like dividing by zero).

Another little wierdness has to do with the output window (which I have all but abandoned at this point). If you assign mouse handlers to clips and send a trace to the output window, it gives focus to the output window, thereby forcing you to click twice on anything on the app before the mouse click will register.

• MovieClip.prototype.setPos :: handy for setting the position to an x,y coordinate
• MovieClip.prototype.hideMe
• MovieClip.prototype.showMe
• MovieClip.prototype.loadWithFade :: for loading jpgs and fading them in
• MovieClip.prototype.crossFadeTo :: for crossfading clips
• MovieClip.prototype.roundCoords :: for use with pixel fonts - rounds to nearest integer coords
• MovieClip.prototype.linearAnimate :: for doing linear animations of clip properties

Version 1.5

Download :: movieClipExtensions.zip