I am trying to develop a methodology for building data driven forms at runtime. I have seen other posts on here regarding the pros and cons of various data driven schemes, performance issues, etc.

In my case I work with a VFP based Accounting package - Visual Accountmate - VAM. For the most part, VAM uses SCX based forms, with all of the objects loaded at design time. Other parts of VAM are more data driven. For example they have a data driven menu system and data driven lookups.

UPGRADES ISSUE
In the world of source available/modifiable Accounting systems one ongoing and horrendously difficult to manage issue is the 'problem of upgrades'. For example build 501 comes out on 1/1/01 502 on 6/01/01, etc. In the interim, forms, data, prgs, etc. have (possibly) all changed as a result of mods by the developer. If I modified an armCUST.scx in build 501, and VAM comes out with a new version of armcust.scx in 502, then I need to reintegrate my changes into build 502. If Accountmate did their changes, where possible, to dictionary entries, reintegration issues would be reduced.

People have talked about the benefits of subclassing, here, but I think that this is only minimally helpful - it is only part of the story - but please - show me where I am wrong on this - perhaps it is my lack of understanding of how to apply the concept effectively.


MODIFIABILITY BY END-USERS ISSUE
To the best of my knowledge, most of the major accounting software vendors profide some sort of facility for allowing end-users and/or developers to modify/customize the system forms without having full source, via some sort of hooks or toolkit - Accountmate is lagging behind in this area. I believe that many of them accomplish this by putting the object definitions in a table, and loading them at runtime. Elements in grids can be easily added or dropped - even other types of controls - can be added on the fly from a table. - but - it seems to me - in this scenario we lose a lot of the benefits of a visual design interface - with drag and drop etc - is there a compromise/combination approach? Also, I don't think it is possible to (fully) data drive the processing functions (please tell me I'm wrong - show me a methodology to data drive processing (other than the simple idea of putting code in memo fields - this would really be helpful to data drive this) I think it is more feasible, or at least easier, to data drive screen/data elements.

SUMMARY
The short of it is that I would like to come up with a formal methodology for data driving forms, for all my changes to Accountmate, and, perhaps even come up with a metadata table for existing scxs, which would allow me to a) better track version changes between Accountmate builds, and b)provide a facility for end-users to add, delete, edit data elements on forms and in a data dictionary and c)ideally, provide at least some limited facility for changing processing steps

Any and all suggestions would be greatly appreciated. Sorry for the long post!