See also our gui integeration philosophy or our PowerPlant to MFC portability section
This document describes the PowerPlant interface for OOFILE.
The PowerPlant application structure follows the generic structure described in gui.htm of dbEditHelper and dbBrowseHelper classes, coordinated with a single dbGUI per dbTable.
The first thing to remember is that we have a double-buffering situation. The edit controls have their own internal storage, which is what the user edits. The second level of buffering is the loaded record which retains the "original" value of each field.
We thus need to copy from edit control to record, then save the record to disk, before the changes are permanent.
This situation is complicated by the need to have user-defined calculated fields displayed on screen. If we just copy values back on leaving the screen, the calculations will always be performed on the old values. eg: if we enter BirthDate, an Age calculated field will not be updated to reflect the new value in the control, but keep calculating from the original BirthDate field value.
To cope with such situations, OOFILE copies the value back from the fields on exit. Thus the dbTable's fields in memory reflect the values in the edit controls, apart from the current field in which the user is typing.
The copying is achieved by having a concrete instance of a dbFieldLink for each pair of database field and edit control. These lightweight controls know how to map the contents of the field to and from the edit control. The time to copy is managed by the dbAbstractEditHelper.
On creation, each dbFieldLink adds an attachment to the edit control that will respond to appropriate actions. We have to add our own mechanism as the PowerPlant controls lack any "dirty" tracking mechanism. Classes such as dbGUIAdaptEditPane wire into the messaging system to note when actions such as copying dirty the field contents.
(c) Copyright A.D. Software 1994-2000 (All Rights Reserved).
Last Updated: 9th September 2001