Hi Chaim,

I don't think you can reliable determine the application in which the form resides. It would work if you call the application with DO, but not if you created a form with NEWOBJECT() passing the application name as the third parameter.

>I know I could add a property to the class and manually specify the name of the app at design time, but this approach would not work if the class appears in more than 1 app.

First of all, most likely you have more than this problem if the class appears in more than one application. While VFP supports multiple applications, there are three things that do not work:

1) Resolving class hierarchies of VCX based classes across multiple applications

2) Accessing files inside an application from external files. For example, if you have an external SCX file that loads a picture from the APP if works for the first form. If that form, however, launches another external form, the second form doesn't have access to the APP anymore.

3) Resolving class references by name and application. VFP uses only the name which makes it pick one or the other class depending on which form is executed, what the memory situation is like and whether we've full moon, or not.

In simple scenarios, all of this usually works fine. But as applications grew and get more complex, these issues become more and more important. For example, when you use the same class name, suddenly the debugger displays binary garbage when you try to debug the application, sometimes VFP crashes, and so on.

Moreover, it's very difficult to test. In order to debug, you need to copy all EXE/APP files into another directory that doesn't contain any of the source files. Otherwise, VFP silently uses the external files in your development directory. Without a test plan, problems in multi-APP file applications typically become apparent when the developer wants to release the first beta version and send it to the customer. Usually, this is an unfortunate situation since you promised to deliver today (all you need is to recompile and cleanup things a bit, you thought) and now have to admit another problem with your application.

Anyway, what about using a project hook to create/update an APP.H that contains the current application name. This way, you can use the same class, but each has the correct application compiled into the code.