Yeah I don't think what you try to do will work because you'll have no idea what interfaces to implement to make this work.
I think what you're trying to accomplish is some sort of plug-in architecture if I understand this right. If that's the case what I would do is force whatever control is created to implement a specific method (not an interface just a method) that can accept the VFP COM object as a parameter. Once that object is passed the control/com object can do whatever it wants with it. You publish the interface, document it and then they can control your app.
I've done this sort of thing with Help Builder's Add-in interface, which allows extension with .NET, COM or of course Visual FoxPro. In .Net I created a wrapper interface and wrapper COM object that holds all of the FoxPro COM Interop objects. As far as the .NET developers that want to extend are concerned they're talking to a pure .NET interfacce - they don't ever see any FoxPro. You can do the same sort of thing with a VB wrapper if you choose.
The other option you have is, is to create a COM interface in a different language - VB, .NET, Delphi, C++ etc. - and register that interface. Then force your customers to implement that interface. Again you'll need to have amethod on that interface like an initializer that can receive a reference of your application object or form or whatever it is you want the control to have a reference to and then call that from your code. THe advantage of the Interface is that you can enforce your interface explicitly and the client environment can automatically implement a skeleton interface.
Most likely this is a simple interface that just has this one Initalize(loFoxObject) method and nothing more but it's really up to you.
+++ Rick ---
>Here is what I'm trying to do.
>
>We have a VFP app that uses Crystal Reports. Our report viewer in built in, as are all the
>dialogs used to prompt for parameters.
>
>We have a client who wants to develop their own reports and their own parameter dialogs.
>Their developers only know VB 6, so I thought that if they developed ActiveX controls, and
>I programmatically dropped them on a base VFP dialog form, then the dialog would actually be
>running inside our application.
>
>All the VB portion needs to do is pass arrays of parameter info to the VFP for, so that
>they can be passed on to the Crystal Report.
>
>Problem is, for every VB control they create, there would have to be a VFP class that binds
>to it and implements it's interface. I'm seeing that this probabaly won't work overall.
>
>What would work is if there was a way for the VB ActiveX control to directly call methods on
>the VFP form. Then the controls could simply pass they parameter arrays directly to the VFP
>form.
>
>I'm not sure if ActiveX control can call methods on a VFP form, and if so, I don't know the syntax.
>
>So far I have all this in a small project:
http://marois-consulting.com/ns/ns.zip>
>Any help is appreciated.
>
>Thanks
>
>
>
>
>
>
>
>
>
>
>>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
