For some reason your reply to me couldn't be replied to so I'm doing it on this message out of sync.
What I'm saying is that IMPLEMENTS is a compile time thing. There's nothing dynamic about it and you can't control it at runtime, unless you do this like Marcia suggests by creating a temporary class and then compiling and using that.
However, if the controls you're trying to use implement a specific interface that interface is fixed and you should be able to implement the interface and it will work with any COM object that implements that interface. Interfaces are globally unique so as long as the interface is registered somewhere on the machine when you compile VFP can create the appropriate association and find the appropriate interface to attach to at runtime.
OTOH, I'm not quite sure what you're doing - an interface is unique and has to pretty much belong to a specific DLL. So it's always going to be in the same place no matter what. You can't have two versonions of the same interface in separate files. Unless you're talking about something other than interface here there's only one wya that this can possibly work.
You can use the Interface ProgId (if there is one) or the ClassID (although I seem to remember some problems with that before).
+++ Rick ---
>I have a VFP class that will implement VB ActiveX control interfaces to handle their events.
>The VB ActiveX control being used could be different each time the class is run Each of the
>ActiveX controls will have the same public interaface.
>
>Is there any way to dynamically fill in the control name and control library in the
>IMPLEMENTS statement:
>
>
>
>
>PUBLIC &gcControlName, gcControlLibrary
>gcControlName = "__rptAccountStatus"
>gcControlLibrary = "d:\demo\nsacctstatus.ocx"
>
>
>DEFINE CLASS RPTControlEvents AS session OLEPUBLIC
>
> ** Inherit the interface of the VB ActiveX report control
>** IMPLEMENTS __rptAccountStatus IN "d:\demo\nsacctstatus.ocx"
> IMPLEMENTS (&gcControlName) IN (gcControlLibrary)
>
>ENDDEFINE
>
>Thanks
