cObject
---cUIObject
------DfBaseObject
---------DfBaseWindow
------------DfBaseUIWindow
---------------DfBaseControl
------------------DfBaseList
---------------------DfBaseForm
------------------------DfBasetabDialog
---------------------------TabDialog_
------------------------------TabDialog
---------------------------------dbTabDialog_
------------------------------------dbTabDialog
---------------------------------------dbTabDialogView
dbTabDialog is used to contain and provide coordinated access to dbTabPage objects. Each tab page displays a tab with its name on it within this object at all times.
The dbTabDialogView class is a class similar to the dbTabDialog class, but it is used to contain and provide coordinated access to dbTabView objects, each of which supports a separate DataDictionary object (DDO) structure. The dbTabDialog class supports only one DDO structure for the entire dialog.
Object TabDialog1 is dbTabDialog
Set Size to 117 271
Set Location to 10 15
Object TabPage1 is a dbTabPage
Set Label to "TabPage1"
:
End_Object
Object TabPage2 is a dbTabPage
Set Label to "TabPage2"
:
End_Object
End_Object
Use windows.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 | dbTabView
:
End_Object
Object oObjectName is a dbTabPage | dbTabView
:
End_Object
End_Object
The only visual objects that can be placed directly inside an object of this class are dbTabPage objects. All other visual objects must be placed inside the dbTabPage objects. Objects of this class must be placed inside 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).
If there is not enough room in this object to fit all of tab pages, this object will scroll the tabs horizontally, or will create multiple rows of tabs by "wrapping".
Setting the enabled_state property to false will disable entry into all tab pages inside this object. Individual pages can be disabled by setting each tab page's button_shadow_state to true (the tab cannot be selected and the tab page cannot be displayed) or by setting the page's enabled_state to false (the tab is enabled, the page can be displayed, but it cannot be entered).
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 users to leave this object (RM_None), ring within the tab page (RM_Ring), ring within this object (RM_Rotate_in_Ring), and to rotate through all tab pages once, exiting when the last object of the last page is departed (RM_Rotate).
This class provides a data-entry container object (DEO container) . A DEO container is an object whose native capabilities (in this case, those of a TabDialog) are augmented by 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.
Objects of this class should be connected to a server (a data-dictionary 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. 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 and will delegate down through the DEO structure until it encounters the object 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 DataDictionary, this object will acquire a great deal of "knowledge" from the server. Although this object itself will not need to use this knowledge, it will be used by all dbTabPages.