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
I'm home now, so just working from memory:
I have a XamRibbon and one of the buttons is used to call that specific function. As we speak, the code-behind instantiation (the stuff I put in an earlier post here) is just in the Clicked event of that button (I know, this should really go elsewhere - I'm still just doing the general plumbing.) That Clicked event is in the code-behind of the application's main window, which contains the ribbon and the various user controls that display whatever functionality the user selects (a two-row grid, basically.) Now the code that instantiates the content pane, I moved from that clicked event to the loaded event of the UserControl (the one that contains the dock manager.) "So far, so good".
So we have:
MainWindow (Window control)-----Grid ---- Ribbon (grid row 0) ---- UserControl (grid row 1)
Grid row 1 actually contains several user controls, but only the currently selected one is visible at any one time, the others are collapsed. The two that are used all the time are declared in the XAML for MainWindow and instantiated at load time - I don't have any problems with the dock manager in those. The other ones are "rarely" used, which is why I'm only instantiating them on demand. This is where I have a problem. So... Answer to the last question: A grid is the parent of the UserControl that contains the misbehaving dock manager.
Tomorrow I'll put the code back in place to reproduce the problem (assuming my current workaround still works anyway :)) and take a couple of screen shots of the visual tree in Snoop. Maybe that'll help you more than me trying to word this stuff here.
Thanks,Michel
Knowing that the ContentPane is not in the visual tree is actually a big help. I'll try to see if I have any luck reproducing the issue. To try and ensure I try the right steps, in what event are you creating that UserControl (the one that contains the xamDockManager whose ContentPane in the DocumentContentHost is disappearing) and what are you eventually parenting that UserControl into (e.g. a tab item's content, the content of a window, the content of a page, etc.)?
The sample could take a while - we're beyond late as it is, and I've already spent nearly two days on this little problem alone. In fact if my latest workaround stops working, I may have to drop the dock manager altogether for this specific part of the application... Not something I want to do.
Re: Snoop. I tried that, and it's interesting: The element is not there at all. I could find the splitpane and the tabgrouppane, but there was nothing underneath, and both had visibility="Collapsed" (this is why I hardcoded the visibility in each element above - I was trying to see if it would help.) The actual content pane was not there, nor, of course, was the content of the content pane.
Well when you have time and can provide a sample then I can try to look into it. Also, if you can get it to happen on your system it would be helpful to run Snoop, Mole or some other element viewer tool to inspect the Visual Tree of the DocumentContentHost to see if the element is not there and if it is (which I suspect it would be), what its ActualWidth, Width, Visibility, IsVisible, etc. are for the usercontrol, the containing contentpane, etc.
OK scratch that... I torture-tested it a bit more and it's still happening, just not as much.
I've now moved that code so that it is called by the Loaded event of the user control that owns the dock manager, where in theory at least the dock manager is probably more keen on getting a document added. I hope that does it, I've got real work to do too. :(