AvalonDock: unexpected/unreliable result of panels manual resize

[lightwalker01]

Starting from the basic example in the wiki...

Sometimes (when a document/anchorable is un-docked & re-docked?) the manual resize of the panels does not respect the position of the splitter when released.

Please watch this screen recording:

[Dirkster99]

I checked this in the currently unreleased master branch:
https://github.com/Dirkster99/AvalonDock

Nevertheless, its a good test case description so I hope you don't mind me stealing the image.

(planned release version 3.5.7) of my branch and was not able to verify this problem.

Would you please be able to cross check and let me know if you see this problem in my branch also?

[lightwalker01]

Nevertheless, its a good test case description so I hope you don't mind me stealing the image.

No problem @Dirkster99, I'm glad it's useful.

(planned release version 3.5.7) of my branch and was not able to verify this problem.

Would you please be able to cross check and let me know if you see this problem in my branch also?

I will try your branch as soon as possible...

[jogibear9988]

@Dirkster99
do you also have the fixes from here included?
if you mainatain a opensource fork of avalondock, I will remove it from my fork of the extended toolkit.
https://github.com/dotnetprojects/WpfExtendedToolkit
because I've never had time to work on this also.

[lightwalker01]

@Dirkster99
I confirm that the problem does not occur in your branch.

[Dirkster99]

@jogibear9988

do you also have the fixes from here included?

I have included the fixes from xceedsoftware/wpftoolkit. You can verify this for most commits,issues, pull requests... by browsing to a particular issue, say: Issues #1480 and checking for a reference link with my handle (dirkster99) on it.

These links get you to a pull request, issue entry, or directly to a commit, and you can therefore, see whats included and what not. I've used this pattern for pretty much all fixes applied in my branch.

You can also use the list at the bottom of the Readme.md file to track all changes that I have applied.

Are there any specific issues/fixes that I missed?

As far as removing the AvalonDock from your project goes, sounds good to me, although I am not
using the WpfToolkit as a whole so I don't mind at all.

But I know these guys (and probably others):

• sa-he
• gnimor

might be happy if you would provide a fixed WpfToolkit version that either:

1. includes my branch (via nuget) or
2. comes without AvalonDock (which simply means the consumer has to inlcude my nuget).

Either way, let me know and I'll definitely link to your repository if thats OK for you.

[XceedBoucherS]

Hi,

This is already fixed in the latest version. You can try it here : https://xceed.com/xceed-toolkit-plus-for-wpf/
Thank you.

[jogibear9988]

@Dirkster99 I've removed avalondock ;-)
And linked to your fork

[Dirkster99]

@jogibear9988
I also included a link back to your repository and will pass the word on in case anyone is looking for a stable version of the the WPF toolkit.

[Dirkster99]

Hi,

This is already fixed in the latest version. You can try it here : https://xceed.com/xceed-toolkit-plus-for-wpf/
Thank you.

@XceedBoucherS
Thank you for the information. This means we can either wait 2 years until this is available in the open source version 3.9 of the toolkit or we pay money to enyoj this resolution right now?

Well, I am really happy that we have a third free open source alternative 💯 👍 :-)