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?

Hello Edo,

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.

Hello Edo,

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?

Hi Andrew,

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.

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 10
2. 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 panel
2. Release mouse to apply
Expected: panel resized to new position
Actual: 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.