More Misha Cat: Why did we use the wrap approach rather than the extends approach for Actions Pane

Continuing my series of interviews with Misha Shneerson.

Eric: Why did we use the "wrap" approach for ActionsPane instead of the "extends" approach?

VSTO uses two models to provide additional functionality on top of the Office object models. In some cases we wrap--for example VSTO's NamedRange object is a wrapper around Excel's Range object. NamedRange implements the Excel.Range object and basically delegates calls you make to its properties and methods to an inner object which is the actual Excel.Range object. We did that because you can't extend the Excel.Range type--this type is not "new-able" for one thing. 

However with managed controls you put on the document, we use an "extends" approach. For example, an extended control like Microsoft.Office.Tools.Excel.Controls.Button extends the System.Windows.Form.Button type. We can do this because in this case Button is a "new-able" type.

But with ActionsPane--which is effectively an extended UserControl--we used the "wrap" approach instead of the "extend" approach.

Misha: The reason is lazy instantiation. Our programming model always creates the ActionsPane host item control--in Word it is a member of the Document project item. In Excel it is a member of the the Workbook project item. We don't actually create the underlying managed control and attach the Smart Document solution to Word or Excel until your code access the ActionsPane control. At that point we can lazily instantiate all the components that make ActionsPane work.