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.
Thanks,
Edo
Has a fix been found for this? I'm running into the same issue on version 18.1.
I just re-read my first post and I think I was not clearly give steps to reproduce, my bad.
Environment:1. Windows 102. Use different display scale on 2nd monitor, example Second monitor 3. Application located on the second monitor
Steps:1. Hold and drag splitter to resize panel2. Release mouse to applyExpected: panel resized to new positionActual: Panel doesn't resized
So to answer your question above, yes I did left mouse up (step 2).
Sorry for the confusion before, I sometime have problem writing explanation details in English.it actually not canceled while dragging the splitter.but: after dragging (after mouse up), the pane resized doesn't applied.
Hopefully you can reproduce this issue using steps above.We have tried to some computers/laptops here and all can reproduce.
Cheers.
But the WM_CAPTURECHANGED is after the WM_LBUTTONUP so either you released the mouse button (or the system thinks you did) or you're looking at the messages that occurred after the DragComplete was raised.
Please ignore my comment above, I will show Spy++ instead.
Following is when DragCompleted event triggered and issue occurs.Notice that WM_CaptureChanged doesn't get return value.
Compare to this following normal scenario, when issue doesn't occur.On the last line, it has R WM_CAPTURECHANGED (the return value).
I am not sure why it only intermittently(often) fails when using display scaling in second monitor.
I'm not sure I follow. Perhaps you are looking at the WM_CAPTURECHANGED when it first took capture as opposed to when its losing capture? The DockedPaneSplitter is a derived WPF thumb. When WPF is raising the OnLostCapture for the thumb presumably capture has been shifted elsewhere or WPF thinks it needs to cancel capture. I was suggesting trying to look up the callstack at the FilterMessage and try to see which message was being processed at the point when DragComplete was raised for the cancel or if the locals of the FilterMessage is optimized away then perhaps using spy++ or an hwndsourcehook to log the messages coming in so you can try to see why WPF is raising that event with a cancel. I'm not sure this will ultimately provide enough information to workaround the issue but it may be possible.