>>>What is the difference between putting code in a form and having the code in a prg as far as OOP is concerned? I thought it would be the same.
>>
>>The biggest difference comes into play if you try to use forms with private datasessions. If you create any objects in your .PRG before you call your PD form, those objects will be in a different datasession from the form and can't "see" the tables in use by your form. It all boils down to OOP concepts, which from your descriptions of problems with forms sounds like you need a better understanding of that before you can really continue and design things properly.
>
>Fred,
>thanks for the input. I think we have your points covered but tell me what you think. We do use private data sessions. The form, running a private data session, is run at the very top of the prg. Any incoming parameters are passed to the form and put into form properties. The form init calls a procedure that creates any needed cursors. Any action the user takes is run in procedures within the prg. Starting the form from the prg makes all the procedures in the prg available to the form. The downside, I now realize, is it will not run modeless forms.
>
>I realize this may sound odd to some but we have tried both ways for some time and found this method to be by far the easiest to maintain. The larger of the two systems we sell has 265 forms, 237 prgs and 245 frx reports. (I just counted them.) Ease of maintaining this has to be second only to the user experience.

The OOP way to do this was as Tamar briefly explained. Create form classes that have the code you need in them as methods to the form class and build up your hierarchy of forms based on that. The code still only lives in one place, even if you have 200+ forms.

>
>Most of this system was converted from FoxPro 2.6 DOS about 6 years ago and we are now in the process of converting all the scans, set filters and seeks to SQL. Data input / output is being converted to a separate prg for each operation which returns cursors for each operation. Once the system is converted we can then take the SQL prgs, held in a separate folder, and simply :) convert them to a SQL back end. This is a Lot of work but we are working with a successful 15 year old product.

Having gone that same route (FPD to VFP) myself many years ago, all I can say is that the path you're on is a path to ruin. <g> Learn OOP procedures and don't look back, you'll truly be glad you did. It may take awhile to "click" in your head, but once it does, you'll be so much better off.