dispatchEvent()™

As promised I’m back with more goodies! This time I’ve extended the simple window manager to support document windows as well as application windows. I also included a class that binds to your MenuBar in an empty menu and keeps it populated with a list of windows. Clicking a window name in the menu will activate, unminimize, and bring the window to the front.

Application windows are windows that can always be brought up, like an activity window, or an about window. When you create an application window, it is created and hidden. Pressing the close button on the window is captured to hide the window rather than allowing it to be destroyed. Thus, it occupies a permanent position on the Window menu.

Document windows are windows which can be created and destroyed. You can have many instances of the same view class. These are useful for new mails or text files or what-have-you.

The main window has a special use. When you attempt to close it, it attempts to close all the child windows as well — so you can have an opportunity to save your unfinished document windows.

This is the windowing toolkit at work on an Apollo app I’m finishing up now. File→New Mail… creates a new document window with the compose view, and adds it to the Window menu. As you change the subject, the title of the window and its name in the Window menu are updated. The Window menu also permanently has several application-wide windows which the close button appears to close. The Window menu brings them and any other window back, even if they are minimized, hidden, or stacked on the bottom.

After the cut, let’s take a look at how this is set up in code.

Continue reading →

I was just working on a good way to flexibly manage my application’s document windows in Apollo, and when I started trying to throw real windows up, I ran into a wall. The windowing docs clearly showed an example of adding display objects right into the stage of a NativeWindow, but I wasn’t able to spawn windows with views in them. After banging my head for a while, I found the note cleverly hidden at the very top of the asdocs with a bold “Important”! Those tricky Adobe technical writers. Anyway, you can add in an HTML view, or display objects, but apparently those windows run their own instance of Flash Player: you can’t just add in Flex components. I would be curious to find out if cross-window scripting is also impossible now. I would guess so. I’m guessing that getting a unified Flash Player execution environment across native OS windows in all supported OSes is a challenging hurdle (to say the least).

At least mine eyes did not deceive me about the other feature I really am looking forward to, native menu bar support. This is more of an issue for the Mac platform since menus are already grouped with the main application window in Windoze.

So these two limitations kind of throw a wrench in what I was trying to do… I guess I’ll do the Windows 3.1 thing and have one big window with a window-docked menu, and containing the document windows as children. The document windows and menu will both be standard flex components within the main Apollo window. Anyway, I’m looking forward to the next public alpha rev! Hopefully it’s on its way :)

Update: I was thankfully wrong about cross window applications, even in the alpha. Adding Flex components requires a pretty straightforward workaround. Daniel Dura’s approach. Todd Anderson’s approach. Ask (a stupid question) and ye shall receive (an answer from the internets)!

Update: Native window saga part two, part three.