Interop with ActiveX Controls

An ActiveX control relies on COM to be activated, modified, have its properties invoked, and so on. Using tlbimp on an ActiveX control doesn't work well. The aximp utility calls tlbimp and creates an appropriate interop assembly; in addition, it creates a second interop assembly that specifically deals with the properties of the ActiveX component.

After you have the interop assemblies, you can reference them in the build and create classes that implement the desired interfaces. For an ActiveX component, you can set the properties and add them to the controls for the form. You can do all of this by hand, but it's not necessary.

This sample used an ActiveX control that was developed by Brent Rector as part of the book he co-authored with Chris Sells, ATL Internals. The control has been slightly modified so that it can be used as part of a VS7 solution. For details on the development of an ActiveX control, refer to Rector's discussion in ATL Internals (ISBN 0-201-69589-8). Two projects are associated with this sample: BullsEyeCtl and BullsEyeApp. BullsEyeCtl is the project that builds the ActiveX control. BullsEyeApp builds a Window Forms application that uses the BullsEyeCtl ActiveX control.

The first thing that you should do is build the ActiveX control. You can build the ActiveX control by loading the BullsEyeCtl project and selecting the “Rebuild Solution” option under the Build menu. This should build the control with no problem; however, if you have another instance of Visual Studio open and it is referencing the control, the control might fail because the “old” control could not be deleted.

Next, build the application that uses the BullsEyeCtl ActiveX control. This is the BullsEyeApp project. It might be a little tricky because the control has been added as part of the components available for the project. The tricky part is that you probably have installed the application and the control in a different directory. The easiest solution is to remove the control from the form and everywhere in the C# source. (It is called axBullsEye.) It will be easier if you just comment out the lines that look like this:

axBullsEye.OnRingHit += new AxBullsEyeLib._IBullsEyeEvents_ OnRingHitEventHandler(OnRingHit);
axBullsEye.OnScoreChanged += new AxBullsEyeLib._IBullsEyeEvents_
 OnScoreChangedEventHandler(OnScoreChanged);

If you comment out those lines in the source, it will be easier to add them back later.

Then, build the application. It should build without errors because the ActiveX control is not referenced any more. Next, you want to add the BullsEyeCtl to the toolbox (and the project). To do this, you need to select Customize Toolbox. This option is available if you are viewing the application in Design mode and you right-click on the Components section of the toolbox. You should see something like Figure 8.6.

With Customize Toolbox selected, you will be presented with a list of controls that can be added to the toolbox. Select the BullsEye Class. Your selection should look like Figure 8.7.

Now your toolbox should look like Figure 8.8.

At this point, you can select the BullsEye from the toolbox and place it on the Windows Forms just as any other control. After you adjust its position, change the RingCount property to 9, and rename the control to axBullsEye, the design looks like Figure 8.9.

Notice in the references section for the project that two new references have been added: AxBullsEyeLib and BullsEyeLib. You should be able to return to the code view, uncomment the lines that were commented out previously, and rebuild the application. Now when the application is run, you should see a bulls-eye with nine rings. Every time you click on one of the rings, you get two callbacks that indicate the ring you hit and a score associated with the hit.

After the control is successfully added to your toolbox in the project and you have fixed the location of the control, you can add the control easily to any other part of this or any other form in the project.

You learned how to insert an ActiveX control into a .NET project. You can see, however, that Visual Studio is building the interop assemblies for you when you add the control to your project from the toolbox. You can see the actual assemblies because they are placed in the same output directory as is used to place the application. (If you are doing a debug build, it would probably be in bindebug). In addition, you can change the properties from within Visual Studio to persist between project loads. Most of the features of an integrated control are available to a legacy ActiveX control.