Undocumented functions in Flash. A huge annoyance: reset()

20 05 2010

Synopsis:

Today has been a really frustrating day. I am writing a new game, and I’ve been making great progress so far. It’s highly optimized for memory performance (so far) and probably as OOP as I’ve ever done. Needless to say I’m rather proud of it so far. It’s been pretty smooth sailing all along, until today. When I found that there is some undocumented behavior. I am using a methodology called Object Pooling. Which basically means I am re-using instances rather than re-creating them. However, as I was going along I hit a nasty little problem. As items came up for re-use all of the visuals were missing. Everything else was there in memory, but the screen was blank. You can imagine my frustration. An to prevent others from experiencing the same frustration, I’ve decided to write what I found here.

What I found:

The items in question eventually inherit from flash.display.Sprite. I was also implementing a custom interface which defined a single method.
function reset():void;

I had this so that when I put the object back into the pool I could call this method which would restore the instance back to it’s default state. However it seems that there is an undocumented “feature” that won’t let me name my function “reset”. Maybe I’m blind, but I couldn’t find it here:   http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/Sprite.html#methodSummary When I would call that function all of the visual elements of that class would be erased when I tried to add it back to the display list. As soon as I renamed the function to “resetItem” everything worked perfectly again.

A Word of caution:

Unless you too want to experience countless hours of frustration, *DO NOT* name your functions “reset” when extending from Sprite**.

** I don’t know it it also occurs when extending other things. I didn’t want to take the time to check because I was pretty peeved.

Advertisements




Persistent HTTP Connections and Flex Data Services w/ Zend_Amf

10 12 2009

I encountered some time ago, what I was convinced was a bug in the Zend_Amf protocols. It seemed to me that something was wrong with the ACL, or the way that things were being called. And it still may be, I don’t know. Here is what I was experiencing. Read the rest of this entry »





Minimum Age Validation Component

12 11 2009

The other day I took my first foray into the world of Custom Validators. I have to admit, I was intimidated at first. However, I needed to provide some validation to a form that I was writing. Rather than writing a sub-routine that was only usable once, I decided that I should make something a little more re-usable. Thus my MinimumAgeValidator was born. It can be used via straight AS, or in MXML. Code after the jump. Read the rest of this entry »





Focus Management with the Flex Component Kit for Flash

5 11 2009

At work today we found a bug in the Flex Component Kit for flash. The basic synopsis: when you create a “component” in flash using the CS3 component kit it automatically causes you to extend a base class known as mx.flash.UIMovieClip. This class is very useful, as according to it’s own documentation it allows you: Read the rest of this entry »





Validating a checkbox in Flex via MXML

29 10 2009

The other day, I ran into some trouble where I needed to validate a checkbox in Flex. I wanted to use a built-in validator, mostly for it’s ease of use, and because I am trying to keep basic elements like that into the MXML where I can. I searched around, and found some great tutorials on using Validators, but nothing on doing it to a checkbox. So I endeavored to figure this out on my own. In the end I used a StringValidator to accomplish this. When it attemts to validate on the checkbox, the “selected” property is automatically coerced into a string format. So in case anyone else wants to do the same thing, use the code below.

<mx:FormItem label="I agree to the terms of use" required="true">
<mx:CheckBox id="terms"/>
</mx:FormItem>
<mx:StringValidator source="{terms}" required="true" property="selected" maxLength="4" requiredFieldError="You must agree to the Terms of Use." tooLongError="You must agree to the Terms of Use."/>