VFPUtils Article By: M. Asherman

  | Bottom | Unframe | Help |

XFormDBF Development Tasks

Locate in Contents | (framed)

Locate in Discussion | (framed) 

Date Done
(not done)
fix minor bug in validation logic for mappings to NULL
(Alan reported this problem on 10/31/01.)  When the mapping expression is validated, a literal NULL result causes the following sort of error to occur:

XFormDBF error #112
Mapping expression is incompatible with field type.
Field: OWNERPLUS4, type: C requires expr type(s): CM, but mapping yields type: L

Further testing and analysis shows that similar problems would occur for any field type other than Logical.

To fix the problem, some additional logic in the XFormDBF.XFOM_ValidMapping method could force a literal NULL to be treated as being of the required type.  Doing this in a rigorously correct manner may a bit awkward, but not too difficult.  The trick is to precede the evaluation with a case statement that casts the local result variable into the desired data type.

This somewhat obscure bug is due to the subtleties of VFP's treatment of NULL values, which may or may not have a data type.  VFP's syntax has no literal representation of NULL that casts it into an explicit type.  However, the following simple expressions can be used to create explicitly typed NULL values:

  • val(null) -> NULL (Numeric)
  • substr(null,1) -> NULL (Character)

Presumably, with a little experimentation, one could construct other simple expressions to produce any desired type of NULL.  This workaround avoids the imperative need for any programming changes to fix this bug.  I.e., instead of specifying a literal NULL, you can simply substitute one of the above typed NULL expressions.  (XFormDBF Help documentation really should mention this unless/until the program logic fixed.)

(not done)
support direct editing of InitExp and CleanupExp via double-click
On the Options page of XFormDBF, let the textboxes for the initialization and cleanup expressions be editable by double-clicking, as previously done for the Template path.  Nadya requested this feature in her message of 3/1/01.

Also consider switching from textboxes to editboxes, for greater convenience in scrolling through long expressions.

(not done)
add an option to ignore numeric overflow errors
Introduce a new option indicating whether to treat numeric overflow errors during a Run as a special case.  This could be a per-configuration setting controlled by a checkbox on the Options page.  (If there are other such special error cases, they could be handled similarly.)

Nayda brought this up in her ErrHandler forum posting of 1/26/01, and I mentioned these further details in my reply:

Instead of causing the Run to stop, a "tracing" message would be issued (via ehm_showapperr) with information about the offending record. Presumably you'd also want to report a count of such non-fatal errors that occurred in the last run, and you would want this feature to be optional, possibly on a per-config basis. There's also the question of whether to consider the overall run a success or failure when this number is non-zero.

Nadya again mentioned (via email of 5/23/01) the need for defining "show-stopper" vs ignorable (but logged) errors in XFormDBF, i.e. Numeric Overflow cases.

(not done)
switch from listbox to grid-based mappings on the Fields page
Instead of a listbox, consider using a grid-based implementation to display output field mappings.  While the listbox is simpler, it has a number of limitations, and VFP's listboxes tend to break down somewhat unpredictably as the lists get large.  Grids are more robust and flexible, providing an easy way to get such useful enhancements as movable and resizable columns, imbedded controls, etc.  This would be helpful in implementing extensions like supporting field comments and other columns of additional information, which would otherwise be hard to squeeze into the page.

Another benefit of substituting a grid in place of a listbox is that it would make it easier to eliminate the bug causing "String too long" for mapping expr > 254 chars, which arises from an undocumented VFP Listbox limit.

(not done)
support optional comments for each output field mapping
Allow for an additional free-form text field associated with each row of mapping information on the Fields page.  If this were limited to a brief title or description, it could be squeezed it into the display of each row of the mapping array.  For longer notes and comments, a separate editbox and splitter could be provided, as is done for mapping expressions.  Nadya suggested this extension in her forum posting of 1/4/01.

Note that it would be helpful to switch to a grid-based implementation of the mapping display before attempting to add any more columns of information to the present listbox-based design.

(not done)
property for optional command to run on Unload event
Introduce a new property, xformdbf.xfop_unloadcmd, for specifying an optional application-dependent command line to execute in the Unload event method when the form terminates.  This would provide a notification mechanism for detecting the termination of modeless form invocations, in order to coordinate multiple concurrent sub-applications within a complex job control framework.  Note that the ifcmd( ) and docmd( ) utilities can be used assemble a single command line out of several VFP command lines conveniently, or you can use a any custom VFP UDF for more complicated actions.

This feature addresses Nancy's request of 10/31/00, and her email of 11/1 which included the following snippet of code from her modified version of the xformdbf.Unload event:

IF type('ojc')="O" and type('oJC.curAppStat')='C'
    IF NOT this.ehp_success


Instead of wiring this logic directly into XFormDBF, I would propose to create a small UDF, xfunload.prg, from the preceding IF statement, and adjust the logic to take an object reference argument to be used in place of "this".  The tie-in to XFormDBF would then be accomplished by assigning the command line "xfunload(this)" to property xformdbf.xfop_unloadcmd.

(not done)
bug causing "String too long" for mapping expr > 254 chars
Nadya reported this problem on 10/27/00.  My testing indicates that the exact limit on permissible length of mapping expressions is 254 chars, due to an undocumented VFP Listbox limit.  Adjusting the column width to truncate the column that displays the mapping expression doesn't avoid this error (VFP Error # 1903), which is a pity because that's the only easy fix.  If we really have to endure such a limit, the validation logic should be adjusted to catch these errors cleanly.  Otherwise, it will take some work to find a way around this display limit, because the listbox's RowSource is coming from an array used elsewhere in the program logic.  In the meantime, it will be necessary to work around this problem by constructing shorter mapping expressions and possibly introducing more concise UDFs in some cases.

In the long run, switching from listbox to grid-based mappings on the Fields page would give us more options for cleaner solutions to this problem.

(not done)
fix flaky behavior affecting grid column widths
As previously noted, there is an annoying change from the default column widths, which frequently occurs when you Restore the current configuration.  Nadya raised this issue again in her email to me of 9/6/00, where she made this specific suggestion:

In XformDBF.Xform_OpenOutPut try put this line:
* connect output table to its grid and listbox
thisform.pageframe1.PageFiles.grdOutput.recordsource = ''
thisform.pageframe1.PageFiles.grdOutput.recordsource = STDB_ALOUT

I.e., assign an empty string to the grid's recordsource property before assigning a non-empty value.  I'll have to give this a try to see if it works as a quick fix.  Nadya also suggested looking at her wgGrid.FormatAndSetCaption method, which I believe has to do with a different way of determining the default column widths.  I would view that as a separate problem, probably of less importance than the general ability to save and restore the user's grid arrangement, mentioned previously.

convert XFormDBF to the new Saver2 architecture
Make the necessary changes to XFormDBF in order to move it from the old Saver classes and forms to the new Saver2 facilities.  The new Saver2 architecture adds error handling and diagnostic features, as well as a cleaner, more robust implementation of state-saving and restoration.  This change will also require metafile conversion before attempting to use old configurations.  To convert an old metafile, open it and run the following VFP command line:

REPLACE cmdline with STRTRAN(STRTRAN(cmdline, "savrp_", "svp_"), "m.cmdr_arg1.parent", "m.cmdr_arg1") ALL

Preliminary conversion notes will serve as a guide to this change, and these notes will be further refined after going through the XFormDBF conversion.  A similar conversion will also be desirable for BTCrit, and the same notes should be helpful in doing that task.

deliver XFormDBF changes (#s 67 & 70) to BT server
Upload and test the latest XFormDBF programs on the BT server.  This update includes:

Note that these changes only affect xformdbf.app and xformdbf.chm (the Help file), which should also be updated in the mdacomm directory.  If you converted your configuration meta-files as directed for the previous update, you don't have to do it again.  If you still have old meta-files that pre-date those changes, you should perform the meta-file conversion I mentioned previously.

simplify editing of Template file specification
Make the Template output file specification on the Options page directly editable, by double-clicking, as was done for Input and Output paths on the Files page.  Also adjust logic for the Template pushbutton, which launches a GETFILE() dialog, to leave the old Template intact if the user escapes.  Previously, this logic would clear the template specification after an Escape from GETFILE(), because there was no other way to clear the template deliberately.  Now, you can clear the Template field by double-clicking to edit, so there's no need to perpetuate this annoying non-standard behavior.  Provide a NOWAIT warning message if the template file doesn't exist, but don't treat this as an error.  Also adjust the related XFormDBF Help as to this change.
(not done)
support optional SAFETY ON/OFF setting
As previously noted, and again raised by Nadya on 7/12/00, it would be nice to be able to turn off the prompt dialogs that occur when you use the Zap or Clone buttons.  This change only affects interactive modes, because the non-interactive RunC action automatically sets SAFETY OFF in all cases.  Non-interactive invocations of XFormDBF that don't clone, i.e. executed via the Run action, will append to an existing output file, not replace it, so the SAFETY setting is not an issue for these cases.  In other words, the ability to turn off the SAFETY setting is not a critical feature, but a minor convenience for experienced interactive users.

Rather than treat this as a fixed global option (which would be dangerous), I would make it an XFormDBF configuration option, controlled by checkbox on the Options page.
(not done)
support use of relative paths for file specifications
XFormDBF uses VFP's GETFILE( ) dialog to obtain the Input, Output, and Template file paths when the user clicks a pushbutton.  Unfortunately, GETFILE always returns a full (absolute) path, so this method of specifying a file doesn't allow entry of a relative path.  Nadya (and Nancy) mentioned relative paths as an urgent need on 7/11/00, and we've also noted this issue before.

For starters, we could introduce flag (True/False) property, xfop_relativepaths, that would cause the result obtained from GETFILE to be turned into a relative path by using VFP's SYS(2014) function.  A global default setting of this option could be made directly via XFormDBF's property sheet.  If greater flexibility is needed, this option could be controlled by a checkbox on the Options page.

Note, however, that support of directly editable file specifications would alleviate the need for this change, because it provides an alternative way of entering relative paths

A related issue that Nadya mentioned is the need for conversion of old configurations from absolute to relative paths.  This can be accomplished simply by executing something like the following VFP REPLACE command against each old metafile to be converted:

REPLACE cmdline WITH strtran(cmdline, 'D:\REDP\APPL\', '..\') FOR inlist(seq, 510, 600, 5120)

These sequence numbers correspond to XFormDBF's state restoration steps for the Input (510), Template (600), and Output (5120) file specifications.

directly editable Input and Output file text boxes
In her email of 6/26/00 Nadya suggested that users be allowed to edit the Input and Output file specifications on the Files page by double-clicking and typing directly into the areas used to display these paths.  This would often be more convenient that the present mechanism based on VFP's GETFILE() dialog, which has the annoying limitation that it does not support a default file specification.  Also note that this mechanism could provide a convenient way of entering relative paths, which is further addressed in a separate task (xfma0068).  Make adjustments to the Files page help information related to these changes.

Similar provisions should be made for editing the Template file specification on the Options page, but this is covered separately.
deliver XFormDBF changes (#s 63, 64, & 65) to BT server
Upload and test the latest XFormDBF programs on the BT server.  This update includes:

Note that these changes only affect xformdbf.app, which should also be updated in the mdacomm directory.  If you converted your configuration meta-files as directed for the last update, you don't have to do it again.  If you still have old meta-files that pre-date those changes, you should perform the meta-file conversion I mentioned previously.

fix spurious incompatibility msgs for placeholder mappings
In our conversation of 7/11/00 Nadya mentioned seeing numerous improper indications of incompatible mappings in messages displaying output field values.  I confirmed that this bug shows up for placeholder mapping cases, i.e. mappings for fields that don't exist in the current output table.  In such cases there should be no attempt to display the output field value at all.
display current/max record # in status bar for Files page grids
Follow Nadya's suggestion of using the grid's AfterRowColChange event to show the current record number (as well as reccount()) for both the input and output table grids on the Files page.  I made a similar change for the input grid on the Fields page, which also includes field attributes.  Don't include field attributes for status bar messages on the Files page, however, because this required disabling interactive column rearrangement, because of an apparent VFP bug.

I had previously contemplated adding fields to display this information on the form, but now I'm inclined to just use the status bar approach, which avoids over-crowding the form.
dynamic status bar message for input grid on the Fields page
Use the StatusBarText property to display additional information about the current input record and field attributes (field name, type, length, dec) for the grid on the Fields page.  I had hoped to display field attributes in an extra line of the grid's column headers, but this turns out to be difficult in VFP.  In our conversation of 7/11/00 Nadya suggested use of tooltips or status bar messages might be an acceptable alternative, and these could also be used to display the current record position.  The necessary logic can be put into the grid's AfterRowColChange event method.

I found it necessary to disable interactive column rearrangement for the input table grid on the Fields page, because of an apparent VFP 6.0 bug (at least under SP3 - not tested under SP4), where the grid's ActiveColumn fails to correctly account for reordering of columns.  I couldn't find any report of such a bug in my search of the Microsoft Knowledge Base, but here's a reference I found to another closely related bug: Q134251 - BUG Run-Time Changes to the Grid Not Saved Correctly.
(not done)
support automatic resizing behavior for XFormDBF
Currently XFormDBF uses a fixed size form, but actually much of the logic is already prepared to support automatic resizing.  This is a long-standing wish-list item that has become more important as the form has grown in complexity.  Nadya brought it up again in her email of 6/26/00, subsequently posted to the forum on 7/11.  Since this is a relatively easy task, I agree that it deserves a fairly high priority.
deliver latest XFormDBF changes to BT server
Upload and test the latest XFormDBF programs on the BT server.  These changes should be accompanied by updates to SplitCon and corresponding mdacomm changes.  This update includes:
update XFormDBF help to reflect recent interface changes
Help for the Fields and Options tabs should be adjusted to account for all changes since the last released version, which include the following:

Also adjust the Help Contents include file to add more bookmarks.  Rebuild the compiled HTML Help file (xformdbf.chm) to pick up all of the latest edits.

(not done)
support optional browse windows for input/output tables
I.e. use something like NOWAIT Browse windows, which the user can position and size independently of the main form.  (This task was previously mentioned under xfma0051, but I've broken it out as a separate task.)
(not done)
provide a convenient way to alter the template output structure
It would be handy if there were a pushbutton on the Options page for Creating/Modifying the template file structure, similar to the pushbutton for the output file on the Files page.

Since you can't do a Save As... from the VFP table designer, an additional button to handle the Save As function might also be useful, but treat this as a separate task.  This would make it easier to create a new template output structure derived from a previous one (which could be considered as the template template).

The subject of a Modify Template Structure pushbutton was previously mentioned as a low priority issue in the old XFormDBF task list (from Nancy's suggestion of 1/14/00), and Nadya brought it up again in email of 5/11/00.  Most recently, Nadya raised the issue again in her forum posting of 3/1/01, so this now seems to warrant a higher priority.

document how to support context-sensitive application help
Taking XFormDBF as an illustration, explain in detail how other applications can be adjusted to support "what's this" help in a similar way.  Nadya requested this in email of 4/28/00.  Also consider using the SplitCon demo form as a simple demonstration of supporting context-sensitive help.  (Since this is really a generic VFP/FrontPage task, let vmma0006 supersede this task description.)
(AP: 0)
set macro to use BT's default Lookup Table Maintenance function
There is a provision (described in help for the Lookup button) for assigning an absolute default command line to be invoked by the Lookup button by adjusting a macro variable.  This macro variable, XFDB_LOOKUP_DFLT, could be assigned to a preferred application-specific choice.

From Nadya's email of 4/10/00, I gather that BT's usage calls for something like the the following Lookup command line:

do ..\tablemaintenance\tablemaintenance with 'Manual','Lookups'

On 4/22 and 4/28 Nadya suggested setting the default to use of her TableMaintenance application.  (I would have to confirm the correctness of the above command line with Nadya before making this change in the xformdbf.h include file.)  However, the macro approach makes life easier only if this is a stable generic setting.  Otherwise, we may as well not rely on an absolute default, and instead use the more flexible global memory variable approach.

Alan originally assigned this task a high priority.  But in our subsequent discussion on 10/4/00, we agreed that it will suffice to use the recommended approach of assigning a value to global memory variable m.xfor_lkup, which avoids the need for any XFormDBF macro changes.

This topic came up again in email from Nancy of 5/31/01, to which I replied on 6/1.  Nadya agreed in her reply of 6/4 that this macro change should not be necessary.

(not done)
(AP: 3)
provide a way of selecting multiple records for Testing
On 4/22/00 Nadya suggested supporting a "multi-selected" grid on the Files page as a way of specifying a set of records to be tested as a group.

Another possible approach that might be simpler to implement and more powerful would be to support a way of setting a filter on the input table.  The Run command (not the Test button) would be used to accomplish this sort of multi-record test.
(not done)
(AP: 7)
optional inclusion of field attributes in column headers
In Nadya's emails of 3/3 and 4/22/00, she passed on this suggestion from Tanya.  More specifically, Tanya's idea was to display the field type and length in an extra column header line of the Input file grid on the Fields page.  The Input grid is currently on the Files page, so this also assumes we've dealt with the separate task of adding an Input grid on the Fields page.  Nadya suggested taking a look at her FormatGrid method, which might be helpful.

I've generalized Tanya's suggestion to allow for the possibility of supporting this feature on both the Input and the Output grids, regardless of where they reside on the form.  This might be implemented by introducing a new generic grid class that supports such a header option.  At the same time, this new grid class (or subclass) could also be used to address issues of default column sizing, as well as saving and restoration of the user's manual column adjustments, which are also useful generic features.  This would also address the old problem of flaky changes in column widths, which occurs upon state restoration.

After further investigation, I learned that it's not easy to create multi-line column headers in the current version of VFP 6.0.  Nadya suggested some possible solutions to this through downloadable utilities available on the Universal Thread, but this will require further research.  Also note the following MS KB article: Q133164 - HOWTO Define Multiple-Line Grid Headers.  In the meantime, I will take the simpler approach of using dynamic status bar messages to display additional input record/field information.
(not done)
(AP: 6)
improve highlighting of the current record(s)
Since the Test command uses the current input record, it would be helpful to have a clear indication of this record, and likewise for the current output record after running Test.  In Nadya's email of 3/3, she suggested row and field highlighting with the sort of technique I used in the Deduper application, based on dynamic foreground/background color properties.

Another possible approach, which might be easier to implement, would be to force VFP to maintain proper display of current record indicators, using some setfocus gimmickry along lines I developed in the TaxCalc application.  (See Q138913 - How to Activate and Use the Record Marker of a Grid, which says: "Use the SetFocus property to make the record marker of the grid refresh every time a record is moved.")

Also note the related task of displaying current record # and record count for both input and output files, which was mentioned previously and has been discussed on more than one occasion.  Instead of squeezing this information into an already crowded page, I accomplished a similar result by using the status bar prompt area.  My subsequent testing indicates that the grid's current record indicator and status bar messages are generally sufficient.

Nadya's message of 1/26/01 also suggests the possibility of using Nick Neklioudov's Grid Highlighter.  This would require further research.

(AP: 8)
support a single field Test operation
I introduced the new form method, XFOM_ShowOutFld, which displays the current output field value in a WAIT WINDOW NOWAIT message.  This is automatically triggered as you move around on the Fields page, if the new form property, XFOP_AutoFieldTest, is set to .T. (the default).  I also added a toggle for this property on the Options page, plus corresponding state-saving logic in class SaverXFormDBF.

Based on my conversation with Alan on 5/26/00, I didn't bother with an explicit field-level Test button, and there is no actual modification made to the output file for this operation; it just displays the evaluated mapping value.

Nadya's emails of 3/3 and 4/22/00 also mention the idea of highlighting the currently selected field in a grid added to the Fields page.  This is not necessary, since the listbox already gives an indication of the current output field.
(AP: 8)


allow input data to be seen from the Fields page
Add a resizable Input grid and another splitter on the Fields page.  Nadya requested something along these lines in her email of 3/3 and 4/22/00.  This depends on some related SplitCon changes, which have been made.  Note that the following VFP command line should be used to convert any old configuration meta-files before using them with the updated version of XFormDBF, in order to avoid error messages upon state restoration:

DELETE FOR 'Splitcon_2_1' $ cmdline

Also see these related tasks:

(not done)
(AP: 5)
provide various quick reports tied into XFormDBF
For example, there should be reports to summarize the configurations, display mappings, file structures, etc.  These might be implemented by making use of the Reporter facility, as suggested in earlier notes.  Custom queries and report definitions could be used to extract data from the XFormDBF meta-file of configuration information.  User-specified scope parameters could be handled via parameterized queries, new fields in the Options page, or by introducing some new custom dialogs.  Certain simple types of reports could also be produced without resorting to a full-blown Reporter-based approach.

As a specific example, in her email of 4/22/00 Nadya asked for the ability to print mappings expression one or all FunctionIDs.

In Nadya's forum posting of 1/4/01 she suggested providing a Print capability for each page of the form, e.g. for the output structure and mapping information on the Fields page.  Limiting the report to the current configuration would be a reasonable simplification to consider as a starting point.

(not done)
(AP: 6)
investigate ways to further speed up large transformations
Alan said (on 4/17/00) that Harold's old transformation logic is about twice as fast as XFormDBF on certain large jobs (about 75K records).  Get a test case for benchmarking and analysis, to determine the most promising avenue of optimization.  Recall previous notes about potential further optimizations.  Also note Nadya's suggestion of 9/7/00 regarding possible use of VFP's SCATTER/GATHER commands.

I did a bunch of further testing and standalone benchmarking during April, 2001, which indicated that the most serious performance problems on the BT system were attributable to the networked setup for the sample configurations we analyzed at the time.  It should be noted that XFormDBF performance may be greatly enhanced by running against local input, output, lookup, and configuration files.

In her email of 6/27/01, Nadya also mentioned this, which will require further clarification:

"XFormDBF slowness during Conversion job. XFormDBF was mostly tested in Extracts job, where it performs with reasonable speed. Tanya has several complaints regarding GUI and performance of XForm in Parcel Conversion job. She needs to describe all problems in the appropriate Forum http://www.ideaxchg.com/ix08/d1/0000004a.htm ..."

browser compatibility problem for #bottom links
Look into problems with links to Bottom of page that showed up in testing with a version of MSIE (on MDA/AST) older than 5.0.  One possible explanation is that this is related to use of FP include files.  Another possibility is that the bookmark is placed at end of page.  Try to fix this to work with any browser.

I've marked this task as done (as far as the XFormDBF forum is concerned), since it really is a generic IdeaXchg issue now filed under ixma0040: look into possible browser compatibility issues for #botttom links.
consider creating separate form for Reply (as opposed to Post)
Note that Top/Bottom links on the Posting page should not be used in the Reply context, because they cause the default connection to be lost (the default Subject line disappears).  The main reason for a separate form is that we don't want to hassle the user with entry of a required Category in replies, but we do want to require one or more category assignments for top-level postings.  Experimentation will be required to be sure that this is doable.

My conclusion after global refinements to Posting pages is that it's not worth the complication of introducing a separate Reply page.  Let use of Keywords always be optional, but supply a default that identifies the forum.
try to reduce edited content stored in the discussion subweb
We should investigate the possibility of moving the discussion Search and/or Posting pages out of ix08 and into the ix07 subweb, for easier editing of information directly included on these pages (e.g. categories and keywords).  In general, one should try to put as little editable content as possible into a discussion subweb, for maintainability.  This minimizes bi-directional FrontPage publishing complications, which can clobber the discussion component.  Further experiments will be required to determine if these pages can be moved.  If not, maybe the best solution would be to keep variable information out of these pages, e.g. by linking to such info on separate pages residing in the editable VFPUtils subweb or the main public IdeaXchg web.

As of the creation of the new IdeaXchg forum templates, I don't think it's worth any further attempts to reduce edited content in discussion subwebs.  The present state of things only leaves the Keywords of the Posting page and a few boilerplate include files that would occasionally require editing, but direct editing on the live web server is not a big deal.
refinements to the XFormDBF discussion Posting page
The Posting page for the the XFormDBF discussion area currently has only a bare submission form, but no help or inline explanation; both should eventually be supplied.  The more immediate issue, however, is that the categories list box needs to have real category choices, not the dummy category codes currently provided for demonstration purposes.  (Also see refinements to categorization of tasks, try to reduce edited content stored in the discussion subweb, and try creating separate form for Reply (as opposed to Post) for related issues.)

The global IdeaXchg cleanups to forum Posting pages and subsequent pass at consistent keywords in posting forms covered the most important cleanups to the list box, which has been renamed from "Categories" to "Keywords".
refinements to the XFormDBF discussion Search page
(This task is a subtask vmma0011, but there's no need to track it separately.)
(not done)
(AP: 3)
add configurable Funcs button to the Fields page of xformdbf.scx
Use exactly the same approach as what I did for the Lookup button, except that the Funcs button should be placed on the fields page.  By configuring the Funcs button to launch a NOWAIT Browse against a table of canned function definitions, we are providing a rudimentary function library facility.  Further refinements can be made as it becomes clear where they are needed.

After my conversation of 6/23/00 with Alan, I tentatively upped the priority of this task, although Alan's previous posting had assigned a lower priority.  Alan had assigned a higher priority to another task relating to the Lookup button (on the main form), which should not be confused with the new Funcs button that will go on the Fields page.  Discuss this again with Alan for further clarification.

Based on further discussions with Nadya on 8/23, this task no longer appears to be important, because she can easily incorporate "function library" features within her Table Lookups facility without any further complications to XFormDBF.

add a configurable Lookup pushbutton to xformdbf.scx
This supports a tie-in to an application-specific utility command, with a limited degree of flexibility.  The internal details of the utility function connected to this button are not be known to xformdbf.  The new Lookup button may as well go on the main form body.  It is disabled by default, but supply "Whats This" help to explain the steps required for configuring the command line to execute when this button is clicked.

This is a quick, functional solution to the problem of providing a convenient connection to lookup table maintenance from xformdbf, without detracting from xformdbf's modular, generic design.
include file for blurb about reloading threads page
Introduce global include file for the blurb about refresh at bottom of Threads pages (framed and unframed flavors).  May as well also take a stab at a generic "reload this page" link, although I'm not yet sure it will work.  Testing reveals that my attempt to handle "reload this page" by going to # in target _self doesn't work, so eliminate this experimental link.
further refinements to page header/footer conventions
Let all page footers begin with link to VFPUtils home page.  Remove all such links from page headers, except for the case of articles, since these are not necessarily tied to a single topical forum, and space permits.  Keep page headers simple and concise, esp. in case of viewing in a small HH window.  Remove link to Discuss in HH page headers, since we have another such link in the bottom navbar; revise label from "Discuss" to "Discussion", since space permits and this is a little clearer.
omit IP addresses from Threads TOC page
This requires a change to the posting page for the XFormDBF discussion.  Keep lines compact, for viewing in a typical small HTML Help window.  Also should adjust old tocproto.htm entries manually to drop IP addresses.  Test this out against new postings.
make Discuss links from HH pages point into Threads
Instead of linking to placeholder messages, link to the bookmark for the placeholder message within the unframed Threads TOC page, which is generally more convenient and familiar.  We may want to carry this convention over to discussion links for other types of pages, but this is especially appropriate for HH help pages, which are primarily meant to be viewed in an unframed HTML Help window.
confirmation message should display all fields picked up
The current confirmation page only displays the Subject line.  It would be a good policy to always display everything that goes into the posting, for easier confirmation and logging of submissions.

This task was covered in global IdeaXchg cleanups to posting Confirmation forms
reorganize ix08 discussion folders for better modularity
Along the same lines as reorganization of ix07/xf stuff, let the the hidden folder be a subfolder of its corresponding visible folder.  This allows the whole discussion area to be more self-contained and treatable as a unit, which should make it easier to clone and adapt as a template for new discussion areas.  Start by moving and renaming ix08/_d1 to ix08/d1/_sys.  Also delete page counter residue under _private.  Adjust ix07 links to pages that have been moved.

Also take this opportunity to rename ix08/_ixincl to ix08/_global, for more consistent generic conventions, and rename ...ixfooter.htm to pgfooter.htm, again for consistency with ix07. May as well delete the copy of placehld.htm in ix07/_global, because this isn't actually used (only the one in ix08 is used).
make another pass over the VFPUtils home page
Clean up the VFPUtils Home page from its current preliminary form to be more presentable.  Sketch out how this web will incorporate additional related forums, i.e. content and discussion areas, e.g. for Saver, Reporter, Querier, ErrHandler, Commander, Splitcon, Misc. Utils., etc.  For starters, supply at least a brief blurb about each of these areas.
freeze old xformdbf.txt and convert into a web page
As a preliminary step toward assimilating old tasks into the new web organization.  Created a new HTML article containing the old XFormDBF notes from the old xformdbf.txt file of 3/18/00.  Also created entry in the Contents include file, plus a corresponding placeholder discussion message.
more info on syntax of HMTL Help Alias (.ALI) files
One question is how to specify either a relative or absolute path, as opposed to no path at all.  Also find out whether alias to a bookmark within a page is allowed.  So far, the only form I've been able to use is a simple "foo.htm" type of reference, without a path.  This imposes an undesirable restriction against separating content pages from HH project cruft, which I'd rather keep hidden and physically separate.

My testing indicates that relative paths into the parent directory don't work when used to define the HH API Alias information for support contextids.  Other examples in MS documents indicate that relative paths work in general, but they don't make it clear if this is supposed to work with "..\" types of relative paths.  It doesn't.

I found these references helpful, although none really answered my exact questions:
refinements to page header/footer conventions
Review appearance of pages when viewed in a fairly small window, as would be the case through HTML Help.  Tweak for conciseness, consistency, and clarity.  Eliminate the link to VFPUtils in message header, to make it more compact and reduce confusion.  Instead, use a standard "logo-style" link to the main XFormDBF Contents frameset in the header.  Put link to VFPUtils home page and mention of SpaceTime into page footers.  Distinguish various subsets of pages by using the following flavors of headers:
  • XFormDBF Forum
    for TOC pages and system pages in ix07, the edited portion of the VFPUtils web.
  • XFormDBF Help
    for pages included into the HTML Help file, also in ix07.
  • XFormDBF Discussion
    for messages, Threads TOC, and discussion-specific system Search/Post/Confirmation pages.
use a conventional "article" treatment for the tasklist table
I.e. just treat the table of detailed task descriptions (this page) as another standard article, with a conventional header, navigation bars, footer, connections to discussion, etc.  This avoids the complication of needless asymmetry.  Compare with earlier template article layout used in old IdeaXchg articles. Try using a custom 2-line navigation bar along the same lines as the one in the placeholder message layout.

Also rename and move this tasklist (table) page, establishing a reasonable convention for naming and placement of articles in general.  Keep articles under modular, author-specific folders.  Use serialized, stable file names, with HTML title that matches the title in the page's header.
TOC section of topics for articles not covered elsewhere
Assuming we go ahead with the new compound TOC model, we'll need to add a subsection for other headings and subheadings not covered by either the Tasks section(s) or the HTML Help Contents section.  Actually, the initial section of the top-level Contents include file can be used for this purpose for starters, until the size of the initial list of entries grows to the point where we need to introduce a separate subsection.  Deal with this issue gradually, as the content is expanded.
new compound model of the main Contents TOC page
Instead of depending on multiple separate TOC frames and shell pages, let the primary Contents TOC page be comprised of multiple sections, or an include file of include files.  The separate sub-include files would maintain modularity, but a single combined TOC page would simplify the web interface and overall design.  We could still allow for the support of entirely separate TOC frames, but this needn't be done unless the further complication is warranted.  This change requires that we also adjust various navigation bars, etc. to eliminate the obsolete Tasks frameset, etc.
assign more sample contextids, including individual controls
Test out VFP's automatic context determination behavior when some individual controls are assigned contextids, and other controls are left unassigned (defaulting to 0).  Addition of new contextids in VFP form member property settings should follow the creation of associated HH content pages, and their inclusion in the HH TOC, the corresponding web TOC include file, and the HH API include files.  Confirmed that What's This help works for the new Lookup button even when it's disabled, which illustrates a case where F1 Help would not have been usable.
placeholder discussion messages in ix08 for xformdbf HH pages
Create placeholder messages, along the lines of previous templates in public ideaxchg subwebs.  Links on HH pages should be set to point to their corresponding placeholder discussion messages in ix08, using absolute web URLs.  Take this opportunity to adjust titles of help pages to follow a reasonable, consistent convention.  This requires changes in page headers, page title tags, help contents TOC include file, and HH TOC.  Placeholder postings should have titles of the form Re: <page title>.
conventions for HH page headers, footers, etc.
Orientation for these pages should be slanted toward their use within an HTML Help file; web-based viewing of these pages is secondary.  Also include tie-ins to placeholder messages in ix08.  Use absolute web URLs for links to placeholder discussion messages and any other parts that should not be pulled into the compiled HTML Help file.  Include a link to the XFormDBF Contents frameset in both header and footer.
improvements to organization of the outline of tasks
Make further refinements to the forum Contents organization, which now lists only outstanding task titles ordered by priority, followed by a list of completed task titles, ordered by date done.

Let this task be superseded by the revised definition of xfma0020: refinements to categorization of tasks.  Also see vmma0008: show date done for each entry in the outline of completed tasks.  (Generic task management issues really belong in the VFPUtils Misc or IdeaXchg task lists.)

further testing and cleanups of context-sensitive help support
Still need to test out xformdbf's non-interactive mode and operation in a pure VFP runtime environment.  Also remember to disable diagnostic tracing in Activate and Deactivate event methods.
clean up and fill out related generic ideaxchg web content
(This task is superseded by vmma0012, since it's really a general IdeaXchg/ VFPUtils issue.)
test out FrontPage's Search behavior on "hidden" sub-folders
See if the suppression of indexing for folders whose names begin with underscore carries over to sub-folders as well as top-level folders within a web.  If this feature works on sub-folders, we could take advantage of it to improve the modularity of the VFPUtils web organization.  This also bears on the best way to move HTML Help project files into the ix07 web.  Testing indicates that suppression of indexing does indeed work for nested subfolders, and nothing gets indexed in the subtree of a hidden folder regardless of depth.
VFPUtils main Search page
(This task is superseded by vmma0010, since it's really a general IdeaXchg/VFPUtils issue.)
(not done)
refinements to categorization of tasks
Some form of topical breakdown will become more important as the task list grows.  Although it's really a more general problem (see vmma0007), XFormDBF is one of the first places where this issue is likely to come up.  After working out some generic conventions, apply those conventions to the XFormDBF task list.
support metafile representation of the help file hierarchy
(This task is superseded by vmma0009, since it's really a general VFP Help issue.)
create additional xformdbf help content
Fill out the end-user help with more pages, context ids, TOC entries, etc.  Addition of new HH content pages should be accompanied by creation of corresponding placeholder discussion messages, adjustments to the HH TOC, the corresponding web TOC include file, and HH API include files, then recompiling the HTML Help file, followed by adding support for new WhatsThis help context ids in the VFP programs.

New pages include: XFormDBF Help - Main Form, Options Page, Config Page, Program Invocation, Error Handling, Related Facilities, Mapping Editbox.  Work new pages into the HH Contents include file, but hold off on other details until all new pages are ready, at least in preliminary form.  Then make other structural adjustments for these pages en masse, to speed up the process.  Add TOC entries for major bookmarks within pages where appropriate.  (Note that the contents outline can intermix links to pages with links to bookmarks within pages.)

Also add a link to the HH TOC page at the top of each HH content page, to make these pages more navigable when viewed without HTML Help or a frameset.
add direct links between public ideaxchg and private vfputils
Make it easy to go back and forth between these sections, as a convenience to the users of the private web.  Links on the respective home pages would help, for starters.
review and experiment with VFP's "what's this" help
See if this can be easily supported, as an extension to basic F1 help features initially implemented.  Testing and documentation indicate that WhatsThisHelp is an alternative mode of help that takes over the F1 key, i.e. HelpContextId is superseded by WhatsThisHelpId when WhatsThisHelp is enabled.  It's a bit more of a pain to set up WhatsThisHelpId settings, because the default of -1 is not as useful as 0 would be.  For normal F1 help, the default behavior when HelpContextId = 0 is to search upward through the object's hierarchy for the first object with a positive WhatsThisHelpID property value.

Although it takes more effort to set up default contextids for WhatsThisHelp, this seems to be the more versatile approach, with more end-user convenience.  Eventually we could support an option to toggle the WhatsThisButton's presence on or off..  (This can be accomplished indirectly by turning the MinButton and/or MaxButton properties on or off.)
move HTML Help project files into local VFPUtils web
Put the HH project files directly into the ix07 subweb instead of locating these under my VFP development directory.  A benefit would be that paths to included help pages become much more direct, avoiding the need for long absolute file paths.  More importantly, avoiding absolute paths turned out to be necessary in order to get context-sensitive VFP Help working.  A possible drawback would be if FrontPage were to get screwed up by direct editing via HTML Help Workshop within its web space, which is possible. But I suspect that the damage would be pretty limited, and Recalculate Hyperlinks should take care of it (I hope).  Try using ix07/xf/_hh/ as the folder for HH project files.  We'll also need to test that such an arrangement conceals this stuff from FrontPage's Search component.

I was able to get this working, but it required that the xformdbf.hhp be placed in the same folder as the HH content pages, in order to avoid problems with use of upward relative paths in the HH API Alias definitions.  Other HH project files reside in the hidden _hh subfolder, which seems to work ok.
fix HTML help to support auto-synchronization with TOC
Normally this HH feature should work, but it doesn't seem to resynchronize as I would have expected, e.g. when I follow a link in the default page.  I thought maybe the intermixing of absolute and relative paths was causing it not to recognize their equivalence, but switching to use of relative paths (in connection with xfma0013) still didn't fix it.  I fixed the problem by turning on the required checkbox under the Navigation tab - oops.  This didn't seem to fix it right away, but it finally started to work in the course of moving the HH project files into the ix07 subweb.
supply context ids in xformdbf's HTML Help file
Compare with how this was done in MDA110/Montage.  Create xfhelp.h/ali files for inclusion in the [MAP] and [ALIAS] sections of the .hhp (project) file.  Recall the suggestion of using the prefix IDH_ for symbolic names, to get additional automatic HTML Help validation features.  HH documentation also seems to indicate that I should use the .H extension (not .HH, as done in the VFP Solutions Help example).  Maybe .HH is for an older version?  Documentation is confusing and incomplete on this point.  Ran into problems with use of absolute paths in the .ali file, so I copied the required pages in the local xformdbf\hh\ project directory and adjusted .hhp to use these instead of direct refs to local web server pages.  This was just a temporary measure, to verify that context-sensitive HTML Help support could be made to work in xformdbf.  The next step will be to adjust the directory organization by moving the HH project files into the local ix07 subweb, so that I can avoid the need for this temporary redundancy.
create xformdbf contents page for html help
Use the contents include file to generate another flavor of Help Contents page, which would be used as the top-level, default page for building the compiled HTML Help file.  This will allow HTML Help Workshop to pick up all of the required help pages, without any need to list the pages explicitly.  It also provides a convenient way of navigating the help, and this convention can be carried over to other modules.
reorganize xf-related folders for better modularity
Try moving and renaming the hidden ix07/_xf folder into a subfolder of the main xf folder, ix07/xf/_sys, to keep all xf-related stuff under a single subtree.  We may as well use a more generic name for the hidden subdir, for better clone-ability.  Manually delete obsolete page counter residue under _private (which FP should have done automatically, but it misses this).  Adjusted navigational links in ix08 for these changes; this was made pretty convenient by using FP's Reports view of ix08, which provides a way of changing all links to a given broken URL in a single step.  I've already confirmed that FP2000's Search conceals sub-directories whose names start with underscore (not just top-level folders).
populate main Contents include file with outline of user help pages
Let this web-based outline correspond directly to the HTML Help Table of Contents outline.  Note that the web-based VFPUtils organization allows us to have additional "tables of contents", i.e. pages usable in the upper frame.
create a few preliminary xformdbf help pages (HTML)
Supply a main intro/overview page, and tab-specific pages, to test out context-sensitivity.  Just start with preliminary placeholder pages in the xf folder for initial testing purposes.  Introduce preliminary header and footer include files for these pages.  Use file naming convention with distinctive prefix ("xfhlp") and stable, compact file names (3 digit sequence # follows prefix).
set up VFPUtils discussion subweb in ix08
And connect this to navigation bars, etc. in ix07.  Use the previously developed Test Discussion under ix01 as a starting point.  Adjust headers, footers, links, page title, etc. as necessary.
(not done)
assimilate old xformdbf.txt task list into this web page
I froze the old ASCII text documentation file, because I've shifted to use of this web-based approach.  See the HTML version of the old XFormDBF documentation for a slightly more convenient reference.  There are a lot of assorted VFP programming task descriptions in the old file, and these should be reviewed and entered into this table.  The tricky part will be to work out the best way of further breaking down the outline of task categories.  Also consider the possibility of filing tasks under multiple headings; this might be made more manageable by flagging each task "record" with one or more category keys.
support context-sensitive HTML Help in xformdbf
This must follow creating preliminary compiled HTML Help file for xformdbf, and supplying context ids in xformdbf's HTML Help file.  Focus on basic support of F1 help for starters.  Note the complication that we want to support both VFP runtime and development environments, as well as stand-alone vs integrated into a larger application (Job Control).  Also should support modal/modeless and interactive/non-interactive cases properly.  Assign context ids (1 - 3) to the form, Files page, and Fields page.  Added logic to form Activate, Deactivate, and Destroy event methods, plus new xfom_helprevert method.  Added some xfop_help... properties to support restoration of prior VFP Help environment settings.  Note that xformdbf Help support can be disabled by setting the form property xfop_help to an empty value.  Tested logic for clean handling of missing help file (xformdbf.chm).
create preliminary compiled HTML Help file for xformdbf
Create HTML Help project (.hhp) using direct references to pages residing on my local web server, to minimize redundancy and simplify maintenance.  Also supply an HTML Help table of contents file, corresponding closely to the ix07's Contents TOC include file.  From these files generate a compiled HTML Help (.chm) file, to be kept with xformdbf.app.
include link to Tasks on primary navigation bars
We should have top navbar links to Contents, Tasks, and Threads flavors of TOCs.
add tie-in to Test Discussion on the VFPUtils home page
new HTML-based task management for xformdbf
Create outline of tasks in upper frame TOC page, with links into a bookmarked table of brief task descriptions below (i.e., this page).
preliminary setup of ix07 subweb for edited content of VFPUtils
Clone and adapt preliminary work on public Test Discussion, from the _d1 (=> _xf) and _ix (=> _global) folders of the main ideaxchg web.

| Top | Unframe |


Copyright 2000- 2002, SpaceTime Systems