Hi,
I'm having a weird problem in the dock manager, using the latest version (2009.2). I've been using it for over a year and never experienced this before:
I have a user control which contains a dock manager. Its panes and the DocumentControlHost all contain user controls (all WPF controls - no WinForms stuff.) *Sometimes* when I open the control, the DocumentControlHost is not displayed: No tab, no content. Start the application again, and then it shows up. It might work a few times in a row, then stop again(!)
Thinking the control in the DocumentControlHost could be the problem, I created a test user control with only a textbox in it, and experienced the same kind of behaviour.
The only difference between this one and the others (which do not seem to be exhibiting this behaviour so far) is that this control is instantiated in code-behind, on demand. The others are instantiated at application startup. This one here is not used on a regular basis, so I only instantiate it on demand to save memory.
The dock manager declaration in XAML is basically the same as with my other controls (the ones that work fine), save of course for the actual controls displayed within the panes.
I've been running in circles for a couple of days now and I'm running out of ideas of what to try. The intermittent nature of the problem makes it even harder to debug (I thought I had resolved it a couple of times, only for it to reappear later...)
Suggestions?
Thanks,MIchel
Yeah, the timing issue would explain why it's somewhat intermittent - pretty much depends on how fast things are happening during a specific run, basically.
My workaround seems to be holding so far - I haven't "lost" my content pane since implementing it. For now I'll just document it in code as a workaround.
Thanks,Michel
Yes that was what I was describing. If that's what you're doing then your workaround is probably your best option for now. When I reproduced it I found it happened consistently when I had essentially set a theme on the containing usercontrol. This seems to be a timing issue relating to ContentPanes within the DocumentContentHost.
Glad to know you were able to reproduce this.
Regarding the theme: I set the theme at the ribbon level. The user controls all have a *string* property named "Theme", which ultimately binds to the ribbon's theme property. Is that what you're describing above?
Thanks for all the information. I was able to piece together a sample that reproduces the problem and will submit the issue. From the snippet it would seem that you are creating a Theme property on your usercontrol and I'm guessing you're doing this by using our ThemeManager.Theme attached property. I'm guessing you're setting the Theme on your usercontrol just as a means of propogating the Theme value and so trying to keep all the controls having their Theme set to the same value and not really expecting to use those resources for the usercontrol itself. If that's the case then one workaround may be to not use our property but define your own string property named Theme. Setting our Theme property means that additional ResourceDictionaries are being put into the resources of that UserControl and that seems to at least be contributing to the timing issue that is leading to the problem. Ultimately this is a problem in the xamDockManager and it will be addressed but perhaps this can help you to continue for now until a hotfix is available. Another option would be to set all the Theme properties to "[current]" and then setting ThemeManager.CurrentTheme in code instead.
Snoop screenshot with contentpane (this is with my code-behind work around, which creates the content pane in the user control's Loaded event):
Snoop screenshot without contentpane: This is when the content pane is declared in the XAML (but the actual user control is still instantiated in code-behind). As you can see, the tree stops at the TabGroupPane