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




Why mobile paradigms have permanently changed data consumption – The Data Revlolution

30 12 2009

Not long ago the world completely changed, and most people in the world completely missed it.

At first, I was one of those people. As part of my duties at work, I have to be mindful of UX (user experience). One of the most difficult tasks of UX has always been how to present data in intuitive and meaningful ways. Previous to this data revolution, many UX engineers would satisfy themselves with a variable cornucopia of buttons, myriads of menus, and tons of raw power exposed to the most simplistic user. Creating some of the most complex applications and logical mazes known to man. Read the rest of this entry »





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 »





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."/>