Class: dbView

Properties · Events · Methods · Index of Classes

Creates view objects.

Hierarchy

• cObject
• cUIObject
  • DfBaseObject
  • DfBaseWindow
    • DfBaseUIWindow
    • DfBaseContainer
      • DfBaseDialog
      • Container3d
        • MdiDialog
        • AppDialog
          • View
          • dbAppClient_
            • dbAppView_
            • dbView

Library: Windows Application Class Library

Package: Dfclient.pkg

Mixins: DFNavigate_Mixin

Description

The dbView class is used to create view objects. Views contain complete stand-alone and independent data-entry units that may include their own DataDictionary object (DDO) structure and data-entry objects (DEOs) that connect to this structure.

Source

// View1.vw - non-deferred view
Use dfClient.pkg
Use Windows.pkg
:
Activate_View Activate_View1 For View1

Object View1 is a dbView
    Set Label  to "My View1 Label"
    Set Size   to 120 280
    Set Border_Style to Border_Thick
:
End_Object

// View1.vw - deferred view
Use dfClient.pkg
Use Windows.pkg
:
Deferred_View Activate_View1 For ;
;
Object View1 is a dbView
    Set Label  to "My View1 Label"
    Set Size   to 120 280
:
CD_End_Object

Syntax

Usage:

Activate_View Activate_Object_Name for oObjectName

Object oObjectName is a dbView
    Set Size to Height Width
    Set Label to CaptionText
    :
    : Create Data-dictionary (or data-set) object structure
    :
    Set Main_DD to DDObjectName
    Set Server to DDObjectName
    :
    Set View_Latch_State to True | False
    Set DSO_Detach_Mode to detachMode
    :
    Set Verify_Save_msg to get_SaveMessage
    Set Verify_Delete_msg to get_DeleteMessage
    Set Verify_Data_loss_msg to get_DataLossMessage
    Set Verify_Exit_msg to get_ExitMessage
    :
    : DEO objects
    :
End_Object

Deferred_View Activate_Object_Name for ;
;
Object oObjectName is a dbView
    :
CD_End_Object

Of Special Note

The dbView provides a DEO view. dbView objects will contain a data-dictionary object structure and other DEO objects which connect to the DDO structure. A dbView object is an MDI (multiple document interface) object and must be placed inside of a MDI client-area object (ClientArea). dbView and View objects are usually saved in their own source files (.vw files) and placed inside of a client-area object with the use or #include command.

dbViews are usually activated by selecting an option from a view pulldown menu. A dbView should act independently of other views within a program. A view object will often be placed in its own package file. These object packages can be written and tested stand-alone and then easily added to any program.

DEO Container Object

The dbContainerForm is a data-entry container object (DEO container). A DEO container is an object whose native capabilities (in this case a Container3d) are augmented to support data-aware behaviors. These behaviors include:

• Finding, clearing, saving and deleting records (and sets of records)
• Change verification (save, delete, and data-loss verifications)
• Server support: DEOs connect to data-dictionary or data-set object structures

These data-aware "skills" are added to all DEO classes through a series of mixin classes. The messages are listed here but documented in the mixin classes. You are encouraged to study the mixin classes. Information provided in these classes may be applied to all DEO classes (all "db" classes). Those classes include: Nesting_Mixin, Navigate_Mixin, Verify_Mixin, Server_Mixin, and DEO_Delegate_Mixin.

Initializing DD Record Buffers

You may control how the data-dictionary structures' records are initialized when a view is activated. You may also control how the data-dictionary should react when a view is closed.

The default behavior is as follows:

• When a view is activated the record that happens to be in the buffer is loaded into the DDO and displayed in the view.
• When the view is closed, the DDO record buffer is cleared, losing any changes.

You may change this. A common change is to force the view to always activate with a cleared DDO buffer. Another change might be for the view to remember the record it was closed with and to reload that record (maintaining any changes). These behaviors are changed by setting the properties view_latch_state and DSO_detach_mode.

For these behaviors to work properly you must declare a main data-dictionary within your view by setting the main_dd property.

The Main_DD

The main data-dictionary is the primary DDO for a view. Sometimes this will be the child-most DD in a multi-file DDO structure. Other times this will be a DD that has parent files and child files. The child files are usually constrained to this main file (you can only see children of the main file) and are often represented in grids. A typical example would be an order-entry view. The order header file would be the main file; it will have constrained children (order-detail) displayed in a table.

The main data-dictionary is defined by setting the main_dd property. When a view is activated the record latch behavior centers around the file of the main_dd.

You will usually set the server of a view to the same DDO as the main_dd. Very often this will be the only server that will be set. All other DEOs in the view will acquire this server.

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 the view until it is activated. Deferring views will improve program load time. A view may be set as deferred via the Studio's Properties window.

Multiple Data Dictionary Object Structures

Implementing a single DDO structure per view is sufficient for most requirements. There are some special cases where you may need to display data from two separate data entities (i.e., unrelated database tables), where more than one DDO structure is required.

Another use of multiple DDO structures is when you may wish to represent two records from the same database table at the same time.

The DataFlex Framework supports multiple data-dictionary object (DDO) structures in a single view. You can declare multiple DDO structures in the same way you would declare a single DDO structure. You must select one of the DDO structures as the default: The view's Server and Main_DD property must be set to the Main_DD of the default DDO structure.

Application Exit Behavior

When an application is about to be exited, the client-area object will send two messages to each registered view.

1. It first sends the message getverify_exit_application to each view. If any view returns a non-zero value the application will not be closed.

2. When the verify_exit_application function is called the default behavior of all dbView objects is to call the view_changed function. view_changed determines if the view is changed by checking the changed condition of all child Data-dictionary (or data-set) objects, returning a non-zero value if any are changed. If view_changed reports a changed condition (returns a non-zero value) a verification message is displayed ("changes exist...") and the user is given the chance to halt the program exit.

3. 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 sends the message save_environment which saves the location of an active view. The next time the program is run and the view is activated, the view will appear in this location.

Verification Messages

Views are supplied default verification messages for the following operations: save, delete, clear with data-loss, and exit with data-loss. These defaults can be changed by setting the verify_save_msg, verify_delete_msg, verify_data_loss_msg, and verify_exit_msg properties.

Modal Panel Classes

The Popup_Modal message allows you to invoke a normally modeless View or dbView as a modal view. When modal, the view will act as a ModalPanel, meaning that it will float outside of the application panel and all windows under it will be disabled. See Popup_Modal for details.

Use with Tabbed Workspace Interface

A proper scrolling tab workspace view should surround the view's visible controls with a scrolling container and a scrolling client area object. The cCJCommandBarSystem object's pbTabbedWorkspaces should be set to True.

Object oSomeView is a dbView
    Set Size to 146 277
    Set piMaxSize to 175 350
    :
    // insert these objects before any visual controls are created in the view
    Object oScrollingContainer1 is a cDbScrollingContainer
        Object oScrollingClientArea1 is a cDbScrollingClientArea
        End_Object
    End_Object
End_Object

See Tabbed Workspace Interfaces for more information about implementing this interface.