>Ok guys, I'm at a critical point here, and I need a solution.
>
>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 form, 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.

Why do you/they need more than one .OCX?
If all it needs to do is to feed arrays to VFP then one OCX with the interface raising one event should be enough....

>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.

They could do it indirectly by raising an event that passed the method name as a parameter.

HTH,
Viv