An Easy Way To Append To a Log File in AIR

When you’re developing an AIR application it’s useful to be able to quickly save information to a file. Especially when it comes to things like tracking the memory usage of an application over a period of time.

This doesn’t require anything fancy. Here’s an example of a simple log() method that either writes or appends to a file called “Output.log” on the desktop:

public function log (text : String, clear : Boolean = false) : void {     var file : File = File.desktopDirectory.resolvePath (“Output.log”);     var fileMode : String = (clear ? FileMode.WRITE : FileMode.APPEND);     var fileStream : FileStream = new FileStream ();     fileStream.open (file, fileMode);     fileStream.writeMultiByte (text + “\n”, File.systemCharset);     fileStream.close (); }

It’s easy to modify an example like this to allow for different file names and paths. It’s also easy to append timestamps or other identifying information.

In short, quick and simple.

Issues Listening To SystemTrayIcon.menu Events

Something is definitely awry with system tray menu events on Windows.

All native menu objects in AIR dispatch a “displaying” event immediately before they are displayed. This gives you the ability to update the menu. It also prevents potential issues that could occur if you try to update a native menu that is currently displayed.

However, when I attempt to listen to this event on the native menu I’ve assigned to the system tray icon, the system tray icon no longer appears in my AIR application.

Take away the event listener and the system tray icon appears. Add it back and the system tray icon disappears. It’s unbelievably strange.

Alternatively, all of this functionality works as expected in dock menus on Mac OS X. It is only an issue with the system tray menus on Windows.

To take it a step further, I’ve discovered that listening to any event on the native menu assigned to the system tray icon causes this behavior. I can listen to events on the system tray icon itself, but not on its menu (or any submenus).

As a result, I’ve been forced to modify the native menu arbitrarily when one or more of the menu items needs to change. However this introduces an entirely new (and rather unfortunate) issue- repeatedly right-clicking on the system tray icon to activate the context menu will eventually cause a general protection fault (GPF).

So I can either try to handle menu changes properly, and as a result lose access to the system tray icon entirely -OR- I can forgo the events and just modify the menu whenever the hell I feel like it, knowing that it will eventually cause the app to crash.

Balls.