Update: I just noticed you are located in North Carolina. Out here, we don't have a user group less than 2 hours away but I understand there is an excellent one in Asheville. You should consider checking it out and visiting (if you haven't already).. Also, being in Raleigh, NC TakeNote is pretty close! I took their training with some co-workers when I worked for the the government and it was excellent. (I had focused on networking for some years since programming in Foxpro and needed refresher training and my co-workers had never used VFP.) I kept the handouts. Jim Duffy and John Peterson conducted the training. They did the training on site for us and it was more beneficial than I could ever say :o)

We recently did this inhouse. We converted 425 screens to vfp forms in 3 months. Once you do around 10 of them, you can do them pretty easily. I have my own personal preferences now:

1. As Tom and others mentioned, USE A FRAMEWORK if at all possible before you start. Follow the framework's tutorial or startup guide and create at aleast one working test application using the framework. (From the uppercase you can tell that I feel strongly about this one. I've worked with and without frameworks and I will always choose to work with one if an option).

2. If you use the framework, you are probably going to have get your backend in order first and then create your forms using the framework. The code in screens and prgs can be moved to prgs into procedures and functions and in most cases used as is.

3. If you do not use a framework, you can convert your screens but you will still have to modify them and before you do that you should be familiar with creating forms and using them in VfP. That's why I recommend running any tutorial or example app you can find first.

4. If you do not use a framework, at least create your own base form class to use (and hopefully some controls too) so that you can consolidate common settings for the future. you will not regret it even if you initially do not make any changes to the class when you first create and use it.

Converting screens:

Even if I create the screens from scratch, I still do a conversion so I can cut and paste the objects onto a new blank form or at least easily cut and past method code etc. The conversion creates a formset and you want a single form for the objects.

If you do a functional conversion, cut and paste the controls onto your new blank form. The functional conversion will bring over the valid events and formats from the dos screen but also defaults to some settings for you will have to change:

You will need to verify/modify the properties of all controls, but some common changes I made manually are:

colorsource - 3 - Default Scheme to 4 - Windows Colors
special effect - 1 - Plain to 0 - 3D
valid event - rewrite to a working lostfocus event

Some settings you won't need to change if you cut and paste controls onto your new form or create them from scratch on your blank form:

formset window type - 2 - read to 0 -modeless or 1 - modal
autorelease .t. to .f.

The setup and cleanup code is moved to the formset's load and unload event. You will need to review the code and put it in its appropriate location. For a fast conversion, you can typically move the code vfp put in the load event to a prg that calls the form. For the unload event it can be placed in the same prg after the form closes. You can remove the readborder and compatible settings placed there by the converter. Ideally, all code in the screen's setup and cleanup method would be rewritten to work from the new form's methods - the load, init, and release or unload, etc. The fastest conversion though is to move it all to before and after the form is called in a new prg you create. Then in your app to run the form, run the prg and it should run fine. conversions require very thorough testing.

The visual conversion makes the form more visually representative of your dos screen but you will still have to cut and paste the controls to get rid of the formset and place the controls on your new blank form created based on your class (mentioned above). All of the code (including methods of each individual control) are placed in the single prg you specified during the conversion process. You will then have to go back to that prg and grab the code and put it in the appropriate place in the form or one of the properties of a control on the form.

This is why I recommend you create a few test apps in vfp first using either the tutorial for the framework you choose or the vfp sample. Personally, I recommend classes from TakeNote Technologies, you can purchase their handouts separately if you want to learn on your own or go to a comparable training site and either get training or study on your own and create a couple of practice apps.

It is all personal preference and you will probably wish you had done it differently when you are finished regardless of which method you choose.


Just my personal experience.

Good luck and have fun!

Tracy



>Here's a quick question ... looking for overview / rule of thumb only.
>
>Looking to convert a 2.x Foxpro to latest version. I will have to learn my way into the curve, so to speak.
>
>Is there any rule of thumb for the time it will take me to:
>
>1 - get familiar enough with VFP to make the basic app run? (Based on your own experience).
>
>2 - average time for converting the average 'screen to form', so to speak?
>
>Just as a general rule. We've been off doing other work, as it were, but now have several clients finally wanting to / agreeing to upgrade the 2.6 apps.
>
>Any reference sources?