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?

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.

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. 

Sorry for the delay, was busy for release.

I tried to add hook and filter for WM_CAPTURECHANGED as suggested. And the mouse captured element is the {Infragistics.Windows.DockManager.DockedPaneSplitter}

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.

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.