I use XamDockManager and have some DockPanels (left, right, and bottom of the content)..
The problem is when I try to resize panel (by using mouse drag on DockedPaneSplitter), it intermittently cancelled (do nothing).When it occurs and I check DockedPaneSplitter_DragCompleted event, the e.Canceled is true.
From the test, this problem only occurs when all these conditions are true:1. Monitor DPI is different between primary and second monitor (I change [Display > Scale and Layout] to 175% to reproduce this)2. Application is not on primary monitor (put application on second monitor)3. HwndHost is set as content in our DockManagerPanel
Additional info: I am using dual monitors and run the application on my second monitor in Windows 10.
Please let me know what can caused resizing panel to be canceled, and how can I prevent this to happen.
stack trace when this issue occurs.
Hello Edo Gasali,
Thank you for making a post to our forum.
I'm afraid to say that I am not sure whether or not I clearly understand what you mean by "3. HwndHost is set as content in our DockManagerPanel".
Could you give us an isolated, executable and reproducible sample which is made as simple as possible so that we can also see your issue on our side?
Thank you very much for providing the sample.
I downloaded it and could buid it on my side. I'll start the investigation with this sample.
This is a quick note to thank you. I'll let you know when there is any update about this matter.
We've been trying to reproduce your issue, but so far we haven't been able to if we exactly follow the steps to reproduce.
If you change the DPI, Windows warns you that some applications won't behave themselves expectedly, and if you want to avoid it, Windows requires you to restart applications or sign out and then sign in the Windows again.As long as we follow this requirement by Windows, the issue is not reproduced on our side.
Could you double-check whether the issue becomes not to be reproduced if you follow this requirement?
I don't have warning when change display using scale and layout.
However, I have tried to restart computer after change it, and I can still reproduce the issue.
Video recording showing the issue: https://gofile.io/?c=49PGSZ
We haven't been able to reproduce the issue but I'm wondering if this is related to your reparenting the hwnd from a different process into your window. Are you able to reproduce this with an HwndHost that contains an hwnd belonging to your application's process? e.g. WebBrowser or WindowsFormsHost.
With regards to the drag being cancelled, the PaneSplitter is just a derived WPF Thumb and listens for its DragCompleted event. If WPF is raising that with the Canceled property of the event args set to true then it will cancel the splitter move. Perhaps you can try to debug why that is happening - e.g. evaluate the callstack of the DragCompleted since you mentioned seeing the Canceled was true. Maybe something else is capturing the mouse.
I tried to use WebBrowser, and the issue still occurs.
I posted the call stack on my second post (it is from my original app, not the small app - but I think it will be similar), most of them are coming from .NET framework.
From the call stack it seems Thumb.OnLostMouseCapture() triggering Thumb.CancelDrag(), but I don't know why that happens.
Sorry I must have missed the callstack you listed. Capture could have been cancelled because the window was deactivated or because something else captured the mouse or something else caused mouse capture to be released. Perhap you could try looking up at the FilterMessage item in the callstack and try to see what message is being processed or use spy++ or add an HwndSourceHook to your window's HwndSource. It's likely a WM_CAPTURECHANGED so maybe start by looking at the Mouse.Captured. If it's another element then presumably that element requested capture. If it's null then try using interop to call the GetCapture api to see which window took mouse capture if any.