Class: AppDialog [Abstract]

cObject
---cUIObject
------DfBaseObject
---------DfBaseWindow
------------DfBaseUIWindow
---------------DfBaseContainer
------------------DfBaseDialog
---------------------Container3d
------------------------MdiDialog
---------------------------AppDialog
------------------------------View

AppDialog is used to extend the MDIDialog class to provide support with a level consistent with the App... classes. An object of this class is registered with and cooperates with its parent client-area object and all other App... level objects (AppClientArea, MenuBar).

This class provides a "basic" (non-DEO) MDI view which may contain objects of basic classes (Container, Group, TabDialog, Form, Grid, Button, etc.) and may never contain data-aware objects (any of the db... classes), such as dbView, used to create DEO views.

This class is not normally used for instantiation. Use the subclass View or dbView instead.

Sample

Object MyClient is an AppClientArea
 
    Activate_View Activate_View1 for View1
 
    Object View1 is a AppDialog
        Set Label  to "My View1 Label"
        Set Size   to 120 280
        :
    End_Object
 
 
    Deferred_View Activate_View1 For ;
    ;
    Object View1 is a AppDialog
        Set Label  to "My View1 Label"
        Set Size   to 120 280
        :
    CD_End_Object
 
End_Object

Syntax

Activate_View Activate_oObjectName for oObjectName
 
Object oObjectName is an AppDialog
    Set Label to text
    Set Size to height length
    :
End_Object
 
Deferred_View Activate_object_name for ;
;
Object oObjectName is an AppDialog
    Set Label to text
    Set Size to height length
    :
CD_End_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.

The application classes provide integrated support between all App...-level components (AppDialog, AppClientArea, AppStatusBar, AppToolBar, and MenuBar). Accordingly, the AppDialog class registers itself with its parent client-area when it is created. This client-area object must be based on the AppClientArea class (or a sub-class).

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).

When an object of this class is created, it will register itself with its parent client area. This way, the client-area object has a method for sending messages to all MDI child objects.

Activating Views

Views are usually activated from the popup menu by sending a custom activate message to the client-area object. The custom message is defined by the command Activate_View or Deferred_View. Views may also be activated by sending the message Activate_view to the object.

Deferred Views

The Deferred_View command is used in conjunction with the CD_end_Object command to defer the creation of this object until it is activated. Deferring views will improve program-load time.

Application Exit Behavior

When an application is about to be exited, the client-area object will send two messages to each (registered) view. It sends the message get verify_exit_application to each view. If any view returns a non-zero value, the application will not be exited.

When the verify_exit_application function is called, the default behavior of all objects of this class is to call the view_changed function. If this function returns a non-zero, a verification message is displayed (changes exist.) and the user is given the chance to halt the program exit.

If all views allow the application to be closed, the client area will send the message notify_exit_application to all views. By default, this does nothing. It provides a hook to which you can attach any system-closedown operations you desire. It cannot be used to stop the program exit. The program will then be closed.