The DockingManager in V3.4 does not always cover the assigned content area (eg Window)

[Dirkster99]

It is possible to move GridSplitter out of the MainWindow and then resize the Window such that the DockingManger does no longer cover the complete assigned content (window).

[nonsensesoftware]

It's pretty crazy that something this fundamental to the control doesn't actually work, especially when they don't obey their own properties. If you look at my attached image, the DockMinWidth property is set to 25. How it is that through resizing the LayoutAnchorablePaneGroup, I'm able to set the DockWidth to anything lower than 25? This is a pretty fundamental feature of the AvalonDock, and it doesn't work.

[Dirkster99]

Did you see the log4net branch that I also maintain(?):
https://github.com/Dirkster99/AvalonDock/tree/Log4Net

We should use it to trap the statement that changes the DockWidth and better understand the root of this issue - what do you think?

[nonsensesoftware]

I'm not familiar with Log4Net, but if this is something you feel we should use, then let me know what I can do to help you.

The underlying issue is pretty deep and it fundamentally does not work as I believe it should (i.e. not obeying the bounds of the window, allowing panes to be pushed off the window because of the grid splitter, etc). This is also an issue in v3.7 (premium trial) version.

[Dirkster99]

The log4net logging facility is quit simple - here is a short description to get you started:

• Download the branch

• Compile and execute MVVMTestApp as it is
  -> This will write a log4net file into your %temp% folder
  -> You can use any log4net tool to view the output (eg: https://github.com/Dirkster99/YalvLib)
  -> The detail of your output is configured in the App.config file (line 33):
  https://github.com/Dirkster99/AvalonDock/blob/Log4Net/source/MVVMTestApp/App.config
  All outputs all types of output (Info, Fatal, Error, Warning etc...)
  Error outputs only errors or fatal errors and so forth

• The code in DockingManager.cs shows you how you can generate the output

You need the static Logger in line 44 to get a facility to spin up for that class:

protected static readonly log4net.ILog Logger = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);

From there, there are multple API logging methods you could choose. I usually use: Logger.InfoFormat("{0}", "This is a test"); if I want to check up on a state - you can use this just like Console.WriteLine() but be carefule to not insert additional Null Pointer exceptions or such :-)

You can also use:

try
{
  throw new Exception();
}
catch(Exception exp)
{
  logger.Error(exp);
}

To log exception as such in the log file - they are highlighted red in the viewer and doing so can be better in terms of performance since you are not required to log the Info log levels as well - but try the info level and stick with it if it is fast enough for you as I already added a few logging statements in the branch...

We can also work the other way around, if thats too much work, I just need to understand the problemin more detail... I understand the DockMinWidth in the LayoutAnchorablePaneGroup is somehow changed and we do not know how.

The class derives through the abstract class LayoutGridControl
from Grid.

But the DockMinWidth is implemented in LayoutPositionableGroup.cs.

So, I would start using an Logger.InfoFormat("Before {0} After {1}", _dockMinWidth, value); statement or 2 into the setter of the DockMinWidth property - I would use something similar in all places that access the property in terms of writting or resetting it.

Then, testing and using the logger output should give you more insides as to what action is causing what change and which one is not the one you want. Have a try with this and let me know if you get stuck and whether my understanding of the problem is correct. I might take a look at this with the logger if that helps you understanding the problem behavior more accurately...

[nonsensesoftware]

I would ignore almost all of the changes I've added in as pull requests, and they are simply stop-gaps to show other developers who are using the 3.4 what to modify in order to not cause AvalonDock to crash. My fixes aren't technically taking care of the root cause, which I believe is something should aim to do.

From what I've seen, there are several issues here, which all really boils down to one thing: When using the GridSplitter, in certain cases, it allows the user to drag content past the application/container window bounds. I haven't really dug in to the code apart from the small parts where I could easily fix specific crashes that I am experiencing (as I mentioned, stop-gaps). What I am getting at here is that if, fundamentally, the GridSplitter didn't allow content to be moved out of the main application window or container window, then we probably won't need to have the other changes that I implemented in the interim, such as the pull request #1393.

I'll take a look at it over the next week or so, using the information you gave me with log4net to log specifics so I can get a grasp on the actual code and where things are changing when they shouldn't.

[XceedBoucherS]

Hi,
Can you attached a WPF Sample so we could test the exact same behavior as you ?
I can see you are dragging the AutoHide1 Panel to the right, but until where ? Past the DockingManager window, past the monitor ?
What is the result ? Which Panel gets shorter than its MinDockWidth ?

Thank you.

[nonsensesoftware]

I'll try and create a sample to reproduce the issue in a .NET WPF application based on the current release of AvalonDock v3.4, but it might be a few days to a week before I can get it uploaded,

However, I don't believe that this is due to the fact that they are in AutoHide Panels, because an application I am developing doesn't use auto-hide content. Basically, any control that uses the LayoutPositionableGroup as its model (from what I've tested) has the potential to be affected by this bug. The controls that I can tell that use this base control is: LayoutPanel, LayoutDocumentPaneGroup, LayoutDocumentPane, LayoutAnchorablePaneGroup, LayoutAnchorablePane, and LayoutGridControl.

There are several places where it can be dragged past. A few cases from my testing:

• Dragged past the bounds of the application window
• Dragged into the bounds of another LayoutAnchorableGroup (placing a control behind it)

Many controls do not obey their MinWidth properties, especially in the cases described in this issue.

[XceedBoucherS]

Hi,
Using v3.4, here's a code snipet.
It contains a LayoutDocumentPaneGroup and a LayoutAnchorablePaneGroup.

Upon running, you can drag the splitter to extend the LayoutDocumentPaneGroup to he right, but it will stop when the LayoutAnchorablePaneGroup reaches its DockMinWidth of 75.
1381.txt

``

[nonsensesoftware]

Run the project TestMVVMApp in the zipped solution and repeat the steps in the zipped video (IssueWithDock.zip)
to see how to reproduce this. This isn't just limited to this layout configuration, there are plenty of others that will do it as well.
AvalonDock-master.zip
IssueWithDock.zip

[XceedBoucherS]

Hi,

Thank you for the sample and video.,
This will be fixed in v3.8.