I have been asked about this from various different angles and responded to it (often with ammo from others) in various different ways. I have decided to compile all info I can as a starting point to address questions hat typically come up from Flex customers regarding Flash Player Memory Management and Flash Player Garbage Collection.

CAVEAT: I am not a Player engineer and haven’t looked at the Flash Player code, but this is my understanding from several discussions with the engineers on the Flash Player and Flex Teams. (Some of this info is taken directly from emails, forum postings and conversations I have had with Alex Harui, Matt Chotin and Gordon Smith.)

Also, Grant Skinner goes into far more detail on his blog about Flash Player Memory management and Garbage Collection.
If you want to know more than the high level that I am going to address here you should check out his blog entries:

http://www.gskinner.com/blog/archives/2006/09/resource_manage.html
http://www.gskinner.com/blog/archives/2006/06/as3_resource_ma.html
http://www.gskinner.com/blog/archives/2006/09/garbage_collect.html

The underlying Flash player is essentially a garbage collection memory model. That means that if nobody has a reference to an object, it will be collected and thrown out eventually. Thus, you never have to delete anything, just make sure all of your references to it are broken by removing objects from the displaylist, removing event listeners or using weak listeners where appropriate.

The Flash Player runs within the browser’s memory space and Firefox or IE give memory to the player. The browsers are then responsible for the memory and will release it to the heap.

Here is a general description of what is generally going onwith memory management as an app runs:

The Flash Player grabs OS memory in large chunks, divides them up into smaller chunks and allocates those small chunks to the application. As the number of small chunks dwindles, the player runs a GC pass to see
if any of those small chunks can be freed before we go to the OS for another big chunk. If the application is idle and nothing is accessing memory, nothing is going to force a GC pass so nothing will ever get freed.

So lets say the Flash Player allocated 40 megs. If the app happened to get to 33 megs there may be no need for the Player to GC. And it could be that in reality the Player could get away with only 20 megs, but it will take that whole 40 b/c the OS is letting it. Still not technically a memory leak, even if you think the Windows Task Manager should show less.

The MemoryMonitor tries to force a GC pass (see the hack comment in the code). It is unclear as to whether the hack works perfectly.

GC is opportunistic. This means it does not run all of the time. It tends to be triggered by allocating memory instead of freeing it, so watching an idle app will almost never result in GC. Because of the fact that GC is more or less “opportunistic”, there is no current way to manually test for memory leaks. I think there are situations where lots of activity forces several large chunks to be acquired from the OS and then, when most of that stuff is freed, each of the large chunks has a few small chunks still in use and so the OS chunks are not released back to the OS because there isn’t enough activity to cause a GC pass. Therefore, the only way we “prove” there is a memory leak issue is to use MemoryMonitor’s callback to repeat a sequence over and over again.

Now, lets look at an example.

Read the rest of this post»

You technically cannot do this, since callLater() actually takes a function as an argument and a setter is an accessor.

However, rules where meant to be broken (or at least worked around).

You can do it by creating a function inline which sets the property within your callLater invocation.

Here is a simple class with a method and a setter:

Here is a simple app demonstrating the workaround:

A complete Flex Builder 2.0.1 Project Archive (.zip) of this sample can be found here.

I have been asked this a few time by customers and figured this was worthy of a quick post:

The release and debug player cannot co-exist on a machine.
(You can’t have release and debug activeX or release and debug plugin installed at the same time, but you can have release activeX and debug plugin)

A player (plugin/activeX control) with the same version#, regardless of debug or release type cannot upgrade an installed player with the same version#. You must first uninstall the player then install the other version of the same player# to switch between release and debug player of the same version#.

The debug player is not available to the general public; it is only available within purchase products (like Flash Authoring, Flex Builder, FDS).

A debug swf will run in either player, but only produce trace and throw RTEs in the debug player.

You can determine what version of the player you are running from within a Flex app using the following code:

I wrote a small sample for a customer to demonstrate how to write a Charting Datatip Renderer and Axis Label Renderer that displayed HTML links that when clicked on open up other web pages.

I based my renderers on the TextArea component, since that component has a link event that gets fired off if the TextArea htmlText contains an anchor tag that has an href that contains “event:”.

Here is the DataTip Renderer, MyDataTipRenderer.mxml:

Read the rest of this post»

I wrote a simple little extension to ComboBox to allow the dropdown to expand to the width of the widest entry and the ComboBox input to expand/contract to the width of the selected item. This is based on the simple ComboBox sample from the docs found here.

Here is the source code for the component:

Read the rest of this post»

I recently had a customer who was trying to debug his Flex components. Under certain circumstances the updateDisplayList() method of his component was getting called and it wasn’t obvious why.
In writing and debugging Flex components sometimes it would be useful to be able to see who called what method to figure out what is going on. Profilers are good for this, but unfortunately there is no Flex 2.0 (or 2.0.1) profiler. In speaking with Flex Engineer, Alex Harui (see his blog here), he suggested the strategy below:

• Subclass the component you are interested in (or if you are writing your own components just add the following to your component).
• Override the invalidateDislayList() method (or whatever method you are interested in).
• Create a new error object.
• Dump out the error objects getStackTrace() method.

This should get you the hierarchy of calls that caused the invalidateDisplayList call.
(And it is the calling of invalidateDisplayList that will flag the updateDisplayList() to be called.)

Read the rest of this post»