AIR window resize inconsistencies

14 May

The last two weeks I’ve been working on 3 different AIR apps and I have to say I really like Adobe AIR. It’s easy to develop for and quite consistent across the various Operating Systems. One thing that had me (and others) puzzled is how the windowing system works, so I thought I’d add a post for future reference.

There’s two main ways you control the appearance of the main application window. One is by setting properties on the mx:WindowedApplication tag and the other is to set properties in the application.xml file that defines each AIR app.

Resizing

The application.xml has a xml property that controls the resizing of your app:

<!-- Whether the user can resize the window. Optional. Default true. -->
<resizable>false</resizable>


So to prevent resizing, you just set this parameter to false, right? Not right. You will notice that the “gripper” is still present in the lower, right corner of your app and this allows rescaling. To turn off the gripper, just add showGripper=“false” to your WindowedApplication tag and that’s it. Or is it? Of course not. To make this work with the system chrome, you’ll actually have to turn off the Maximize button as well, making the complete settings like this:

<!-- The type of system chrome to use (either "standard" or "none"). Optional. Default standard. -->
<systemChrome>standard</systemChrome>
<!-- Whether the window is transparent. Only applicable when systemChrome is none. Optional. Default false. -->
<transparent>false</transparent>
<!-- Whether the window is initially visible. Optional. Default false. -->
<!-- <visible></visible> -->
<!-- Whether the user can minimize the window. Optional. Default true. -->
<!-- <minimizable>false</minimizable> -->
<!-- Whether the user can maximize the window. Optional. Default true. -->
<maximizable>false</maximizable>
<!-- Whether the user can resize the window. Optional. Default true. -->
<resizable>false</resizable>

The other option is to not use the operating system’s windowing style, but rather the standard one that AIR provides.

<!-- The type of system chrome to use (either "standard" or "none"). Optional. Default standard. -->
<systemChrome>none</systemChrome>
<!-- Whether the window is transparent. Only applicable when systemChrome is none. Optional. Default false. -->
<transparent>true<transparent>


These settings will automatically hone the

setting specified in the XML, so the window can’t be resized. You’ll still see the “gripper”, but it won’t have any effect and you can easily turn it off.

The Fullscreen bug

Another, slightly related thing you should be aware of is that there’s a bug relating to using standard window chrome and setting the

/

properties in the application.xml. If you turn off these properties, they will be grayed out (disabled). Once you set the app to FullScreen mode and return from it, the maximize/minimize buttons are now incorrectly set as enabled allowing the user to set them. Only workaround I know of is to loose the OS native window chrome.

It would be great if this was cleaned up and made more consistent for the next iteration of the AIR runtime. If I turn off the gripper, I want it to disappear (no matter what) and if I set resizable to false, I actually don’t want it to be possible to resize the app, no matter what.

I’d also love to be able set properties such as “Application.application.maximizable” at runtime so I don’t need the XML file at all. It’s really just annoying and messing up my development process.

Note: This post applies to AIR 1.5. I’m not sure, but I think this applies to NativeWindows as well.
airLogo.jpg

14 May 2009 at 7:38 pm

0 Responses to AIR window resize inconsistencies

  1.