 |
.NET database and distributed computing tools |
BFC | Visual Studio | Database Technology | Distributed Computing | Utility Classes
BFC's Screen and Application Library Classes
Extending MFC (Microsoft Foundation
Classes)
| Contents |
|---|
|
BFC is a large, integrated class library, broken down into subsystems that can be understood separately. A standard BFC application uses four basic low level libraries as underpinnings: the Utility, Database, Screen and Application libraries (derived in that order). The Screen library sits on top of the Database Library and depends on it because, for example, of the built-in Screen Dictionary records and mask edit controls that know about data dictionary information. The Screen library includes the Database and Utility header files, but has no knowledge of any other BFC subsystem but the BFC Resource DLL (B1RDLL). The Screen library is responsible for the basic look and feel of a typical BFC application. Programmers are free to alter the way their applications behave. The Screen library is constructed on top of a combination of Windows and MFC (Microsoft Foundation Classes) libraries and the BFC Utility and Database libraries. Application programmers can achieve completely different looks and feels by intermixing direct use of the libraries underlying the Screen library and deriving from BFC screen classes. The Screen library includes a wide variety of enhanced screen controls which can be used for building forms and dialogs with large scale scrollable tables (grids), combos, and tree controls (hierarchical list boxes). Sophisticated base classes for creating data aware edit controls, calendars, spin controls, 3D static text controls and bitmap buttons greatly simplify programming of commercial quality screens. Some of the major screen control classes include:
BFC Screen Control Classes Hierarchy Chart
Besides screen controls, the Screen library includes basic application building classes such as:
|
The Screen Library (B1SLib) provides a complete set of state-of-the-art
screen controls, such as table (grid) controls, tab controls, hierarchical list
boxes, enhanced status bar, 3-D and mask edit controls, etc., which are designed
to be easily connected to the database classes. Most controls are built using
MFC and the Win32 common controls.
Command File Document Screen
The Screen library makes extensive use of the classes in the Database and Utility libraries. A typical example is the relationship between the Screen library’s Edit Base class (clsEdBase) and the general purpose Database Field Mask class (clsDbFldMask) and the Utility Date and Time classes. The SetMask() function of clsEdBase can be used at any time to set or change the mask. (You still use the normal GetWindowText() and SetWindowText() to get and set the data in the edit control.) If a mask is supplied, clsEdBase does the required validation as the data is entered by user in the edit control and in case of any error, it flashes the appropriate message in the status bar.
The character and numeric mask formats available to clsEdBase come from the Database Field Mask class (clsDbFldMask). The mask can be obtained directly from the data dictionary by specifying the database record type (table) and field name (column). The characters to be used for currency, decimal point and thousands separator are obtained from Control Panel/Regional Settings (as stored in the Win.ini file): Similarly, the date and time format masks available to clsEdBase come from the Date and Time classes (clsDate, clsTime, clsDateTim). When clsEdBase recognizes a date format specification, it automatically provides a date lookup button that can be used to bring up a calendar. |
Test Form Screen
A programmer can do many database operations, such as AddRec(), either directly through the Database Library or go to the Screen library, which makes some standard end user interface assumptions. Adding a record using the database subsystem means filling in field values into an area of memory and then calling AddRec() to do the database insert operation. On the other hand, the screen library assumes a more complicated structure, with concepts of:
The database subsystem's AddRec() returns a completion code, e.g. APP_RetCodOk (0) if all goes well. The screen subsystem's AddRec() causes a completion message to be displayed on the status bar, possibly including a color (for example, "Duplicate data" in red, with a beep). In general, the meaning of a particular operation depends on whether it is being done by the Screen subsystem, which assumes end-user interaction, or the Database Library. For example, a screen Cancel means interrupting an end-user data entry operation, whereas a database Cancel would be a multitasking interrupt of an actual database operation, such as stopping a long running query or rolling back the addition of a record after it had already started. A screen Copy record operation means priming a data entry screen with the contents of another record, which allows the end-user to quickly make a few changes and then choose whether to add it as a new record or cancel. On the other hand, a database Copy record operation would directly copy a record from one part of the database to another. StartAdd, StartCopy, StartDel, and StartChg are all facilities provided by the Screen library that are not needed or provided by the Database Library. So, when you are thinking about screen based data entry or display, you will often find that the easiest way to do your database operation is to let the Screen library handle it for you automatically. On the other hand, concepts like screen Cancel (restoring previous values) have very limited applicability for batched, long running jobs of database operations, and for these you go directly to the Database Library.
Application Library Classes
BFC has the concept of deriving an entire application from another, in addition to just deriving individual classes. The Starter Application (ZZ_APP.EXE) illustrates how to derive from B1_APP.EXE. The Starter Application uses the classes, resources and command files of B1_APP.EXE as a base. The Application library classes, which are the starting point for a typical BFC application, include:
Application Class HierarchyA standard BFC application, like any MFC application, requires a CWinApp derived class to be constructed when other C++ global objects are constructed. When you create a new BFC application, a CWinApp based application class is automatically created for you. If you give your application a short name of "YYY" and an ID of
"YY", then there is an application class created called clsYYYApp.
Your application class, clsYYYApp, in turn is derived from the Foundation App's
application class, clsBFCApp. Since your
application class is derived from BFC's, you can override the functions of
clsBFCApp, such as InitInstance(), InitAfterLogon(), CleanupApp(), and
DispAbandonShip() to add your own behavior.
Finally, clsAppBase is derived from MFC's CWinApp, whose functions and data members are available to your application. To review the MFC hierarchy, CWinApp is derived from CWinThread, which is derived from CCmdTarget, which is derived from CObject. To summarize, the BFC application class hierarchy is as follows: CObject - MFC Object Class In addition, you can, in turn, derive a second application from your own
application (let's call it YD_App.EXE). Then, you can override your base
application's behavior to create an easy to maintain, custom tailored version.
In this case, the inheritance chain for the required application class (e.g.
named clsYYYDerivedApp) would extend one more level, for example: The bulk of the power of the BFC's application class comes from the Screen Library's clsAppBase and not from the Application Library's clsBFCApp. In general, you can derive directly from Screen Library classes and completely skip over the BFC Application library if you wish to entirely circumvent the typical behavior of the Foundation Application. However, usually it is much easier to accept the Starter Application as it is created for you and just override individual functions. Main Frame Window Class HierarchyLike most MFC applications, a BFC application has a main frame window, which
surrounds all of the other windows. Assuming you give your application a short
name of "YYY" and an ID of "YY", then there is a main frame
window class created for you called wndYYYMainFrame, which will be found in
YY_MainF.H & CPP. As is usual with MFC architecture, you can add handlers in
the main frame window class for your application's menu items.
clsWndMainFrameBase goes a long way towards eliminating the need for all those message handlers whose only function is to launch a form or dialog. clsWndMainFrameBase handles WM_COMMAND messages (for example, from selecting a menu item) that do not have corresponding message handlers. If there is an entry in the Menu Item, Form View and Dialog Info array (gastruMenuItmFrmVwAndDlgInfo) in your Global Definitions file (YY_GDef.cpp) for the ID selected and an associated form view or dialog, then clsWndMainFrameBase will automatically launch it. Finally, clsWndMainFrameBase is derived from MFC's CMDIFrameWnd, whose
functions and data members are available to your application. Although BFC does
not present a typical Microsoft Multiple Document Interface (MDI), because
database application end-users often find it confusing, the Base/1 Foundation
App contains an example of how to use BFC as the basis for a regular MDI
application. The Command File Editor/Viewer uses a CEditView and a Command File
Document class to illustrate the standard MDI model. (To
see this example of typical MFC document/view architecture, choose the File/New
or File/Open menu items in the Foundation App.) To summarize, the BFC main frame window class hierarchy is as follows: CObject - MFC Object Class Application Manager Class Overview Every BFC application is created with an Application Manager Class for registering application screens (forms and dialogs), documents, views, combos, menus, document templates, etc.. Assuming you give your application a short name of "YYY" and an ID of "YY", then your starter application will contain code for clsYYYAppMgr, which is derived from the Base/1 Foundation App's clsAppMgr. Screen Manager Class OverviewThe Screen Manager Class, clsScrMgr, provides some central functions for the screen library and the application as a whole. There is one instance of the Screen Manager Class (clsScrMgr) in the application. clsScrMgr allows for simplified launching of complex forms and dialogs, for
providing easy access to the status bar, the user's log, if any, and shared
resources such as pens, brushes & fonts, and handling abnormal termination
for all severe errors.
The clsScrMgr functions used to assist in handling Graphic Device Interface (GDI) objects include:
clsScrMgr provides some convenient wrappers for database functions, such as:
clsScrMgr plays a central role in error handling and logging for an application and has functions such as:
Other useful clsScrMgr functions include:
Form View ClassesScreens having forms for data entry and display are key ingredients of most business applications, and BFC provides several form view base classes as starting points. They are all eventually derived from MFC's CFormView and provide enhancements that:
There are 4 form view base classes:
The Form View Base Class (clsFrmVwBase) is derived directly from MFC's CFormView class and provides the basic additional functionality for the other BFC form view classes. You will seldom need to derive directly from this class, since most forms contain either a table of data, or individual record detail fields or both. Usually you will use the table form view, detail form view or table and detail form view base classes clsFrmVwBase responds to the private message PM_QueryNeedToStayOpen, and if a modification operation is in progress, it presents the user with the choice to Save or cancel the operation. clsFrmVwBase uses its Screen Database Buffer Class (clsScrDbBuf) member to determine whether the form is currently being modified. (See clsScrDbBuf for more information about screen database exchange.) clsFrmVwBase traps the PM_EdModified private message, which is sent by the Edit Base Class (clsEdBase), and sets the MFC document's modified flag only if the form has its own non shared MFC CDocument class. The Form View Table Base Class (clsFrmVwTblBase), which is derived from Form View Base Class, is used to present data in a tabular fashion. It coordinates with the Scrollable Table Base Class (clsTblScrlBase) and the Screen Database Buffer Class (clsScrDbBuf) to display data in a table. It also provides functionality to sort, search, or filter the data that is obtained from the database through Scroll Cache Record Set class (clsRecSetScrlCache). If the main menu contains a "View" popup menu, clsFrmVwTblBase dynamically adds Sort, Search, and Filter menu items to the top of the View menu. The Form View Detail Base Class (clsFrmVwDetailBase), which is also derived from Form View Base Class, is used to represent the details of a database record on the screen. The Database Access Control Form (frmDbAccCtrl) and the Batch Job Detail Form (frmBatJobDetail) illustrate this model. The Form View Table And Detail Base Class (clsFrmVwTblAndDetailBase), which is derived from the Form View Table Base Class), provides coordinated table and detail fields functionality. User Administration (e.g. frmUsrMastLst) and Distributed Batch Processing Services screens (e.g. frmBatJobMastLst) illustrate this model. Here is the inheritance chain for clsFrmVwTblDetailBase, the Table & Detail Form View Base Class: CObject - MFC Object Class By convention, BFC uses the Hungarian notation of "frm" for form
view instances of all types (clsFrmVwBase, clsFrmVwTblBase, clsFrmVwDetailBase,
clsFrmVwTblAndDetailBase). You use the runtime class of the derived form while adding the document templates or while calling the screen manager's SetupFrm(). Automatic launching requires an entry in the array of Menu Item, Form View and Dialog Info structures (tagMenuItmFrmVwAndDlgInfo), maintained in your Global Definitions file (YY_GDEF.CPP). You provide the runtime class of the derived class to permit the screen manager (clsScrMgr) to launch the form view automatically, for example, in response to a menu command. To provide Sort and Search functionality, override GetPFrmSortSearchInfo() and return a pointer to the tagFrmSortSearchInfo structure. To provide Filter functionality, override GetPFrmFilterInfo() and provide all the filter information for the form in a structure of type tagFrmSortSearchInfo. Dialog Base Class OverviewThe Dialog Base Class (clsDlgBase) is the general purpose base class used for deriving dialog box classes in BFC. It is derived from MFC's CDialog and provides:
You can use a clsDlgBase derived class as a member or instantiate on the stack for dialog box functionality. Automatic launching requires an entry in the array of Menu Item, Form View and Dialog Info structures (tagMenuItmFrmVwAndDlgInfo), maintained in your Global Definitions file (YY_GDEF.CPP). You provide the runtime class of the derived class to permit the screen manager (clsScrMgr) to launch the dialog box automatically, for example, in response to a menu command. Here is the inheritance chain for clsDlgBase, the Dialog Base Class: CObject - MFC Object Class By convention, BFC uses the Hungarian notation of "dlg" for dialog instances. (e.g. dlgAbout, dlgBatJobMgr, dlgCmdProc) |
BFC | Visual Studio | Database Technology | Distributed Computing | Utility Classes
|
|
|||||||
| Home | Products | Consulting | Case Studies | Order | Contents | Contact | About Us |
|
|
|||||||
|
Copyright © 2012, Base One International Corporation |
|||||||