Hi Albert

I suggest you use a launcher. Build the reports .app as a new exe and use the launcher for both. When the managers run the reports exe, the launcher will send them the new exe with the correct subclass. I leave the reports out of the exe and have the launcher check and update them as well.

>Hi y'all,
>
>I have loaded up a new version of an .app onto my client's server and when running a certain report, it complains that it cannot find a certain subclass. But the subclass is just a new subclass of a class that has existed in the .app for a long time. It runs on my dev machine when I am running the .app or just running the .vcx "raw" by erasing the .app. I suspect that somehow VFP is getting "confused" because of the following:
>
>1) the main app that users use for data entry etc is "compiled" to a .exe on the server. This does not change a lot.

>
>2) because it changes a fair bit, all the code that generates reports is in a separate app, compiled to a .app. Only a couple of managers run the reports a lot so it makes it easy to update the reports .app if they want a quick change - without kicking all 30 users of the system mid-day.
>
>I think the problem happens because some of the class .vcx's are in both the .exe and the .app. The .exe loads first and then when they go into the reports form, the .app loads when needed.
>
>I understand the basics of where VFP looks for what for "simple" things but do not know the rules of how it searches for a class when the class is present in two different .exe/.app's and what happens if the subclass is in both of those. Note that I did not really want to have class duplication between the two files but it seemed like once I went into the second .app, it could not find items in the first .exe so I had to bring in all the classes that I would need into the 2nd.
>
>The bizarrest thing is that if I compile both files and set up my environment on my desktop pc, VFP finds what it needs.
>
>TIA for any suggestions - including how to reorganize these files so that there is no class duplication.
>
>Albert Gostick