cObject
---cUIObject
------DfBaseObject
---------DfBaseWindow
------------DfBaseUIWindow
---------------DfBaseContainer
------------------DfBaseDialog
---------------------Container3d
------------------------dbContainer3d_
---------------------------dbContainer3d
------------------------------dbTabView_
---------------------------------dbTabView
A data-aware tab dialog is created by creating a dbTabDialogView object and then creating dbTabView (or dbTabPage) objects inside of it. DbTabViews are used when each tab-page will contain a stand-alone view with its own DDO structure. In this case, a unique DDO structure will reside inside each dbTabView object. Each tab page displays a tab with its name on it within the tab dialog at all times.
Object oTabDialog1 is dbTabDialogView
Set Size to 117 271
Set Location to 10 15
Object TabPage1 is a dbTabView
Set Label to "Tab Page 1"
Set ToolTip_Value to "Tab Page 1 tool tip"
:
End_Object
Object TabPage2 is a dbTabView
Set Label to "Tab Page 2"
Set ToolTip_Value to "Tab Page 2 tool tip"
:
End_Object
End_Object
Use Windows.pkg
Object object_name is a dbTabDialogView
Set Size to height width
Set Location to row column
Set Rotate_mode to RotateMode
Object object_name is a dbTabView
Set Label to TabButtonLabel
Set Tab_ToolTip_Value to ToolTipText
:
: DDO Structure
: DEO objects
:
End_Object
Object object_name is a dbTabView
:
End_Object
End_Object
The only visual objects that can be placed directly inside of a dbTabDialog are dbTabPage or dbTabView objects. All other visual objects will be placed inside of the dbTabPage or dbTabView objects. DbTabDialog objects must be placed inside of another DEO container, usually a dbView.
DbTabPages are used when all of the pages in a view share the same DDO structure (the DDO structure will reside in the parent dbView object. DbTabViews are used when each tab-page will contain a stand-alone view with its own DDO structure. In this case, a unique DDO structure will reside inside each dbTabView object. You may not mix dbTabPage and dbTabView objects within the same dbTabDialog.
If there is not room in the tab dialog to fit all of tab-pages the tab dialog will allow the tab-buttons to be scrolled, or, will create multiple rows of tab buttons.
The size and location of a tab page is set automatically and is determined by the size and location of its parent tab dialog object.
The label displayed by the tab page's button is set and queried with the label property.
Individual pages can be disabled by setting the tab page's button_shadow_state to true (the tab button can not be selected and the tab page cannot be displayed) or by setting the page's enabled_state to false (the button is enabled, the page can be displayed but it cannot be entered).
Tab pages support tool tips. When the mouse is moved over a tab, the tool-tip text for that tab is displayed. The text value is stored in the Tab_ToolTip_Value property. The display of a tool tip is disabled if the text value is blank.
The rotate_mode property allows you specify where next navigation should proceed from the last object of a tab page. Modes are supported to allow you to leave the dbTabDialog (RM_None), ring within the tab page (RM_Ring), ring within the tab dialog (RM_Rotate_in_Ring) and to rotate through all tab pages exiting when the last object of the last page is encountered (RM_Rotate).
The dbTabView is a data-entry container object (DEO container) . A DEO container is an object, whose native capbilties (in this case a dbTabView )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.
Each dbTabView must contain a data-dictionary structure. It acts like a dbView and should be structured the same way dbView objects are structured. If an explicit server is set in this object it will most likely be the Main-DDO server for the view. All child DEOs will acquire this server unless they explicitly are changed.
You can set custom verification messages to supply save, delete, data-loss and exit confirmations. Normally, these verifications are defined within the view object (dbView) and acquired by all children. If new messages are required they often occur within the same object that sets a new server.
The dbTabView class supports the messages request_save, request_clear, request_clear_all, and request_delete. Normally these messages are sent from a DEO entry object and will delegate down through DEO structure until it encounters the obejct that explicitly set the server (often a DEO container). This makes it possible to define request-message behaviors at the container level so that child DEOs can make use of the definitions by delegation.
When this object's server is a data dictionary, this object will acquire a great deal of "knowledge" from the server. Although the container itself will not need to use this knowledge it will be used by all DEO entry objects that acquire the server.