Monthly Archives: January 2004

IconEngine support for V1 and V2

I have been working to integrate IconEngine to be compatible with V1 and V2 components, here is an update on my progress.

Below is the iconEngine integrated into V2 components, button, menu, list, accordion, datagrid.

The requirements for the implementation are as follows:

1. No additional library assets other than the V2 components, pure ASCII.

2. Icon usage is done via documented component methods without modification.

3. No edits to any Macromedia code (EULA compatible).

4. Forward compatible with support for V3 and FLEX components.

If you see any problems in the rendered swf, please let me know in the comments. Assuming compatibility testing goes well, version 1.3 of the IconEngine should be right around the corner.

Much to come.



OT : No Power in Kingston, Jamaica

In third world light, we encounter the occasional power outage. This one started at 9:20AM and lasted to 5:15PM.

The power goes out in Jamaica with regularity. Typically the outages last about 3 minutes, so today I decided to wait it out. 2 hours later, I called my wife and arranged a long afternoon lunch. Leaving the house, I assumed the power would be back on when I returned. I only really got worried when on my way to lunch, I passed a large JPS (Jamaica Power Service) repair truck driving slow. 4 JPS workers were on the back of this firetruck sized vehicle, all of them staring at the power lines as the truck drove 2-5 MPH. The troublesome part is that 2 of the workers were smoking spliffs during their search for the broken spot. I instantly knew that this would be an all day affair, if not longer.

During my stay in Jamaica, my patience has improved 1000%. There is nothing more grounding than being told “Soon Come” when you ask how long something is going to take. In Jamaica, “Soon Come” can mean a few minutes, a few hours, or never, it is all in the way it is said.

I can’t wait to move back to Washington DC in July!

A big thanks to Apple Computer, my ipod batteries lasted the entire day!



Debugging Central Applications

You can use the Central Debug Panel SWF outside of the Flash IDE making a perfect standalone debugger.

The debug panel swf works perfectly in the standalone player and allows you to see trace commands without swiching apps. Simply copy this swf file and make a standalone player using File>Create Projector from the standalone player.

Mine was located here:

C:\Documents and Settings\Administrator\Local Settings\Application Data\Macromedia\Flash MX 2004\en\Configuration\WindowSWF\Central Debug Panel.swf

Perfecto! 1000% better!

This should be a Central application!



The Central Installer/Updater – 101

Working with the Central installer/updater is confusing, yet it is critical to successful deployment of your application.

Key concepts and problem areas for installing and updating Central applications:


1. Central applications are deployed to a URL with a domain name. The URL cannot run on your local machine or on a local web server “localhost”. Central apps are installed locally based on the domain name as the root of the file system.

2. The Central Installer/Updater works only with the product.xml file. If you change files on the web server but not update the product.xml, Central will NOT know files have been updated. The only users that receive these updates will be on new installations of the application.

If product.xml is not modified, Central will not update. (See 5 for specifics on version property of product.xml)

3. I have encountered problems with relative path urls within the product.xml file. As such I use the full URL path within the product.xml file. Central documentation clearly says otherwise (this is used within the sample apps in the SDK), but I tend to do what works in practice. Call me crazy!

4. I version all files by filename within the product.xml. This makes updates work perfectly. Here is a sample:

Note that each swf file for apps or pods are always named per version. If I am working with version 1.2, the application src will denote a file “main12.swf”. This avoids caching errors and makes absolutely sure my updates take when an update occurs.

5. For Central to update a deployed application, the following values must be modified by a full .1 in value. Changing versions by .001 or .03 will not force Central to update anything. These values are essential in the product.xml file as follows:



6. DO NOT EDIT THE INSTALLER BADGE!!! Just drop the badge swf file(s) adjacent to the product.xml and this will create a perfect installer. This also allows you to share this installer URL so your application will install from other sites for marketing/promotion purposes. This is the logic behind using absolute paths in product.xml as in certain cross domain installations, relative path urls will fail. ;(

The badge dynamically imports the product.xml file and loads the icon and text content automatically regardless of where you call the application.

7. Every application deserves its own directory. I also recommend adding a index.html file so just the path will provide access to the installer.

8. The product id inside of product.xml defines the application licensing. Sample applications ship with a common product id and thus when Central attempts to install one, it will overwrite the other application for licensing reasons. This product id is the same in the Central SDK sample applications:


This is ok to use for development, but when you go to deploy these product ids will cause problems if they are not changed.

9. Within your swf make sure that this actionScript executes only 1 time:

Central.initApplication(this, this)

This code initializes your Central Application. When it doesn’t execute, Central will not execute onActivate and you will thus not receive argument references to the shell and other good stuff.

10. For your first application, upload a sample app to a URL. Install the application within Central. Navigate to the locally installed path inside of the Central path, this is typically:

C:/Documents and Settings/{UserAccount}/Application Data/Macromedia/Central/#Central/{RANDOMKEY}/{domain}/{path}/{files}

I am not sure of the local install path on Mac.


Mac path is as follows:

{Hard Drive}/Users/{USERNAME}/Library/Application Support/Macromedia/Central/{domain}/{path}/{files}

Special thanks to Sean Voisen for the Mac path info.


Once you locate the installation directory, if you modify any of these files and simply restart Central, your application will change. This is a great way to develop as you can do iterative build and test locally without posting anything to a web server. This has saved me hours of hassle, time, and frustration.

11. THE SAMPLE APPS ALL NEED TO BE COMPILED!!! None of the Central apps are compiled in the Central SDK and for first timers this can be overwhelming and exhaustive. Here is the HelloWorld Sample app for review. This version has been modified to make deployment easier. I flattened the file system on the example to make it easier to understand. Also the badge and badge html is included in the example. Just post a valid domain name and call the URL, successful install!

Compiled HelloWorld Application(Only deployment Files)

Source HelloWorld Application(All Files)

Install HelloWorld in Central

This alone might explain developer frustration in getting first applications working. This isn’t rocket surgery, lets keep things simple.😉

12. I have also encountered problems with Central debug panel installed in MX2004Pro. On many occasions, the trace events simply do not occur at all and monitoring a Central application within FlashMXPro is frustrating switching between apps.

13. The icon tag in product.xml must be listed within the product.icon and application.icon otherwise it will fail to install locally in the badge, Central Installer dialog, and the application icon in the toolbar. The HelloWorld app in the Central SDK contains this error and the icon will not load for the product. This has been corrected in the version above.


At first glance all these gotcha items seem overwhelming, but don’t let that stop you from working with Central. Once you get your first application installed, you will discover just how simple Central is to work with.

Take the plunge and deploy your first Central app today. Central simply rocks!😉



Icon Explorer 1.2 and Icon Engine 1.2 Released

I have updated the Icon Engine and added format changes to Icon Explorer 1.2.

Version 1.2 Changes:

1. Icon Format supports unlimited colors

2. Icons Format supports a header (name, created, copyright, x,y)

3. Icons Format supports positioning via x, y header properties

The format design changes made the engine simpler and thus much faster at runtime. In basic testing the performance improved about 30% on average. In additon the format changes make format conversion easy, including ICO, MAC Icons, GIF, PNG, JPEG. Also the changes allow for icons to carry header information inside the icon format. Icon Format 1.1 is not compatible with Icon Engine 1.2 but it is easy to convert with a text editor or Icon Explorer.

Here is an example of the pixel shifting with cursors via the icon header x, y. Notice the cursor snaps to a pre-defined location on the pointer not the (0,0) coordinate:

source code

You can also easily override the default header setting by passing a coordinate during drawIcon:

//draw an icon and shift it horizontally -10 and vertically -12


Icon Explorer Central Installer

Special thanks to Mario Klingemann for helping with the format. Thanks Mario!😉



Icon Engine 1.02 Proposed Changes

Having working with the Icon Engine and Icon Format all week, I am seeing areas for improvement. Here are the proposed changes for version 1.02 of the format and engine.

Proposed changes to Icon Engine:

1. Change CLUT limit from 26 colors to unlimited color values.

2. Improve performance and simplify engine design.

3. Add Header to support Meta Data within Icons like Author, Created, Modified, Copyright, Company.

The biggest of these is the CLUT changes as these imply moving from the Alpha mapping to a numeric mapping. We are also looking to add a delimiters to the pixel Block values to speed processing and enable future format additions in a structured manner. The key weakness in the format is runtime processing, anything we can do to make the Icon Engine faster is worth the time and effort. Ideally, Icons of various sizes should be easy to render and burden the player minimally. The shift from Alpha to numeric color values makes processing much faster as colors are referenced directly vs calculated from an Alpha value.

The header addition is also very important as it allows metadata to be added into the icon. This is especially true in regard to copyrights and author credits. This will also make the icons portable allowing IconExplorer, Icon Professional or other Icons IDEs or tools to read and display this critical information.

Special thanks to Mario Klingemann for so eloquently voicing his issues with the format. I am especially encouraged that many in the Flash community are embracing the format. I am hopeful that we can establish an open standard for icons for the Flash platform.

Please voice your concerns about the format changes in the comments here. Icon Engine will formally moved to version 1.02 next week along with a new release of Icon explorer and the included icons. I will also be releasing a free tool to convert your icons from 1.01 to 1.02 and add header information.