>>>
>>>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.
>>>
>>
>>I see no reason having the code in PRG rather than a form would reduce EXE size, unless you mean that many forms call the same PRGs. If that's the case, then OOP is exactly what you need.
>>
>>You put all that common code into a form class, and base all your forms on that class. The code is there only once, in the class definition, but all the forms have access to it, and those that need to extend it can do so.
>>
>>For example, in one application I'm working on, one of the criteria is that users have to be able to print out the forms exactly as they look on screen. So I have a method in the base form class for that app that prints out the form. Every form I base on that class can use that method.
>>
>>As for the maintenance issue, that's a matter of personal taste. I love the fact that I can open several methods at once and work on them in parallel when I need to. In a PRG, I have to flip back and forth between them.
>>
>>Tamar
>
>
>(Note: I hope no one takes these comments wrong. I really appreciate all the input and it is very valuable to me. I am just trying to explain why we do things this way.)
>
>It looks like I didn't explain things clearly. We do use OOP extensively. We just don't put code in the forms. All forms are based on a single form class that does contain common code. Each control in every form - text box, label, grid etc. is based on a single base control. Some are sub-classed further as needed.
>
>For example, in order to allow resizing of our forms, now that we have moved to VFP 9, all we need to do is set the anchor property for each of the base controls and put some resizing code in the base form. I already did it and it works great for 99% of the system. The holdup on that is that the current font is MS Sans Surf and it does not scale well. We need to change to Arial and that means going through over 200 forms to re-align the lables. Still not very hard to do, just time consuming and something that has to be done entirely at the same time.
>
>The program associated with each form only handles code needed exclusively by that form. This code calls common code in the procedure files. Thus, in most cases, these programs are small. In we have two large procedure files; one containing our 'Base Library of procedures' and the other containing common procedures for the product. These two combined have about 9,000 lines of code in 60+ procedures. I can't even imagine trying to deal with that much code in that many methods in one container.
>
>As for the size of the exe. The method source code stays with the form when it is compiled unless debug is off. Without debug you cannot get the line number of the error and without that we cannot quickly fix errors. Yes, some people have a procedure that strips the code out but that is a pain and God help us if it was run on the wrong copy.
>
>One last comment. The reason we like prgs is that we still use Brief. No other editor comes close. I can set 10 jump points in 10 different programs and jump to any one instantly. I can do column cut and past which is wonderful working with arrays. I can be in a very large prg and can mark and beautify 12 lines of code in the middle instantly. And if I really need Intellisense I can always build some code in the form.

All of that jump points etc is IMO just work arounds to trying to deal with discrete components grouped into a single file.