Also known as:

One of current projects involves some texteffects and I am loath to do anything on the timeline that can be done quicker by code. So my basic idea was (keeping the designer in me happy):

Doing the design stuff at design time on stage:

Doing the animate stuff at runtime through code:

At this point I was already thinking about converting the stage textfields to bitmaps but found I was thinking about optimising things too early, so back to KISS, basic principles first.

Silly me, I thought it would be easy in actionscript 2 to get the position of a character in a dynamic textfield. As in:

textfield.getCoordsOfChar (pIndex:Number)

but apparently no such thing exists. Ofcourse if you have a monospaced font, there are other ways to accomplish this, but this solution works for both monospaced and other fonts.

Although in actionscript 3 there is something like getCharIndexAtPoint, that is not quite what I needed.

Using a trick I managed to implement it in actionscript 2. Note that this is still under development, being researched etc, so it’s not a general I-will-work-everytime-approach. Anyway the basic principle is this:

• apply first the white textformat to everything, then applying the black textformat to the range (i, i+1)
  (basically in every iteration of the loop you set everything to white except the character whose position you are looking for)
• copy the textfield to the bitmap
• perform a getColorBoundsRect on the bitmap and voila an approximation of the character position

And I say approximation since it’s seems to be off by a couple of pixels, but close enough to be usuable. In addition large amounts of text will slow down the process considerably and small font sizes wreak havoc, but it’s good enough:

Download the prototype here, it includes the Greensock Tween classes, but you can use anything you like.

Also known as:

I was working on our AS2 logger today. In particular I was creating a setup where you could simply drop in a couple components in your fla and ‘tada’, you would have a reflecting logger at your disposal.

I’ll go into the reflecting logger and component creation in another post, because what happened was that during a test run I ran into the dreaded 256 levels recursion problem.

Some research indicated that the problem lay with getters and setters.

Imagine you have a class:

class TestClass {
    public function get id1 () {
        trace ("hello world");
    }

    public function id2() {
        trace ("goodbye world");
    }
}

Now do:

_global.ASSetPropFlags(TestClass.prototype, null, 0, 7);
for (var i:String in TestClass.prototype) {
    trace (
         "Property:"+i+" is function ? "+
         (TestClass.prototype[i] instanceof Function)
    );
}

Ok, truth be told, you will not do this every day. In fact building a reflection package is probably the only time this issue shows up. However I like to document stuff for posterity’s sake, so here we are.

Executing the code above will show something like:
hello world
Property:id1 is function ? false
Property:id2 is function ? true
Property:__get__id1 is function ? true
Property:__proto__ is function ? false
Property:constructor is function ? true

The _global.ASSetPropFlags is used to unprotect all the prototypes properties, in order to force them to show up. In a real situation, you should always make sure you keep track of the original settings of an object’s properties and revert the object back to those settings after you are done with it.

Anyway what is really interesting is that testing the id1 property to see whether it is a function or not, causes the underlying method (the ‘get’ method) to execute.

Luckily I never use getters and setters. But other people do. This is not to say that getters and setters are bad, just that I ran into a situation which I hadn’t anticipated .

In most situation this will not cause a problem either, but you never know. The getter might go into a recursive loop if no parameters are passed. A class might update it’s properties unintentionally, who knows? I don’t. I do know that if those side effects do happen, you will lose hours of precious time bughunting.

So how to circumvent these special properties of woe?
If you look closely at the output again, you’ll see something like __get__id1 in there as well.
These kind of methods will only be created by flash if you use getters and setters.

So how can you detect if obj[i] refers to a getter/setter and should not be executed?

Test for the existence of __set__i and __get__i.

As the saying goes, you’ll find the solution in the last place you look.

More information on ASSetPropFlags:
http://objectpainters.com/blog/2007/06/21/assetpropflags-explained/