---
title: "MVVM Adapter for WPF Docking Manager"
published_at: "2012-12-19T12:22:00+00:00"
modified_at: "2022-09-07T04:46:07+00:00"
url: "https://www.syncfusion.com/blogs/post/mvvm-adapter-for-wpf-docking-manager"
excerpt: "This article explains how to adapt the Syncfusion docking manager to an MVVM application. Since our WPF Docking Manager is not an item control, it is not possible to have a traditional item-source binding to a collection of objects in..."
taxonomy_category:
  - "Development"
---

# MVVM Adapter for WPF Docking Manager

[wpf](https://www.syncfusion.com/blogs/author/wpf)

![Image](https://www.syncfusion.com/blogs/wp-content/uploads/2018/08/mvvm_adapter_f6f0217f.png)

This article explains how to adapt the Syncfusion docking manager to an MVVM application. Since our WPF Docking Manager is not an *item control*, it is not possible to have a traditional *item-source* binding to a collection of objects in the view model. This can, however, be achieved by creating a wrapper or adapter for the docking manager.

I have used a simple text-reader application to demonstrate this approach. The sample looks like this:

[file:///C:%5CUsers%5Cjawahars%5CAppData%5CLocal%5CTemp%5CWindowsLiveWriter1286139640%5CsupfilesA610A64%5Cimage19.png](file:///C:%5CUsers%5Cjawahars%5CAppData%5CLocal%5CTemp%5CWindowsLiveWriter1286139640%5CsupfilesA610A64%5Cimage19.png)

1. **1. Documents View**: The pane that lists all the available documents. The tooltip will display the path of the document.
2. **2. Properties View**: The pane that shows the properties of a document. Our PropertyGrid control is used here.
3. **3. Document View**: The pane that uses the WPF flow-document reader to display the content of a file.
4. **4. Command View**: The view has two commands: ** Open Document** and ** Exit**. Executing an ** Open Document** action will open the ** Open File Dialog**. The document you open will be added to the existing documents list. Other commands like ** Close Document** and ** New Document** can also be implemented the same way.

The project structure looks like this:

[file:///C:%5CUsers%5Cjawahars%5CAppData%5CLocal%5CTemp%5CWindowsLiveWriter1286139640%5CsupfilesA610A64%5Cimage16.png](file:///C:%5CUsers%5Cjawahars%5CAppData%5CLocal%5CTemp%5CWindowsLiveWriter1286139640%5CsupfilesA610A64%5Cimage16.png)

**Docking Adapter** The adapter is simply a user control that contains our docking manager as its content. The adapter has two properties—**ItemsSource** and ** ActiveDocument**. Binding a collection of objects to the ** ItemsSource** property will trigger a collection change in which the adapter will create a corresponding framework element (e.g., a Content control) in the docking manager, setting the underlying data context of the control to the business model.

```
<mvvm:dockingadapter itemssource="{Binding Workspaces}" activedocument="{Binding ActiveDocument,Mode=TwoWay}">
 
</mvvm:dockingadapter>
```

[file:///C:%5CUsers%5Cjawahars%5CAppData%5CLocal%5CTemp%5CWindowsLiveWriter1286139640%5CsupfilesA610A64%5Cimage%5b5%5d.png](file:///C:%5CUsers%5Cjawahars%5CAppData%5CLocal%5CTemp%5CWindowsLiveWriter1286139640%5CsupfilesA610A64%5Cimage%5b5%5d.png)

Our text-reader application maintains a collection of workspaces. A workspace can be a normal dock pane or a document pane. The adapter also maintains an interface called *IDockElement,*which maintains basic attributes needed for every dock element.

*(The text-reader application is just for the sample and contains very basic operations. This article and sample intend to showcase the MVVM support for the docking manager.)*

The adapter user control also determines the state of the element, whether it should be added to the docking manager as a dock element or document tab.

*(The adapter can be further customized to add elements as floating or auto-hidden.)*

The docking manager provides an **ActiveWindowChanged** event. Using this, the ** ActiveDocument** property in the adapter needs to be updated every time focus changes to other panes.

**Application structure**

[file:///C:%5CUsers%5Cjawahars%5CAppData%5CLocal%5CTemp%5CWindowsLiveWriter1286139640%5CsupfilesA610A64%5Cimage5.png](file:///C:%5CUsers%5Cjawahars%5CAppData%5CLocal%5CTemp%5CWindowsLiveWriter1286139640%5CsupfilesA610A64%5Cimage5.png)

The view model has a collection of workspaces that is data-bond to the **ItemsSource** property of the docking adapter. The adapter transforms the particular view model or business object into a corresponding dock element in the docking manager.

Every dock element we see in the application is a workspace. There are three kinds of workspaces: the All Documents view, the Properties view, and the Document view. The docking adapter hooks up the “active window changed” event of the docking manager; the view model receives the message whenever the active document is changed.

**Data Template** Since WPF has an implicit template approach, it is easy for us to apply visuals to the view models. In this application, the data templates are defined in **App.xaml** with only the ** DataType** attribute mentioned and not key-specified. The WPF template engine will traverse the tree and find the appropriate model type and apply the templates.

```
            
<application.resources>
            <datatemplate datatype="{x:Type local:Document}">
                <grid>
                    <local:documentview></local:documentview>
                </grid>
            </datatemplate>
            <datatemplate datatype="{x:Type local:DocumentsViewModel}">
                <grid>
                    <local:documentsview></local:documentsview>
                </grid>
            </datatemplate>
            <datatemplate datatype="{x:Type local:PropertiesViewModel}">
                <grid>
                    <local:propertiesview></local:propertiesview>
                </grid>
            </datatemplate>
</application.resources>
```

Following this approach, the docking adapter can also be treated as a normal item control and can be used in any MVVM application.

**Sample link**