cObject
---cUIObject
------DfBaseObject
---------DfBaseWindow
------------DfBaseUIWindow
---------------DfBaseContainer
------------------DfBaseDialog
---------------------Container3d
------------------------MdiDialog
---------------------------AppDialog
------------------------------View
---------------------------------dbAppClient_
------------------------------------dbAppView_
---------------------------------------dbView
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.
// 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
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
The dbView provides a DEO view. DbViews will contain a data-dictionary object structure and other DEO objects which connect to the DSO 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.
The dbContainerForm is a data-entry container object (DEO container) . A DEO container is an object, whose native capabilties (in this case a Container3d )is augmented to support data-aware behaviors. These behaviors include:
These data-aware "skills" are added to all DEO classes through a series of mixin classes. The message 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 are: Nesting_Mixin, Navigate_Mixin, Verify_Mixin, Server_Mixin, and DEO_Delegate_Mixin.
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 cleared DDO buffer. Another change might be for the view to remember the record it was closed with and to reload that record (maintainting 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 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.
View 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.
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.
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.
When an application is about the be exited the client-area object will send two messages to each registered view. First it sends the message get verify_exit_application to each view. If any view returns a non-zero value the application will not be closed.
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.
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.
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 the verify_exit_msg properties.
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.
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 object 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.