Referencing Host Items in a DPM Project from the Host Item Container

In Dynamic Programming Model (DPM) style integrations there are three levels of correspondence between a DPM add-in and the host:

1)      “Host Item Container”:  This is the entry point type which contains the host items and has its own code file in a DPM add-in project.  This type and its associated code file would persist even if all host items were removed.  For example:   a document which contains drawings.

2)      Host Items:  These are items which receive their own code files in a DPM style integration and are associated with a specific item in the host.  If the host item is removed, the associated host item code file is removed from the add-in project.  If a new host item is added, an associated host item code file is added to the add-in project.  If a host item is renamed, the display name of the associated host item is updated in the add-in project.   For example:   drawings within a document.

3)      Host Objects:  These are objects which receive their own variable names within a host item code file in a DPM add-in project.  For example:  shapes within a drawing. 

In the SDK sample ShapeAppDynamicProgrammingModelCSharp a document is used as the host item container and its associated code file is “ThisDocument.xx ” (".cs" or ".vb").  Drawings contained within the document are host items and have code files which match their original name such as “Drawing1.xx”.  Shapes within drawings are host objects within host items such as “Circle1” in "Drawing1". These variables are declared and instantiated in the hidden  designer file of the associated host item code file.  For example:   if Drawing1 contained a circle, then Drawing1.designer.xx would have code to declare and instantiate the host object Circle1.  Note: to see the hidden designer files, select the "Show All Files" option in the Project Explorer pane and expand the node for a code file (see screen shot below).

Screen shot:  Hidden designer file

While host objects have a variable name associated with them that can be accessed through their host items, in the SDK sample, host items do not.  Therefore you could use code from within a host item to reference a host object by its variable name, but you cannot use similar code in the host item container to reference a host item.

For example:  Here are the start-up methods from the SDK sample for both a host item (Drawing1_Startup) and a host item container (ThisDocument_Startup).  The host item can refer on of its hosts object by a variable name; however, a host item container cannot refer to a host item by a variable name in this fashion for SDK style integrations.

private void Drawing1_Startup(object sender, System.EventArgs e)
{
    //refer to a host object by its variable name
    this.Circle1.Color =
        Microsoft.VisualStudio.Tools.Applications.Samples.ShapeApp.
        Application.CreateColor(System.Drawing.Color.Black.ToArgb());
}
 
private void ThisDocument_Startup(object sender, EventArgs e)
{
    //CANNOT refer to a host item through a variable name
    // using an SDK style integration
    this.Drawing1.Circle1.Color =
         Microsoft.VisualStudio.Tools.Applications.Samples.ShapeApp.
        Application.CreateColor(System.Drawing.Color.Black.ToArgb());
}

While it is not possible to reference host items in the same way as it is possible to reference host objects in a standard SDK style integration, it is possible to do this in ProxyShim style integration.  This is demonstrated in the Summit sample ShapeAppDynamicProgrammingModelCSharp_ProxyShim which is, like other NoRuntime samples, available upon request after filling out the information form.

For more information on the SDK Dynamic Programming Model style integration see the online MSDN documentation .