cObject
---cUIObject
------DfBaseObject
---------DfBaseWindow
------------DfBaseUIWindow
---------------DfBaseContainer
------------------DfBaseDialog
---------------------Container3d
------------------------dbContainer3d_
---------------------------dbContainer3d
------------------------------dbTabPage
A data-aware tab dialog is created by creating a dbTabDialog object and then creating dbTabPage (or dbTabView) objects inside of it. DbTabPages are used when all of the pages in a view share the same DataDictionary object (DDO) structure (the DDO structure will reside in the parent dbView object). Each tab page displays a tab with its name on it within the tab dialog at all times.
Object TabDialog1 is dbTabDialog
Set Size to 117 271
Set Location to 10 15
Object TabPage1 is a dbTabPage
Set Label to "TabPage1"
Set Tab_ToolTip_Value to "Tab Page 1 tool tip"
:
End_Object
Object TabPage2 is a dbTabPage
Set Label to "TabPage2"
Set Tab_ToolTip_Value to "Tab Page 2 tool tip"
:
End_Object
End_Object
Dftabdlg.pkg
Object oObjectName is a dbTabDialog
Set Size to height width
Set Location to row column
Set Rotate_Mode to RotateMode
Object oObjectName is a dbTabPage
Set Label to TabButtonLabel
Set Tab_ToolTip_Value to ToolTipText
:
: data entry objects (DEOs)
:
End_Object
Object oObjectName is a dbTabPage
:
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 data entry object (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 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 button the tool-tip text for that button 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 dbTabPage is a data-entry container object (DEO container) . A DEO container is an object, whose native capabilties (in this case a TabPage) 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.
A dbTabPage should be connected to a server (a DataDictionary object). The server can be explicit (directly set with the set Server message) or acquired from a parent DEO container. Often the dbView object will provide the server for a DEO container. All child objects will also use the server unless a child object explicitly sets a different server. Do not explicitly set a server if you do not have to. If the acquired server from the parent is correct, use it.
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 dbContainer 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.