| Bottom | Unframe | Help |

Locate in Contents | (framed)

Locate in Discussion | (framed) 

IF NOT this.svp_commander.CMDRM_AddFuncStep(this.svp_funcid, ;
  18, "m.cmdr_arg1.windowstate=" + ltrim(str(this.windowstate)))
    RETURN .F.
ENDIF

By using the new Commander argument, we can eliminate the surrounding IF ... ENDIF and RETURN .F., substituting the following equivalent single command line:

this.svp_commander.CMDRM_AddFuncStep(this.svp_funcid, ;
  18, "m.cmdr_arg1.windowstate=" + ltrim(str(this.windowstate)), -1)

Note that similar substitutions could also be made in all Saver-based applications (e.g. XFormDBF & BTCrit).  Since the bulk of application-specific Saver logic resides in SVM_Save methods, and these consist almost entirely of sequences like the one illustrated above, this change would be a major simplification.  Most importantly, SVM_Save methods would become much more compact, simpler to understand, and easier to maintain.  The effect of this change on performance would probably be negligible.

• gaps may appear in the listbox of available configs
• gray areas may appear at edges of the editbox

These somewhat bizarre effects seem related to rapid mouse movement, and the problem is correctable by slowly resizing the dialog a bit more.  While this behavior may be due to a VFP bug, it's possible that a little additional refreshing logic could eliminate the problem altogether.

Another resizing issue that could be handled better is the possibility of shrinking the dialog to the point where the splitter bar is obscured from view, or the listbox's scroll bar is not completely visible, or pushbuttons get too crowded, etc.  These problems should be fixed by enforcing minimum dialog height and width properly.  It might also be useful to support proportional resizing, at least as an option, for the splittable portion of the dialog (listbox/editbox).

Nadya mentioned noticing problems resizing the Pick Configuration dialog in her posting of 3/28/01, but she didn't give any specific details.  (Reproducible test cases would be very helpful.)

In her message of 2/8/01 Nayda mentioned a bug in the Switch To... dialog when there is a large of configurations to choose from.  Nadya pointed out that this is probably due to VFP Listbox bugginess.when there are more than 65 items.  The change to a Grid-based implementation should fix any such problems.

Nayda suggested a Print command for the pick config dialog in her XFormDBF Forum posting of 1/4/01, and again in her posting of 3/28/01, but note that this is really a Saver feature, which also applies to BTCrit, etc.

Note that the forthcoming Saver2 classes already added an argument to the old version of Saver.  The proposed change would add two more arguments, bringing us to something like this:

Init(funcid_arg, cmdr_arg, targob_arg, tmplid_arg, tmplfi_arg)

where:

• funcid_arg: is the functionid, as before
• cmdr_arg: Commander metafile, as before
• targob_arg: ErrHandler reference for target indirection
  This is the new argument already added in Saver2, which has the same meaning as it does in the new ErrHandler, upon which Saver2 is based.
• tmplid_arg: template functionid - proposed new argument
• tmplfi_arg: template metafile -  proposed new argument

Under the Saver2 architecture, XFormDBF (and BTCrit, when similarly updated) is a subclass of the new SaverForm foundation class, so it will be a simple matter to support these same additional Init arguments in XFormDBF (ditto for BTCrit).

Additional Saver changes will also be required for Commander's revised internal naming conventions.  These require small Saver changes to preserve compatibility with Commander changes, as a preliminary step before the more substantial Saver changes to make use of Commander's new error handling features.  We may as well also make adjustments to XFormDBF to switch over to the new Commander names, although compatibility provisions should allow these changes to be deferred.  Rebuild BTCrit and test to confirm that it still works without any changes to VFP code.

1. invoke Switch To...
2. supply a New Functionid and click OK
3. click on Save Config to save under new funcid

The new Save As... command would invoke the savrgetf.scx dialog, with the initial focus on the New Functionid field.  After the user enters a new functionid and exits from this dialog, the configuration would be automatically saved.  If an existing functionid is selected, the user would be prompted before replacing the old configuration.

1. copy SaverForm into temp.vcx
   drag and drop the class via VFP Project Designer against saver2.vcx.
2. rename SaverForm to SaverCust in temp.vcx
   via VFP Project Designer.
3. adjust records via browse against temp.vcx
   Make class alterations that can't be done via standard VFP tools like the Class Browser or Class Designer:
   1. replace class with 'errhandler' for objname = 'savercust'
   2. replace baseclass with 'custom' for objname = 'savercust'
   3. edit the properties memo field for objname = 'savercust'
      Remove lines for properties that don't pertain to Custom class, Caption and DoCreate.  Don't risk invoking Class Designer with these properties still attached.
4. copy SaverCust from temp.vcx into saver2.vcx
5. make remaining changes to class SaverCust via Class Designer
   Adjust comments, property sheet defaults, and method code as appropriate.  In order to minimize redundancy, we will want to introduce core Saver UDFs to handle generic aspects of logic.  Also continue to beef up error-handling logic at every opportunity.

A similar procedure would be use to create additional Saver foundation classes from SaverCust, to cover other VFP base classes as needed.  These foundation classes could then be subclassed by conventional use of the VFP Class Designer.

• Close button and/or Escape support in savrconf dialog
  The Config dialog should be easy to exit, as mentioned previously.  Escape should not be supported it it interferes with normal escape-from-editing behavior.
• compact graphical pushbuttons
  At least as an option, if not the default, supply small graphics for each of the generic Saver configuration button classes, as mentioned before.
• let Config dialog be a nested Saver-based form
  I.e. the state of the Config dialog's layout really should be saved and restored, and this would be most cleanly accomplished by using a nested Saver.  The parent configuration would then only need to store the Config dialog's configuration id.
• maybe use two rows of buttons for very narrow layouts
  This may become necessary as more controls are added.  Mentioned previously.
• maybe support a modeless Config dialog
  As mentioned before, this may be doable, but I'm not sure how useful it would be, so wait and see. 

Also see the following related tasks, which are listed separately:

• Save Config As... command
• support user-selectable configuration meta-files
• configuration/application version compatibility mechanisms
• automatic state-saving and prompting options
• Saver property for restricting functionid prefix
• packing facilities for Saver meta-files
• new svm_... methods for support of Saver command buttons
• support context-sensitive help in generic Saver dialogs

Another potentially desirable option is whether to prompt for destination or auto-creation of saved states.  As previously mentioned, the current implementation always auto-creates the state-saving meta-file if it's missing; this logic is handled in Commander.  We may want to provide prompting option(s) to control this at the Saver level.

These new generic Saver properties would be incorporated as check boxes on the generic Config page/form.

Add a way to explicitly PACK the current meta-file, e.g. via Saver command button and corresponding generic Saver method plus supporting core UDF.  Also add one or more properties to provide some reasonable automatic packing behavior, which should require no explicit user action.  As mentioned previously, a tricky complication is the need for an EXCLUSIVE opening in order to PACK.

This feature will be especially useful when a single meta-file contains a mixture of saved states belonging to a variety Saver classes, e.g. for parent SaverMain states plus child SaverForm states, as in the new Saver2 demo scenario.

Because the configuration meta-file records are indexed on functionid, this form of restriction can be highly efficient on large files.  Compare this with the more flexible, but less efficient capability of restricting configurations by category.

A prerequisite for comprehensive error handling in the SVM_Save and SVM_Restore methods will be to incorporate error-handling into the generic Commander facilities.  This can be done along similar lines to what was previously done for Querier, XFormDBF, and Saver.  Also see these related tasks:

• propagate Aborts and error info up the target indirection hierarchy (done 01/22/01)
• revise specs for default RETURN depth on user Aborts (done 01/13/01)
• pick up default diagnostic/tracing properties via target indirection (done 12/28/00)
• quiet Commander subclass for nested error handling requirements (done 11/11/00)
• optional ErrHandler Init argument for target indirection (done 11/10/00)
• changes for support of nested ErrHandlers (done 10/26/00)

• fix ON SHUTDOWN handler for modal dialog cases
  Be sure that this works for cases where a modal dialog is in progress.
• fix no-op state restoration of main modeless Config dialog
  Initial testing is aimed at confirming support of no-op Savers.
• testing/debugging of modeless Config dialog usage
  Especially review logic for issues related to the sequence of termination steps.  Check for implicit closing of associated modeless Config dialog.
• enable state-saving & restoration for main Config dialog
  Once the no-op case is fully debugged, let the modeless Config dialog behave like other state-saving forms.
• support optional args to demomain.prg
  Which would be passed on to demomain.init, i.e. the standard Saver2 Init args: funcid_arg, cmdr_arg, targob_arg.
• relaunching of child form should use path canonicalization
  To avoid the necessity of storing absolute pathnames in state-saving metafiles.
• introduce additional trace levels, as needed

The Saver2 foundation classes will include a new SaverForm class (based on ErrHForm, not to be confused with the old Custom-based SaverForm class) for forms that support state-saving and restoration.  Other Saver foundation classes will eventually be needed to support additional non-Form types that can use state-saving and restoration, e.g. Custom, Toolbar, Container, Grid, assorted control classes, etc.

The old Saver classes (used by XFormDBF and BTCrit) can eventually be phased out, because they will be superseded by the new error-handling Saver classes.  Both flavors will be allowed to coexist (in separate applications) to allow for a transition period.  In order to avoid needless complexity, there will be a separate project, class library, and supporting forms for the new Saver2 facilities.  This will also give me an opportunity to make another pass at improving some internal conventions.  The following module substitutions will be made in going from the old Saver facilities to the new version 2:

Note that in the old model, the Saver subclass object was added as a member to a form, which was based on the error-handling form class, ErrHForm.  In the new Saver2 model, a SaverForm class based on ErrHForm is used, eliminating the need for a separate Saver subclass member object.

In addition to the primary objective of introducing a Saver foundation Form class based on an error-handling class, the following general Saver refinements were included:

• extended argument syntax, allowing meta-file path
• clean conventions for Saver property and method names
• added error checking logic for Init method
  Also see additional methods yet to be adjusted.
• introduced selective saving toggle properties
• reduced size and complexity of state-saving
• simplified the Saver class hierarchy and demo app

• update savrpick.scx/sct
• delete obsolete saver.txt
  Superseded by Old Notes About the Saver Application.
• add link to to the new Saver forum
• delete saver.app
  This demo app should never have been in mdacomm in the first place.
• update xformdbf.app

• the Saver demo application
  Saver includes a standalone demo, which is useful for development and testing as well as being an illustration of the general facility.  As of Saver2, the demo was extended to give an example of nested Saver usage.  This needs to be explained clearly, because it goes beyond simpler non-nested Saver applications (like BTCrit and XFormDBF).  Sample screen shots would also be helpful.
• the Saver foundation class library and core functions
  The Saver foundation classes handle state-saving and restoration for specific base classes of objects, and these are further subclassed as necessary.  The class library also includes a variety of Saver-related command button classes and a generic configuration container class, SavrContConfig.  All of this should be documented in detail.
• generic Saver dialog forms
  There are two dialog forms, a resizable "Configuration" dialog and a "Pick Configuration" dialog, which should be documented.
• related underlying applications
  Saver uses the ErrHandler, Commander, and SplitCon applications.  The relationship to these other components should be clearly explained.  Also note include files and minor generic utilities used by Saver.
• using Saver within a higher level VFP application
  Explain how to go about incorporating Saver into an arbitrary VFP application, e.g. as done for XFormDBF and BTCrit.  Also discuss how to adapt an existing framework to make use of Saver.
• configuration meta-files
  Mention assorted information and related issues of general interest about the configuration meta-files that Saver generates.