Andrew Whitechapel : VSTO Doc Solutions

Using Managed Controls as ActiveX Controls

andreww — Tue, 25 Nov 2008 10:31:00 GMT

Can you use a managed usercontrol in an Office document in the same way that you can use a native ActiveX control – all without using VSTO? Some time ago, I posted about how to use native ActiveX controls within a doc-level VSTO solution, by wrapping them in managed usercontrols. A reader (Casey) asked the question, “what about going the other way?” The answer is “maybe”. Or, to be more precise, “up to a point, but the technique is unsupported and probably won't work in most scenarios”. If you still want to play with this a bit, here’s how to start…

First, create a managed usercontrol project – either a Windows Forms class library or control library project. Use the usercontrol designer to design your custom usercontrol the way you want it (using any standard controls you like).

Second, in the project properties, on the Build tab, select the “Register for COM interop” option. This will register any COM-visible classes in the project when you build it, and will also build a COM typelib and register it.

Third, attribute your usercontrol class to make it COM-visible. Also, specify a GUID, to avoid getting a fresh one on each build; and specify that you want the compiler to generate a dispatch class interface for the control.

[ComVisible(true)]

[Guid("0F2A2E9D-C79E-4b1b-9AF7-2D1487F29041")]

[ClassInterface(ClassInterfaceType.AutoDispatch)]

public partial class ManagedOcx : UserControl

{

Next, we need to provide some additional registry entries: Control, MiscStatus, TypeLib and Version. You can do this with a .REG script, but it’s generally better to write functions that will be called on registration/unregistration (attributed with ComRegisterFunction/ComUnregisterFunction).

Control is an empty subkey. TypeLib is mapped to the GUID of the TypeLib (this is the assembly-level GUID in the assemblyinfo.cs). Version is the major and minor version numbers from the assembly version. The only mildly interesting subkey is MiscStatus. This needs to be set to a value composed of the (bitwise) values in the OLEMISC enumeration, documented here. To make this enum available, add a reference to Microsoft.VisualStudio.OLE.Interop (and a suitable ‘using’ statement for the namespace).

[ComRegisterFunction]

static void ComRegister(Type t)

{

string keyName = @"CLSID\" + t.GUID.ToString("B");

using (RegistryKey key =

Registry.ClassesRoot.OpenSubKey(keyName, true))

{

key.CreateSubKey("Control").Close();

using (RegistryKey subkey = key.CreateSubKey("MiscStatus"))

{

// 131456 decimal == 0x20180.

long val = (long)

( OLEMISC.OLEMISC_INSIDEOUT

| OLEMISC.OLEMISC_ACTIVATEWHENVISIBLE

| OLEMISC.OLEMISC_SETCLIENTSITEFIRST);

subkey.SetValue("", val);

}

using (RegistryKey subkey = key.CreateSubKey("TypeLib"))

{

Guid libid =

Marshal.GetTypeLibGuidForAssembly(t.Assembly);

subkey.SetValue("", libid.ToString("B"));

}

using (RegistryKey subkey = key.CreateSubKey("Version"))

{

Version ver = t.Assembly.GetName().Version;

string version =

string.Format("{0}.{1}", ver.Major, ver.Minor);

subkey.SetValue("", version);

}

[ComUnregisterFunction]

static void ComUnregister(Type t)

{

// Delete the entire CLSID\{clsid} subtree for this component.

string keyName = @"CLSID\" + t.GUID.ToString("B");

Registry.ClassesRoot.DeleteSubKeyTree(keyName);

}

Build the project, then run Excel. From the Developer tab, go to the Controls group, and click the Insert button. This drops down a little gallery of available controls. The one in the bottom right-hand corner pops up the More Controls dialog, which offers a list of all suitably-registered ActiveX controls. You should find your custom control in this list.

Note: this seems to work OK for Excel (with the very limited testing I've done), partly works with PowerPoint, but fails miserably with Word. Possibly, some more of the OLEMISC values might improve this; possibly there are some messages we need to hook; possibly there are some more interfaces we need to implement – I haven’t tried. Of course, the VSTO runtime has a nice set of hosting controls that enable this behavior for Excel and Word, but these are not usable outside the context of a VSTO solution. As I said, this is an entertaining avenue to explore, but it remains unsupported. The fact that I’ve only barely got it to work in a very limited way should tell you that this is probably not a technique you want to use in any serious way.

VSTO Loader and Runtime Components

andreww — Thu, 03 Apr 2008 05:06:00 GMT

Perusing the forums over the last few months, it’s clear that there’s some confusion about the various VSTO loader and runtime components. At the time of writing, there are 4 versions of VSTO in existence, including 4 sets of design-time tooling and 3.5 versions of the VSTO runtime. I say 3.5 versions, because the VSTO 2005 SE runtime was an in-situ replacement for the VSTO 2005 runtime, and both are considered VSTO v2 (2005 SE was purely additive to 2005). Other versions – that is, VSTO 2003 (v1) and VSTO 2008 (v3) – are SxS with v2.

Right now, each VSTO solution runs against the version of the VSTO runtime that it was built against, regardless of the version of Office that is hosting it. It can be confusing to figure out which version will be used, so here’s a breakdown. The 4 versions of VSTO in existence at the time of writing are:

· VSTO 2003 (VSTO v1 runtime), which supported doc-level customizations for Excel and Word 2003 only, in a very simple fashion.

· VSTO 2005 (VSTO v2 runtime), which provided very much broader and deepter runtime support for Excel/Word 2003 doc-level customizations, and introduced app-level add-in support for Outlook 2003.

· VSTO 2005 SE (VSTO v2 runtime), which maintained the v2 runtime support for Excel/Word 2003 doc-level customizations, and replaced the app-level add-in support – extending it to cover Excel, Outlook, PowerPoint, Visio and Word 2003, and Excel, InfoPath, Outlook, PowerPoint, Visio and Word 2007.

· VSTO 2008 (VSTO v3 runtime), which maintained the v2 runtime support for Excel/Word 2003 doc-level customizations, and added v3 runtime support for Excel/Word 2007 doc-level customizations. Also maintained the v2 runtime support for app-level add-ins for Excel, Outlook, PowerPoint, Visio and Word 2003, and added Project 2003. Also added v3 runtime support for app-level add-ins for Excel, InfoPath, Outlook, PowerPoint, Project, Visio and Word 2007. Plus, added design-time support for SharePoint 3.0 Workflow.

The runtime versions are used as follows, first the doc-level solution types:

· A VSTO 2003 v1 doc-level solution will always run with the VSTO v1 runtime. You could only create a VSTO 2003 solution for Excel/Word 2003, but the solution should continue to run without change in Excel/Word 2007 – and it will continue to use the VSTO v1 runtime.

· A VSTO 2005 v2 doc-level solution will always run with the VSTO v2 runtime. There’s no such thing as a VSTO 200 SE doc-level solution, because VSTO 2005 SE was additive to VSTO 2005, adding only app-level add-in support. Again, a VSTO 2005 doc-level solution built against Excel/Word 2003 should continue to run unchanged in Excel/Word 2007 and will continue to use the VSTO v2 runtime.

· A VSTO 2008 doc-level solution for Excel/Word 2003 will use the VSTO v2 runtime. It should also continue to run without change in Excel/Word 2007 and will continue to use the VSTO v2 runtime.

· A VSTO 2008 doc-level solution for Excel/Word 2007 will use the VSTO v3 runtime. It will not run in Excel/Word 2003.

Similar patterns hold true for app-level add-ins:

· A VSTO 2005 v2 Outlook add-in will run against the VSTO 2005 v2 runtime so long as VSTO 2005 SE is not installed. If VSTO 2005 SE is installed, then the add-in will run against the VSTO 2005 SE v2 runtime.

· A VSTO 2005 SE v2 add-in for Excel, Outlook, PowerPoint, Visio or Word 2003 will run against the VSTO 2005 SE v2 runtime. It will not run if the VSTO 2005 SE runtime is not installed. It will continue to run without change in Excel/Outlook/PowerPoint/Visio/Word 2007, and it will continue to use the VSTO 2005 SE v2 runtime.

· A VSTO 2005 SE v2 add-in for Excel, InfoPath, Outlook, PowerPoint, Visio or Word 2007 will run against the VSTO 2005 SE v2 runtime. It will not run if the VSTO 2005 SE runtime is not installed. It will not run in Office 2003 because it requires the Office 2007 PIAs which are not designed to be used with Office 2003.

· A VSTO 2008 add-in for Excel, Outlook, PowerPoint, Project, Visio or Word 2003 will run against the VSTO 2005 SE v2 runtime. It will not run if the VSTO 2005 SE runtime is not installed. It will continue to run without change in Excel/Outlook/PowerPoint/Project/Visio/Word 2007, and it will continue to use the VSTO 2005 SE v2 runtime.

· A VSTO 2008 add-in for Excel, InfoPath, Outlook, PowerPoint, Project, Visio or Word 2007 will run against the VSTO 2008 v3 runtime. It will not run if the VSTO 2008 runtime is not installed. It will not run in Office 2003 because it requires the Office 2007 PIAs which are not designed to be used with Office 2003.

The different versions of the VSTO runtime include different loader components. The load sequence therefore varies according to the version of the solution. For doc-level customizations, the load sequences are:

· VSTO 2005: Otkloadr.dll à VSTOLoader.dll à VSTORuntime.dll à solution

· VSTO 2005 SE Office 2003: Otkloadr.dll à VSTOLoader.dll à VSTORuntime.dll à solution

· VSTO 2005 SE Office 2007: Otkloadr.dll à VSTOLoader.dll à VSTORuntime.dll à solution

· VSTO 2008 Office 2003: Otkloadr.dll à VSTOLoader.dll à VSTORuntime.dll à solution

· VSTO 2008 Office 2007: VSTOEE.dll à VSTOLoader.dll à solution

The load sequences for app-level add-ins are:

· VSTO 2005: AddinLoader.dll à solution

· VSTO 2005 SE Office 2003: AddinLoader.dll àVSTORuntime.dll à solution

· VSTO 2005 SE Office 2007: VSTOEE.dll àAddInLoader.dll à VSTORuntime.dll à solution

· VSTO 2008 Office 2003: AddInLoader.dll à VSTORuntime.dll à solution

· VSTO 2008 Office 2007: VSTOEE.dll à VSTOLoader.dll à solution

Why do we have so many runtime versions, you might ask? Why is it so seemingly complicated? Well, the runtimes are designed for the opposite purpose – the intention is to make life simple for users – users should not need to worry about which version is used, and we have multiple versions to ensure that all solutions will continue to run without change in the face of new versions of Office. A major factor in this is the requirement that a deployed solution should continue to work without any user/admin intervention even though the user might upgrade the version of Office on their machine. They might have multiple solutions deployed which were built over time against multiple versions of VSTO – and all of them should just continue to work.

Integrating Doc-level and Add-in Solutions

andreww — Fri, 21 Mar 2008 03:20:00 GMT

Everyone knows you can build document-level Office solutions and you can build application-level Office add-ins. Suppose your requirements dictate that you build a solution that uses both techniques – can this be done? First, let’s pause and consider whether this is a good idea in the first place, and whether you could re-architect to use only one or the other.

In most cases, the requirements for a solution can be met either with doc-level solutions or app-level add-ins. The Office application’s COM object model is entirely available to both types of solution. In some cases, there will be clear advantages to one or the other approach. For example, the VSTO-enhanced doc-level host-item controls (eg, XmlNodes and Content Controls in Word – or, ListObjects and NamedRanges in Excel) are only available in doc-level solutions. In other cases, you could do it either way. For example, suppose you have a need for some control UI in a custom task pane – you could use the doc-level Actions Pane, or you could use the app-level Custom Task Pane. Suppose you need Ribbon customization – again, you could do this either with a doc-level solution or with an app-level add-in. The same is true for custom CommandBars in older versions of Office.

On the other hand, there will be some contexts where the only possible solution requires the use of both techniques. Consider this scenario, for example:

· Your solution needs to work with users who have Word 2003 and with other users who have Word 2007.

· A user must be able to work with the solution in one version, then hand the document to another user who might be using the other version, who then hands it back for further work. In other words, the same document must be editable in both versions, it must be round-trippable, and the VSTO customization must work in both versions.

· The solution requires custom CommandBars when running in Word 2003, and custom Ribbon when running in Word 2007.

· The solution requires some form of Custom Task Pane or Actions Pane.

These requirements impose significant constraints on the solution design, specifically:

· The solution must use the Word97-2003 binary file format, because the VSTO v3 runtime that works with the new Open XML file format does not work with Word 2003.

· You cannot use doc-level Ribbon customization, because this only works with the new file format. So, you must use app-level Ribbon customization.

· You cannot use an app-level Custom Task Pane, because it must work the same in Word 2003 which does not support Custom Task Panes. So, you must use the doc-level Actions Pane.

To meet these seeminly conflicting requirements, you’d have to design the solution to use both doc-level and app-level components:

· Build an app-level add-in, which will work in both Word 2003 and 2007. This would include conditional code to determine which version of Word the solution is running in, and set up either a Ribbon customization or custom CommandBars accordingly.

· Build a doc-level customization, targeting the old binary file format in Word 2003 – which will also work in Word 2007, so you can have a doc-level ActionsPane.

· Remaining business logic could be put in either place: either in the doc-level customization or in the app-level add-in. If you need closely integrated processing of VSTO doc-level host-item control wrappers, this obviously goes in the doc-level customization. Any other work could go in either place.

· Connect the doc-level customization with the app-level add-in through shared logical interfaces. That is, the doc code will include an object that implements some interface, say IDocumentCommands, that is known to the add-in; and the add-in will include an object that implements some interface, say IAddInCommands, that is known to the doc code. These interfaces should be defined in a separate assembly that is then re-used by both the doc customization and the add-in.

· The runtime hook-up can use the fact that all app-level add-ins are exposed through the host application’s COMAddIns collection. Each add-in can expose any arbitrary functionality by setting the COMAddIn.Object property to some arbitrary object. In a sensible system, you would set this property to an object that implements an interface that is known to both the doc-level customization and the app-level add-in, say IAddInCommands.

· Calls from the doc-level customization to the app-level add-in will therefore go through this object, via standard CLR COM interop.

· The Office COM object models do not expose any COMAddIns equivalent for doc-level customizations. That means that the doc-level code must make itself available in a custom manner, and without the benefit of CLR COM interop.

· Therefore, the solution requires that the doc-level code gets hold of the add-in’s exposed object via the COMAddIns collection, and hands off to the add-in some exposed doc-level object. From this point, calls in the other direction – that is, from the app-level add-in to the doc-level customization will go through remoting, via the shared (IDocumentCommands) interface.

Here’s an overview of the design:

Let’s break this down. First, we define the two interfaces in a separate class library. Note that the IDocumentCommands interface will be implemented in the doc code, and the implementing object will be used via remoting – so this does not need to be COM-visible. On the other hand, the IAddInCommands will be implemented by the object that the add-in sets into the COMAddIn.Object property, and will be used via COM interop – and therefore needs to be a COM-visible dual interface:

namespace DocumentAddInInterfaces

{

public interface IDocumentCommands

{

void InsertText(string s);

}

[ComVisible(true)]

[Guid("158CF0BC-16F3-49be-A4DD-E3A81283C7A0")]

[InterfaceType(ComInterfaceType.InterfaceIsDual)]

public interface IAddInCommands

{

void RegisterDocument(IDocumentCommands d);

void InsertText(string s);

}

When the add-in loads, it constructs some arbitrary object that it wishes to expose. This object implements an interface (IAddInCommands) that is known to both the add-in and the doc customization. This interface offers two methods: RegisterDocument, which allows the doc-level code to register itself with the add-in; and InsertText, which inserts some text in the document:

[ComVisible(true)]

[ClassInterface(ClassInterfaceType.None)]

public class AddInCommands : IAddInCommands

{

private Word.Application wordApplication;

public AddInCommands(Word.Application w)

{

wordApplication = w;

}

public void RegisterDocument(IDocumentCommands d)

{

Globals.ThisAddIn.documentCommands = d;

}

public void InsertText(string s)

{

object missing = Type.Missing;

Word.Range r = wordApplication.ActiveDocument.Range(
ref missing, ref missing);

r.InsertAfter(

String.Format("Add-in.InsertText: {0}{1}",
s, Environment.NewLine));

}

The add-in sets this object as the value of the Object property in the COMAddIn object that represents this add-in in the COMAddIns collection of the host application. In VSTO add-ins, this is done by overriding the RequestComAddInAutomationService method:

public partial class ThisAddIn

{

internal IDocumentCommands documentCommands;

public IAddInCommands addInCommands;

protected override object RequestComAddInAutomationService()

{

if (addInCommands == null)

{

addInCommands = new AddInCommands(this.Application);

}

return addInCommands;

}

When the document loads (at some point after the add-in is loaded), it gets hold of the application’s COMAddIns collection, and the specific COMAddIn object that represents the add-in it wants. From this, it gets the add-in’s exposed object that implements IAddInCommands. The first thing it does with this object is to call back on its RegisterDocument method. This is the method that allows the doc code to pass an arbitrary object to the add-in code, thereby establishing the two-way communication:

public partial class ThisDocument

{

public IDocumentCommands documentCommands;

internal IAddInCommands addInCommands;

private void ThisDocument_Startup(object sender, System.EventArgs e)

{

SimpleControl simpleControl = new SimpleControl();

this.ActionsPane.Controls.Add(simpleControl);

try

{

documentCommands = new DocumentCommands(this.Application);

object addInProgId = "IntegrationTestAddIn";

addInCommands =

(IAddInCommands)

this.Application.COMAddIns.Item(ref addInProgId).Object;

addInCommands.RegisterDocument(documentCommands);

simpleControl.btnCallAddIn.Enabled = true;

}

catch (Exception ex)

{

MessageBox.Show(ex.ToString());

}

Note that the code above assumes we have a SimpleControl custom UserControl that we’re placing in the doc-level Actions Pane. This SimpleControl offers a button that the user can click.

The doc object implements another known interface (IDocumentCommands) which has one method, InsertText. This object will be used via remoting, so we’ll make it MBRO:

internal class DocumentCommands :

System.MarshalByRefObject, IDocumentCommands

{

private Word.Application wordApplication;

public DocumentCommands(Word.Application w)

{

wordApplication = w;

}

public void InsertText(string s)

{

object missing = Type.Missing;

Word.Range r = wordApplication.ActiveDocument.Range(
ref missing, ref missing);

r.InsertAfter(

String.Format("Document.InsertText: {0}{1}",
s, Environment.NewLine));

}

At some point later on, the user interacts with the doc customization code and also with the app-level add-in code, in no particular order. Here’s what happens when they interact with the custom CommandBars or Ribbon (which are implemented in the add-in)… They click a button (in the Ribbon/CommandBar) to insert some text in the document. This button handler uses the cached IDocumentCommands object to invoke the InsertText method implemented in the doc code:

public void btnCallDocument_Click(Office.IRibbonControl control)

{

Globals.ThisAddIn.documentCommands.InsertText("Add-in invokes Doc");

}

Conversely, when the user interacts with the doc-level custom ActionsPane, the Click handler for the button on the UserControl uses the cached IAddInCommands object to invoke the InsertText method implemented in the add-in code:

private void btnCallAddIn_Click(object sender, EventArgs e)

{

Globals.ThisDocument.addInCommands.InsertText("Doc invokes Add-in");

}

To sum up: most of the time, you can simply pick one or other of the two main Office client customization technologies to meet your solution requirements – and you should strive to keep things simple wherever possible. On the other hand, sometimes you need to build a more complex solution that uses both technologies. This is particularly true if you need to span multiple Office versions, each of which supports different extensibility mechanisms. If you take this approach, you’ll want to connect the components together in some sensible fashion. Going from add-in to doc customization, you can use the CLR’s standard COM interop. Going from doc customization to add-in, you can use remoting. In both directions, you should use a defined set of interfaces.

ActiveX Controls in VSTO Solutions

andreww — Thu, 13 Mar 2008 07:26:00 GMT

In the past, before it became strategically acceptable to build Office-based solutions in managed code, it was common for people to build such solutions using pure COM technologies. They built native COM add-ins, using C/C++, or they built document-level customizations using VB and VBA. In some scenarios – typically doc-level – the solutions made heavy use of ActiveX controls. Typically, the solution used both standard and custom ActiveX controls, often on the document surface – and (rather less commonly) in the ISmartDocument-based document actions pane.

Now that VSTO has emerged as the preferred technology for building Office-based solutions, it is common for people to use managed custom UserControls (either Windows Forms-based or, increasingly, WPF-based) in their solutions.

However, some of the native ActiveX controls used in earlier systems are still very relevant and useful to the requirements of newer solutions. Plus, it’s not always practicable (or, sometimes, even possible) to rewrite your native ActiveX controls as new managed UserControls. One obvious technique to resolve this is, instead, to wrap the native controls in managed UserControls.

What follows is an example (obviously very simplified) of one way to do this. I’ll create a VSTO doc-level solution, and add two custom UserControls, each one wrapping a native ActiveX control. I’ll put one of these on the document surface, and the other on the doc-level ActionsPane.

First, create a new VSTO Word 2007 doc-level project. Then, add a new UserControl, called ManagedMSCal. When this opens in the designer, right-click in the Toolbox and select Choose Items. In the Choose Toolbox Items dialog, select the COM tab, and then check the box next to Calendar Control 12.0. This is a native ActiveX control in the DLL MSCal.ocx:

Importing this will generate two interop assemblies:

ú Interop.MSACal.dll – this is the CLR proxy for COM types, that is the conventional interop assembly which is the managed equivalent of the COM type library.

ú AxInterop.MSACal.dll – this is Windows Forms proxy for the ActiveX control. It defines a class AxCalendar which derives from System.Windows.Forms.AxHost.

You’ll also notice that the Calendar Control is now available in the Toolbox:

You can treat this like any other control in the Toolbox, and drag-drop it onto the UserControl design surface:

Set its Dock property to Full, and its Modifiers property to Public – this last is a lazy short-cut to allow us to expose the inner AxCalendar object as a publicly accessible member of the wrapper ManagedMSCal control. This will generate a new field in the hidden part of the UserControl partial class:

public AxMSACAL.AxCalendar axCalendar1;

Next, in the ThisDocument class, declare an instance of the ManagedMSCal wrapper UserControl as a private field in the class:

private ManagedMSCal managedMSCal;

In the ThisDocument_Startup method, instantiate the control, and sink its AfterUpdate event – we’ll get this event when the user clicks a different date in the calendar. Then, add the control to the ActionsPane:

private void ThisDocument_Startup(object sender, System.EventArgs e)

{

managedMSCal = new ManagedMSCal();

managedMSCal.axCalendar1.AfterUpdate +=
new EventHandler(axCalendar1_AfterUpdate);

this.ActionsPane.Controls.Add(managedMSCal);

}

In the AfterUpdate event handler, insert a paragraph at the end of the document, and then insert the selected date:

void axCalendar1_AfterUpdate(object sender, EventArgs e)

{

this.Content.InsertParagraphAfter();

this.Content.InsertAfter(
this.managedMSCal.axCalendar1.Value.ToString());

}

At this point, you can build and test. The wrapped ActiveX control will appear in (the managed UserControl in) the doc-level ActionsPane. When the user clicks a date in the calendar, that date is inserted into the document.

Next, add another custom UserControl, called ManagedSlider. As before, right-click the Toolbox, select the COM tab, and choose the Microsoft Slider Control v6.0 – this is in MSComCtl.ocx. As before, drag-drop it from the Toolbox onto the UserControl design surface. Set its Dock property to Full, its Modifiers property to Public, its Min property to 1, and its Max property to 100. This will generate a new field in the hidden part of the UserControl partial class:

public Axmscomctl.AxSlider axSlider1;

Now open the document in the designer in Visual Studio. From the Word Developer tab, select a RichText content control, and drop it onto the document. In the content control, type in the text “Hello World”. Then drag-drop the ManagedSlider control from the Toolbox onto the document surface:

This will generate two corresponding fields in the hidden part of the partial ThisDocument class:

internal Microsoft.Office.Tools.Word.RichTextContentControl richTextContentControl1;

internal WordDocOcx_ManagedSlider wordDocOcx_ManagedSlider1;

Update the ThisDocument_Startup method to sink the Scroll event on the wrapped AxSlider object. Handle this event by setting the font size of the text in the Rich Text content control to the value of the slider:

private void ThisDocument_Startup(object sender, System.EventArgs e)

{

managedMSCal = new ManagedMSCal();

managedMSCal.axCalendar1.AfterUpdate +=
new EventHandler(axCalendar1_AfterUpdate);

this.ActionsPane.Controls.Add(managedMSCal);

this.wordDocOcx_ManagedSlider1.axSlider1.Scroll +=
new EventHandler(axSlider1_Scroll);

}

void axSlider1_Scroll(object sender, EventArgs e)

{

this.richTextContentControl1.Range.Font.Size =
this.wordDocOcx_ManagedSlider1.axSlider1.Value;

}

Build and test:

Over time, many people will move wholesale to pure managed development, typically using VSTO. Some people will find it more appropriate to stick with native code, COM and ActiveX controls. For the people in the middle, who want some sensible transition plan, wrapping existing ActiveX controls in managed UserControls is a reasonable approach.