>This will work for this way of instantiation.
>But there are other ways to instantiate a object from a differnt app.
>
>You could to strange things with classes if you start with this.
>
>A lot depend on SET CLASSLIB
>If there is nice little subclassing through some vcx's you can catch a parent from where you like.
>
>Think you have a form xy in classlib zz. This uses an grid out of classlib xx. Classlib zz is compiled to your First.EXE. (Simple exclude xx in project manager)
>
>Classlib xx is in a HelpFirst.exe
>
>If you have classlib named xx also in second.exe.
>It contained a class of similar to the grid's class.
>Second exe is compiled later out of same path structure and owns some new features to the grid.
>
>A
>SET Classlib TO xx IN APP HelpFirst.exe
>or
>SET Classlib TO xx IN APP second.exe
>before instantiating form xy can change behaviour of the grid.
>
>So I want to know where my grid is comming from.
>
>Agnes

You are one step from the idea of making your classes as COM components and instantiate them with ProgID, e.g.

ThisForm.AddObject('eexcel','OLEControl','Excel.Application.10')

You can have versions in your COM components so that you will be able to know what functionality you have in them.

VFP lacks of this functionality that you need.
I do not know 100% sure way to determine from which APP you have instantiated a given object.

Kind Regards