EDIT: It looks like it has something to do with how I align my screens. If I have them aligned at top I don't see this problem, but if the screens are aligned at bottom the problem appears. 

atyon,

So far it looks like the only real difference is a the size of the shadow - just a pixel or two bigger than when not making the call to the OS API.

Opinion? Alternatives?

astoyan,

What issues should I look for if I skip the call to get DWMWA_EXTENDED_FRAME_BOUNDS? I commented out that call and just the rcClicp obtained at the top of CXTPFrameShadow::GetClipRect after passing it to ScreenToClient. I have run on my 3 monitor system and so far I get the shadow and it doesn't cover up my application window regardless of which monitor I am on.

Is Microsoft aware of the problem in their API? If so, has it been addressed? I have build 1809 with a KB fix that addresses some issues when dragging windows. But I reopened the case because when running on a desktop with the main monitor scaled but not all other monitors, the rectangle displayed when mousing down (say on a MFC toolbar that is floating) is being scaled when it should not be.

I don't see this shadow covering the application (Office 2013 themes). But, I do see the issue on CXTPResizeDialog based classes that use a frame theme with a shadow. I turned the shadow off, but these themes result in single pixel borders making resizing nearly impossible, especially on 4k monitors.

Is there any fix that I can add to my 18.5 code base?

Thanks for the clarification.

- Mark R.

Regards

Can you share any information on why some applications are experiencing this and not others?

Many thanks!

- Mark R.

Regards,

   Alexander

XTPFrameShadowManager()->SetFlags(xtpFrameShadowsDisabled);

(Or DisableShadow as you posted)

But then there will not be a shadow around the application which all other programs have. I still hope for a fix from CodeJock - it did work in 18.4.