>>I would like to raise a general strategy question for which a bit of background is required....
>>
>>Several years ago, I developed an application which calculates financial indexes. The client was under great time pressure, and the strategy I developed was to build a calculation engine in FoxPro (version 2.0 at the time), while the client's staff built the index histories. I taught the staff the basics of FoxPro, and they were able to set up the tables we would need when the indexes went into daily production. In the years this project has been running, several
>>
>>staff members have become very competent FoxPro programmers, and most of the staff can use FoxPro for data checking and creating ad hoc reports.
>>
>>After much discussion, the client has decided to upgrade to VFP. I will rewite my apps in VFP 5, and among other things, we are looking forward to the added precision and the savings in disk space that we will realize by using floating point DOUBLE fields in our DBFs.
>>
>>While I appreciate the additional capabilities available to the developer in VFP, my problem is that the client has a staff which still needs to be able to build tables, set relations, browse, validate data, and perform many maintenance tasks. VFP can still do all these things (very well!), but the interface and documentation are no longer supportive of the beginning user. (The 'Database' menu and the 'Sort...' dialog box were very useful to my users.)
>>
>>I have found there to be great synergy in having a language and table structure that could be used ***both*** to build powerful applications and by less experienced users who need to manipulate large amounts of data quickly. Converting the tables to another software package is not the answer.
>>
>>One possible solution that I can see is a beginner's "front end" to VFP. Has anyone tried to build such a thing? Does one exist already? To me, the ideal front end would be menu driven and have a command window. It would let new users do 'useful work' in VFP up through the stage where they could write simple programs. After that, if they have the interest and/or their job required it, they could move to the VFP developers' interface.
>>
>>I am most curious to know what others of you are doing to deal with this problem. Thanx.
>>
>>Steve
>
>IMHO, you should encourage the users to learn how to use VFP. The best way would be to have them get used to the VFP environment while using one or two menus that you write which are nothing more than glorified macros. It would be kind of like a 'Switch Kit'. Create menus with commands/Text similar in appearance to 2.6 and have the users get used to VFP that way.
>
>Does that make sense? If it doesn't I'd be happy to elaborate.

Matt,

Could you elaborate, please. Are you suggesting that the 'Switch Kit' menus place the text of the command on the screen, or am I missing something?

I agree completely that the ultimate goal is to get the users comfortable with VFP since this is the environment in which they need to work.

Thx,

Steve