views:

58

answers:

1

I'm attempting to host an ActiveX control in a WPF app. After attempting to use existing info on the web and here, I've hit a dead-end.

I need to use an ActiveX control provided to communicate with a UV power meter. They provide an application that registers and uses the control and even includes some useful demo apps. I stripped out the OCX file and put it here if needed. You won't have the power meter to talk to, but the app and demos will still load the ActiveX control successfully.

I created a simple Windows Forms application. I was able to bring the ActiveX control into the toolbar, drop it into my form, and everything is fine. The demo apps they provide do this as well.

However, getting this to work in a WPF environment is another story. The control can't be added to the toolbox and "dragged" into the app.

So far I've tried two techniques:

  1. Technique found here. I am able to add a reference to the control, but then I enter namespace hell. The xmlns:ax namespace it suggests making cannot find the information. Here's my attempt based on what the object viewer tells me: xmlns:ax="clr-namespace:OphirUsbXLib;assembly=Interop.OphirUsbXLib"
  2. Technique found here. This is essentially to create a new project that creates a library based on Windows Forms, which contains the ActiveX control (yikes). I am able to add the Windows Forms Host, but I cannot get access to the ActiveX control within. I can make the control public, but I still cannot call methods etc. This doesn't look like the right solution.

In short, I have an ActiveX control that works beautifully in Forms, but is a real bitch to get working in WPF.

Any insight is appreciated!

+1  A: 

In this situation I would consider making a WinForms usercontrol which wraps the ActiveX control you are trying to use.

You could make public properties and methods which expose each of the required properties and methods on the ActiveX control, and then host this WinForms UC on the in a WPF WinFormsHost control.

I have already done something similar to this, in reverse, hosting a WPF UserControl in a WinForms UserControl, then hosting that on a VB6 Form in a legacy application.

benPearce
I think what you're describing will work (the second approach), but it just seems like a pain to have to write fresh access methods to get at the ActiveX control. Say the control has 50 methods, for example, 50 new methods would need to be written that essentially "pass through" to the control. I wish there were a better way.
Tim
Take a pragmatic approach, only expose those methods and properties that you actually need to use from the WPF application
benPearce