Class: AppPanel [Abstract]

Properties  Events  Methods    Index of Classes

Provides a top-level window for applications that is independent of all other windows

This is an abstract class and should never be used by a developer for object instantiation. While a developer could use this class for sub-classing, it is not encouraged.



Library: Windows Application Class Library

Package: Dfpanel.pkg


AppPanel container class provides a top-level window for applications that is independent of all other windows. This class is an extension of the BasicPanel class and provides support for an MDI (Multiple-Document Interface) application. This class supports and controls MDI child components (a menu bar, a tool bar, a status bar and a client area). The descendant class, Panel, is the class normally used for instantiation. By default, an object of this class has icons for maximize and minimize, a resizable border, system-menu icon, and a caption bar.


Object Pnl is an AppPanel
    Set Size to 200 250
    Set Label to "MyTest Panel"
    Object ClientArea is an AppClientArea
        : Add Mdi view objects


Object object_name is an AppPanel
    Set Size to Height Width
    Set Label to CaptionText
    : Add MenuBar object
    : Add Tool bar object
    : Add Client area object
    : Add Status-bar object

Of Special Note

Three levels of programming classes are supported: basic (non-MDI, no support for tool bars or status bars), application (App... classes - MDI support, basic tool bar and tool-bar support), and high-level-application.

A proper MDI (Multiple Document Interface) application consists of an MDI Panel object (which contains and supports a menu bar, a tool bar, a status bar and a client area), an MDI client-area object which contains and supports child MDI dialogs or views. The App... classes (AppPanel, AppClientArea, AppDialog) provide the needed cooperative support to create an MDI application.

Although complete applications can be written using the App... classes, they are considered to be intermediate-level classes. A higher and more-powerful level of classes exists and it is expected that most applications will be written using these high-level classes (Panel, ClientArea, cToolBar, cStatusBar, MenuBar, View, and dbView).

Child component IDs

It is this object's job to coordinate activity between its various child components. In order to do this, this object must know if a component exists and what its object ID is. When a child AppClientArea, AppToolBar, or AppStatusBar is created, it registers itself with its parent (the object of this class) by setting the pertinent property in this object. These properties are Client_id, Toolbar_id and StatusBar_ID, respectively. These objects can be used by all objects within this object (via delegation) to coordinate activity between components. For example, entry objects will request status help by getting the StatusBar_ID of this object and sending the message to that status-bar object.

Controlling Components

This object automatically controls the size and placement of its components (menu bar, tool bar, status-bar, client-area). As components are added or removed from the desktop, this object handles the resizing and relocating of all components as required.

In addition, this object supports a number of properties and messages that control attributes and behaviors of the components. It may toggle the visibility of the tool bar and the status bar. It may also arrange the view objects within the client area (cascade, tile, minimize all, restore all).

Many of these messages are sent by other component objects to this object. For example, a popup menu choice may toggle the status bar's visibility by sending the toggle_statusBar message. This message will delegate to this object, where it will be acted on. Similarly, the popup menu may determine the status of the status bar by getting the StatusBar_state property (again by delegating to this object).

Exiting the Application

When a program is about to be closed, several messages are sent to this object. First, a verification function (verify_exit_application) is sent. It is the responsibility of code in this object to determine if it is appropriate to exit the application and return a zero value to close, or a non-zero value to abort the close. It meets this responsibility by sending this message to its client-area object. The client-area object will, in turn, send this message to all of its child view objects. This process allows all views in an application to verify that it is appropriate to exit the application. If any of these returns a non-zero value, the exit will not occur.

Once it has been determined that the application can be closed, a notification message is sent to this object (notify_exit_application) indicating that the program will be closed. This object sends this message to the client area, which in turn sends this message to all views. This ensures that all views are notified when an application is about to be closed. This allows each view to take whatever steps are necessary for a proper closedown.