If you want to use windows in AIR with custom chrome (especially transparent) you have to consider some drawbacks. First you cannot use NativeWindow if you want to use Flex components from the mx.* namespace. There is a separate Window class in the AIR package which encapsulates a NativeWindow. To get your own content inside this window you can create a separate MXML file like this:
<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Window xmlns:mx=”http://www.adobe.com/2006/mxml”
width=”200″ height=”100″
transparent=”true” systemChrome=”none” type=”normal”
showStatusBar=”false” showTitleBar=”false” showFlexChrome=”false”>
<PlaceYourContentHere/>
</mx:Window>
This will display a transparent window without any controls and header on the screen.
Whenever you want to create and display the window use:
var myWindow:MyWindow = new MyWindow
myWindow.open()
If you want to change the position of the window you have to use its nativeWindow property:
// Center window
myWindow.nativeWindow.x = (Capabilities.screenResolutionX – myWindow.width) / 2
myWindow.nativeWindow.y = (Capabilities.screenResolutionY – myWindow.height) / 2
I used to use the NativeWindow class for transparent windows since AIR beta 1. To get Flex-Containers in it I initialized them in the main application window, removed them there and added them to stage of the NativeWindow. This worked fine until I used controls like ComboBox or ColorPicker which relied on the PopupManager. The popup window didn’t occur until I found that it was opened in the main application window at the position of the initial component.
Hello,
very useful advice. I wonder if you could expand, so if we want to use Flex Components we can create a separate MXML window and initialize that instance of a window or my making it through var window:Window = new Window();
When would we want to use a NativeWindow instead of an MX/Flex Window? Is better just to use a MX/Flex Window to be on the safeside and to prevent running into buggy situations?
Another problem I have ran into is following the event handling for NativeWindowBoundsEvent.MOVE for the main /first window “WindowedApplication”, because the WindowedApplication is an MX/Flex Window (Can contain Flex Components). I’ve tried this.nativeWindow for attaching the event, no go.
Thanks,
Chad
Comment by Chad — 22.05.2008 @ 18:33 |
Hi,
This is with respect to AIR windowing system. I am working on an application where components have to added/ removed from the main application window and added to new windows.
The issue I am facing is with Comboboxes, tooltips all show up in the main application window rather than the popped up window. I am using mx:Windows and mx:WindowedApplication.
Please let me know If you have any thought about it.
Thanks & Regards
Vandana
Comment by Vtrinity — 21.04.2009 @ 23:22 |
I remember having the same problem. It is the PopupManager who is responsible for this behaviour. You could use one whole-screen native window with transparent chrome and put the other windows as Canvas in them. The user doesn’t feel the difference.
Hopes this helps.
Markus
Comment by pegolon — 22.04.2009 @ 5:50 |
Thanks for your reply.
Can you please elaborate a little more.
I would like to give you some more details about my application. I have WindowedApplication(Main App ) with custom chrome and there are dividebox, canvas, hbox containers within it. I add the components from mx:window to the containers inside the main app and vice versa. And I see that tooltips, comboboxes do not come on the mx:windows but rather on the main app.
I appreciate your response and look forward for some more..
Vandana
Comment by Vtrinity — 22.04.2009 @ 17:20 |