Understanding Windows, Window Groups, and Types
The concept of a window in the Windowing API windowing environment differs slightly from what you're probably used to in a traditional windowing system. In the Windowing API windowing environment, applications are split into several windows when content comes from different sources, when one or more parts of the application must be updated independently from others, or when the application tries to target multiple displays. For example, a user interface that was developed in Adobe AIR can be overlayed on top of a native document viewer, or a plug-in can be embedded within a web view or document. Adobe AIR components can be used to form user interface controls for navigation or media playback. These controls can be contained within a window that is overlayed over top of a map or multimedia. In this example, the background window must be updated independently from the foreground user interface controls.
You must create window groups in order to organize, display, and control the windows in your application. A window group consists of a child window and a parent window, where a parent window creates and manages one or more child windows. To create a group, a window must call the screen_create_window_group() function and provide a name for the group. The name of the window group is then communicated to the other functions, threads, or even processes, that are responsible for creating child windows. Any child window can join this group as long as it has the associated group name. The parent window is notified each time a child window joins the group. A window handle is included in the notification to allow the parent window to control certain properties of a child window such as visibility, position, size, and z-order. A parent window cannot access any of the child windows’ buffers. A child window remains invisible until it is added to a window group and is made visible by the owner of the group.