>>>>>>>I ran an app from the command window and all was well, I thought.
>>>>>>>I built an .exe.
>>>>>>>When I ran the .exe it told me that a oapp.fedproc did not exist.
>>>>>>>When I looked at the applib.vcx the function did not, in fact, exist.
>>>>>>>Fortunately, I had an old copy that included fedproc, added it, and all is well.
>>>>>>>What is going on?
>>>>>>
>>>>>>Sounds like the old copy you referred to was in a folder that's earlier in our path list. And that you or someone else deleted the missing parts in the newer version.
>>>>>>
>>>>>>Anyway, make sure that the correct version if applb.vcx is included in the project.
>>>>>
>>>>>>Sounds like the old copy you referred to was in a folder that's earlier in our path list
>>>>>Tore
>>>>>Thank you for your reply.
>>>>>Can you please clarify what you mean by path list?
>>>>
>>>>I mean the order used in VFP's default path and your Set Path commands. Run this program, it will show the order in a readable format:
>>>>
>>>>

>>>>*Listpath.prg
>>>>#Define crlf Chr(13)+Chr(10)
>>>>Local laDummy[1], lcDummy, lnY
>>>>lcDummy = Set([Path])
>>>>lnY = Alines(laDummy, m.lcDummy,1+4, [;], [,])
>>>>lcDummy = []
>>>>For lnY = 1 To m.lnY
>>>>   lcDummy = m.lcDummy + m.laDummy(m.lnY) + crlf
>>>>Endfor
>>>>Messagebox( m.lcDummy )
>>>>

>>>
>>>But this only half of the problem. It misses for example SET CLASSLIB. what deals with this as well. Also systems search path.
>>>And if you open up a class from somewhere else, VFP caches the classlib, and this got precedence over all of this. There is a lot of fun included.
>>>
>>>I run all my tests from a clean environment with no path / classlibs except systems PATH
>>
>>
>>>And if you open up a class from somewhere else, VFP caches the classlib, and this got precedence over all of this
>>
>>That might be the issue here
>>I frequently look at classes in other apps - in like-named libraries- without leaving the current app.
>>How to defend against this?
>
>Run a second IDE for searching. Run a second IDE for testing, so it is not influenced by the searches. That's what I do.
>Still, I run into it from time to time, due to own tools that uses shared framework - but slightly different versions. Fun all the time.
>
>CLEAR ALL is not 100% secure against cached libs, and CLOSE ALL kills all projects.

Thank you, Lutz