>>>One thing that I had found that occured in VFP6, was that if you made a reference to ANY class that existed in an external to the .EXE classlib, that VFP could become confused and expected to find all classes externally. It appeared that it had "lost" it's internal references of all classlibs. I don't know if that still occurs with VFP7 or 8, but it was definitely a problem with VFP6, at least for our app. Could this be a problem for you, or are you absolutely sure all of your classlibs part of the .EXE?
>>
>>That might be...
>>When I said we have all classes included, I counted on the fact that when we build the EXE classes used are automatically puled in the project.
>>How would you make a reference to an "external" (you mean a class in a lib that is not included, right?) without having the class lib included when you build?
>>Do you remember the circumstances in which this happened to you in more detail?
>>I can't think that we have classes not included, but the effect is certainly exactly like VFP has lost its way and tries to find all classes externally, so I'll do some more exploring...
>>Thanks for staying with me.
>
>We used to have certain optional "layers" of class libraries. Some of these could be field replaced, hence they were external. But since they were optional altogether, they didn't even need to exist. The SET CLASSLIB command would check for the existance of the .VCX files and we'd adjust accordingly.

Doesn't look like our case...
I discovered that we still have a few newobject() where we have the class library (cModule parameter) with the path included. I dont know if that confuses VFP, but I know that no user can see that folder, in fact VFP could (should?) complain about that.
So I'm going to search and remove the path from all our newobject() and see if the error stops.