Flexible Code

I can’t say too very much about this but I do know for sure that in an AIR application I am working on we found that having an indeterminate status bar drove the CPU performance crazy. The interesting thing here is that I saw this with Vista, XP, and OS X. And, to top that, I found this when the progress meter was not even on the display list!

Let me explain that last part. I have it in a display stack and it’s not the selected item. So it’s in my MXML description, but not “drawn” as far as I understand it from a Flash perspective.

In any case, it’s a known bug for Adobe at this point. Note this will certainly get fixed, so check the date of this posting before you jump to the conclusion that this is your problem. In any case, see below for information on a bug report to Adobe on this item:

Deferred 1668388 [perf] Flex Progressbar set to indeterminite, the CPU usage is higher on MAC PPC (similar to bug 1657144)

This is the full description…
This may be similar to 1657144, but this particular test case (that has progress bar indeterminite set to true when compare to Windows performs worse on the Mac. In particular the performance on PPC is pretty bad and about 63% worse than the Flash Player Stand Alone.

I have tried tons of “mouseOut” and lose-focus types of solutions to deal with my AIR applications losing focus. Well, as of ActionScript 3 I find there is a new event (on the stage itself) which is published when the mouse leaves the movie.

stage.addEventListener(Event.MOUSE_LEAVE, myMouseOutFunction);

Finally!

I was hunting around today for all opened windows in my application. Seemed obvious enough and something Adobe would have included in the environment — and they did. But it was not something simple to find a reference to, so I thought I’d throw this post out there in the ether. Maybe someone else will find it useful.

var windows:Array = NativeApplication.nativeApplication.openedWindows;

Beautiful. And this opens up some other interesting possibilities:

Represents this native AIR application.

The NativeApplication class provides application information, application-wide functions, and dispatches application-level events.

NativeApplication is a singleton object, created automatically at application startup. Get the NativeApplication instance of an application with the static property NativeApplication.nativeApplication.

(from the api)

There are some interesting items in there:

• activeWindow : NativeWindow
  [read-only] Returns the application window that is currently active.
• applicationDescriptor : XML
  [read-only] The contents of the application descriptor file for this AIR application.
• icon : InteractiveIcon
  [read-only] The application icon.
• supportsSystemTrayIcon : Boolean
  [static] [read-only] Specifies whether AIR supports system tray icons on the current operating system.
• timeSinceLastUserInput : int
  [read-only] Returns the time, in seconds, since the last mouse or keyboard input.
• exit(errorCode:int = 0):void
  Terminates this application.
• undo():Boolean
  Invokes an internal undo command on the focused display object.

Of course I was already using several of these for my tray-icon and menus and such, but I didn’t know the window list was in here too.

This is a huge topic. I’m not going to do it any justice at all.

I was using NativeWindows to build my custom system and found quite a few issues figuring out how to “draw” to them the same as the main application window.

Several issues I found which killed me were:

1. Tooltips from items on the new NativeWindow were showing up on the original ApplicationWindow
2. The popup manager showed things on the App window as well.
3. Scroll bars were not draggable

So I decided it was me, and not just the “beta” of AIR that was at fault and it was time to investigate the real “mx:Window” class.

I am on Beta 3. But anyone reading this almost certainly is as well (or later). So who knows when all of this really started working.

I effectively replaced everything NativeWindow with Window in my application. I then went and set all the chrome and transparency settings on the window and it mostly worked. I had to rework my hand-managed drag-manager and oddly enough there was a funny “not system” chrome around the window I couldn’t get over.

In the end Bradacle on the post referenced below found the answer for me:

showFlexChrome=”false”

That takes off the extra chrome which can be found on the mx:Window object.

More info:

http://blog.everythingflex.com/2007/07/17/air-windows/#comment-4999