Matt,

Just because a file is in a project, it doesn't mean that VFP runtime environment items SET CLASSLIB, PATH, PROCEDURE or LIBRARY commands default to all of the entities.

In fact it's probably not a good idea for VFP to automatically set these for you because:

1) there may be some hierarchy involved that it can not be aware of. Our environment here is one example of this. There is a "library" classlib X that has a class Y in it. There is an account specific classlib AccountQ that has a subclass of Y and the subclass is also named Y. AccountQ occurs higher up in the classlib path so the account specific subclass is instantiated by the driver code inside of the base class Y.

2) There may be classes that are never instantiated directly so there is no need to have the class in the path clogging things up. For example classlib basecontrols has a first level subclass of all of the VFP baseclasses. Everything in the other classlibs is a further subclass of these so there never a need to have basecontrols in the classlib path.

3) just because I have 20 .prg files in the project I don't want a SET PROCEDURE setup that includes all of these UDFs.

It may seem redundant but it's not as bad as you think it is.

>If I have added my class lib's to my project file, why do I still have to put code like:
>
>set classlib to f:\blah\library1
>set classlib to c:\vfp7\ffc\_table additive
>etc.
>
>It seems stupidly redundant. I told the computer which class lib's were assosciated with my app, and where to find them when I added them to the project, and I still have come back and programmatically activcate them.