Critical: ToolWindow is not inheriting DataContext anymore

Docking/MDI for WPF Forum

Posted 9 years ago by Radu
Version: 10.2.0530
Platform: .NET 4.0
Environment: Windows 7 (32-bit)
Avatar
This is a critical bug!

ToolWindow is not inheriting DataContext anymore.

We used as a workaround DataContext="{Binding}" for each of our ToolWindows.

And a question: since some time we noticed there are several DataContext switches for the ToolWindow (null, then the correct one, then again null, etc). Can't this be fixed too?

Comments (6)

Posted 9 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Radu,

Thanks, we've corrected this for the next maintenance release. Which we hope to get out tomorrow.

As I mentioned earlier, this will not correct the DataContext getting set to null then restored, as that is a separate issue which due to value inheritance. As you move things around the visual tree (such as ToolWindows), they must be temporarily disconnected from the visual tree. So their DataContext may get temporarily disconnected as well.

The only current workaround is to explicitly set the ToolWindow DataContext, versus using any inherited values.


Actipro Software Support

Posted 9 years ago by Radu
Avatar
Thank you!
Posted 9 years ago by Radu
Avatar
The initial issue seems to be fixed (DataContext gets inherited now) but I feel now it is killing an eventual DataContext="{Binding ...}" set for the ToolWindow (basically the case when you don't want to inherit).
Posted 9 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Radu,

Could you please put together a small sample project that reproduces the issue and email it over to our support address?

The one reproducible case where the DataContext/Content was getting cleared was corrected by the latest maintenance release, so we'd need the sample project to troubleshoot the issue. You may be able to add a handler to the DataContextChanged event on the ToolWindow in question, and see from the callstack where it's getting cleared.

Keep in mind that the DataContext would get temporarily null-ed out as you move the ToolWindow around the visual tree. This is due to the fact that's it's being detached, then reattached to the visual and logical trees, thus temporarily preventing the binding from find the source.


Actipro Software Support

Posted 9 years ago by Radu
Avatar
More details: the ToolWindow has a DataContext specified and it is initially hidden (autohide). Making it visible and then docking it causes losing DataContext
Posted 9 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Radu,

The DataContext property is not a reliable way to pass a context down to the content of a DocumentWindow or ToolWindow. Mainly because DocumentWindow and ToolWindow are not a visual parent/ancestor of it's content. Instead, these types are only visually responsible for their associated tab, or in the case of standard MDI, their window. The content of the selected window is displayed by an associated container, such as TabbedMdiContainer, RaftedDocumentWindowContainer, or ToolWindowContainer.

Because the DocumentWindow and ToolWindow are not visual parents/ancestors of their content, their DataContext is not generally inherited down. Instead the DataContext of the container is inherited by the content. But it appears in the case of auto-hidden windows, the DataContext of the tool window is inherited.

In the following code, it may be expected that the TextBlock would display the string represented by StringValue (assuming the DataContext has been properly set on the associated Window/Page):
xmlns:shared="http://schemas.actiprosoftware.com/winfx/xaml/shared"     
xmlns:docking="http://schemas.actiprosoftware.com/winfx/xaml/docking"     
...
<docking:DockSite>
    <docking:DockSite.AutoHideLeftContainers>
        <docking:ToolWindowContainer>
            <docking:ToolWindow Title="DataContext Test" DataContext="{Binding StringValue}">
                <TextBlock Text="{Binding}" />
            </docking:ToolWindow>
        </docking:ToolWindowContainer>
    </docking:DockSite.AutoHideLeftContainers>
    ...
</docking:DockSite>
The above code may work initially, but the DataContext on the ToolWindow will get cleared when it is pinned or docked. As a result the TextBlock will no longer display the proper string.

Rewriting the code above, like so will correctly display the approriate string in the TextBlock in all instances:
xmlns:shared="http://schemas.actiprosoftware.com/winfx/xaml/shared"     
xmlns:docking="http://schemas.actiprosoftware.com/winfx/xaml/docking"     
...
<docking:DockSite>
    <docking:DockSite.AutoHideLeftContainers>
        <docking:ToolWindowContainer>
            <docking:ToolWindow Title="DataContext Test">
                <Grid DataContext="{Binding StringValue}">
                    <TextBlock Text="{Binding}" />
                </Grid>
            </docking:ToolWindow>
        </docking:ToolWindowContainer>
    </docking:DockSite.AutoHideLeftContainers>
    ...
</docking:DockSite>
The DataContext is now set on the root element of the content, instead of the ToolWindow. The Grid can inherit it's DataContext from the container or the tool window and still properly resolve it's binding.

We've added a troubleshooting topic on this matter in our documentation.


Actipro Software Support

The latest build of this product (v2019.1 build 0683) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.