'as' isn't the equivalent of typing.

I guess I hadn't thought too deeply about it, but I always thought that the 'as' Operator was the equivalent of typing a variable.

pseudo code example:

type(x) = as type

or to give a real world example:

var myVar:String='3';
var myInt:int=int(myVar);
//or alternatively:
var myInt2:int=myVar as int;
trace(myInt,myInt2);

But this code will trace:
3 0

I've realised that while typing a variable actually converts the variable to the requested datatype, 'as' merely informs the compiler to expect a certain variable to be of a certain datatype.

In the above example, 'myString as int' doesn't work because myString isn't an int.

However, if initially we had defined myVar like so:
var myVar:*=3;

The code would have no problem as myVar is an int.

ComboBox direction

This blog has moved.

I needed to force the Flex ComboBox to open in a specific direction. (I'm using a HTML Component FCKEditor, which has to be on top, so I need to aim the ComboBox away from it, so it doesn't animate underneath it)


It seems as though the only way to do this in Flex is to edit the mx.controls.ComboBox class itself. With some help from typeoneerror, I went ahead and did just that:


i added two booleans to the class to use to force the comboBox's direction:


public var forceDirectionDown:Boolean = false;
public var forceDirectionUp:Boolean = false;


now in the displayDropdown method, inside the 'opening the dropdown' section, i just changed the if statement:


if (forceDirectionUp || (!forceDirectionDown &&
point.y + _dropdown.height > screen.height &&
point.y > _dropdown.height))


There is still a problem, however - when I set the Combo to 'forceDirectionDown' and there isn't enough room at the bottom of the screen, when the dropdown closes, it assumes to animate the dropdown down, away from the combo. To resolve this, I added to the 'closing the dropdown' section, where it sets endY. I changed the condition line to:


endY = (forceDirectionUp || (!forceDirectionDown &&
(point.y + _dropdown.height > screen.height || tweenUp))

"Color" component parameter

I never really understood why when you define a component parameter, you can define its type. Wouldn't the variable type that the parameter is related to, always define the type of the parameter? Aren't parameter and variable types synonymous?

Well, it turns out that they are not necessarily.

I've never paid much attention to the fact that you can specify the 'type' of a parameter in the Inspectable tag, as it was obvious to me that this would be the same as the variable type.

But I've discovered at least one case where this is not so.

Attempting to define an Inspectable variable as type 'fl.motion.Color' seems to work okay - it invokes the Color Picker in the Component Inspector when you click on the component on the stage. However when in the Component Inspector when you change the color from the default, and run the file, you'll get:

1067: Implicit coercion of a value of type int to an unrelated type fl.motion:Color." error.

Obviously Flash expects the parameter of type 'color' to be related to a variable of type 'int'. Seems a little strange but there is a way to get around this apparent conflict between parameter and variable types of 'color':

Specify the parameter to be of type 'Color' and the variable to be of type 'int'.

package
{
import flash.display.MovieClip;
public class test extends MovieClip
{
private var _color:int;
[Inspectable (type = "Color")]
public function get color():int {
return _color;
}
public function set color(value:int):void
{
_color = value;
}
}
}

Flex - skinning the DateField icon

This blog has moved.

When adjusting the Date icon skin in a DateField component, its not sufficient to just use the css that Flex auto-generates when importing the Skin Artwork. In addition to 'skin', you must also specify that upSkin, overSkin, downSkin, disabledSkin are all set to null. otherwise they will supersede 'skin'. you do this for example, like so:


DateField {
skin: Embed(skinClass="DateField_skin");
upSkin: ClassReference(null);
overSkin: ClassReference(null);
downSkin: ClassReference(null);
disabledSkin: ClassReference(null);
}

adding classes dynamically Part II

A little addition to a previous post on adding symbols dynamically from the library. I was having difficulty adding classes(that weren't in the library) dynamically - they weren't being recognised.

var classRef:Class = getDefinitionByName("Square") as Class;
var shape:IShape= new classRef() as IShape;
//Flash displays: ReferenceError: Error #1065: Variable Square is not defined.

With help from Aaron Beall(on adobe forums) who was having the same problem, i've realised that obviously flash doesn't know to compile the class if it only exists in a string. So we need to ensure that flash compiles every possible class that we may refer to dynamically. We can do this simply by declaring a variable of that class type.

var squareRef:Square;

CS4 component icon library bug.

I've been wondering why items in my library disappear occasionally - including the library buttons and column headers!

I've narrowed the problem down to a CS4 bug. Steps to reproduce bug:
1.Create a MovieClip
2. Select 'Component Definition'
3. Add a parameter so that the component icon will become visible.
4. Select 'Seek Bar Control Icon' or 'Buffering Control Icon' as custom component icon.
5. Select 'OK'
6. Watch the craziness ensue!

jerky raster animations

It has always bothered me that animations of raster images are always jerky when they get to the point of animating less than a pixel per frame. Flash assumes that rasters should only live on the exact pixel.

This can be resolved with bitmaps that are created with ActionScript with the Bitmap.pixelSnapping value but for pure animation is a little more complicated.

I've just discovered that if you adjust the scale, rotation or skew of the image, Flash will turn pixelSnapping off. So giving a slight degree(more than 0.1%) of one of these factors is the simplest way to demand no pixelSnapping, without requiring one line of ActionScript.