>>Yes, but since I don't like procedure files being hard to manage, I prefer them to exist as separate prg files (like even a few lines of procedure might be a separate file). Mike Yearwood was suggesting this and I was objecting, thinking it is better to have less files but in time, I saw he was right :) Sometimes I have a few procedures in the same file if they are closely coupled. These are all separate prg files (SQLQueryInto.prg for example).
>
>Glad you came around. It's not important what files we have. It does not really matter how things are stored at design time. It's important that the bits of code are reusable, how they are available at runtime. The only drawback is that the project manager is tied to source safe and it's slow with lots of files.
>
>Encapsulation is not about how things are stored at design time.
>
>I don't have to tell FoxPro I want to access a date function library before x=date(). Likewise I really do not want to say SET PROCEDURE or SET CLASSLIB.
>
>I want to say x=MyCode() or oClass=MyClass(). Clean and simple. Yes - I want MyClass to be the name of a class definition and I want oClass to use an object factory to determine what class to instantiate.
>
>With many things aggregated into big files, multiple developers cannot simultaneously work in different parts of those files without source control/merging. Sharing the code is a design time thing and so should not be impacting the execution at runtime.
>
>The code is a blueprint. The exe is the physical manifestation of the code.

Just want to point out that my code for splitting a procedure file into individual PRGs is now in the Thor Repository. My article about it, including the reasons I don't like procedure files, is here: http://www.tomorrowssolutionsllc.com/Articles/Splitting%20a%20Procedure%20File.PDF

Tamar