Thanks, Victor and Naomi. I will give it a whirl in the morning.

And possibly the afternoon as well. In the interests of keeping it simple, one thing I didn't mention is there are 66 sub-apps. I wish I were joking.

>What I've done in situations like that is:
>
>1. delete all .fxp files
>2. recompile all the class libs (COMPILE CLASSLIB *.vcx)
>3. recompile all the forms (COMPILE FORM *.scx)
>4. recompile entire application.
>
>
>
>>I have inherited responsibility for a large VFP 9 app, or should I say a large number of related apps. (Together they run most of the business). The whole thing is structured in a way I have not run into before and the specific problem I am facing is the "source is out of date" message when trying to debug.
>>
>>Here is the way things are structured on the hard drive. The names are not real but should illustrate the issue ---
>>
>>X:\MyApp
>>X:\MyApp\app1
>>X:\MyApp\app2
>>X:\MyApp\app3
>>
>>......
>>
>>X:\MyApp\appN
>>
>>There is also a folder named X:\MyApp\apps. It contains a copy of each .APP file built from the projects in app1 through appN.
>>
>>The EXE runs from X:\MyApp. In its main program, it issues a series of SET PROCEDURE ADDITIVE commands referencing about a dozen of the .APP files in X:\MyApp\apps. It then displays a menu and a toolbar. Depending on what the user chooses, a call is made to a program or form within the appropriate sub-app.
>>
>>The problem is when I try to debug one of those programs or forms the debugger shows the dreaded "source is out of date" message in the trace window.
>>
>>The two guys who wrote this system left under bad circumstances, leaving behind no documentation and providing no turnover, so I can't ask them. This is really a general VFP debugging question. What do I need to do to trace through the source code? I can do so fine in the main EXE but not in any of the sub-apps.
>>
>>Thanks in advance for any assistance.