CXTPFrameShadow covers the whole application

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   Hi, 

after upgrading to 18.5 I get a shadow over the whole application when it opens on another monitor than the primary (I save window position) and call EnableFrameTheme. I found that if I set m_hOwner to NULL as suggested in http://forum.codejock.com/forum_posts.asp?TID=23639 the problem disappears, but I see that in 18.5 m_hOwner is still passed to CWnd::CreateEx? 

Should m_hOwner be NULL in this case?

The shadow causes the whole application to be unresponsive and cannot be used... 

I haven't been able to reproduce it with the RibbonSample unfortunately.

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
Fredrik Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 22 June 2005 Status: Offline Points: 235	Post Options Post Reply Quote Fredrik Report Post Thanks(0) Quote Reply Topic: CXTPFrameShadow covers the whole application Posted: 10 September 2018 at 11:34am
	Hi, after upgrading to 18.5 I get a shadow over the whole application when it opens on another monitor than the primary (I save window position) and call EnableFrameTheme. I found that if I set m_hOwner to NULL as suggested in http://forum.codejock.com/forum_posts.asp?TID=23639 the problem disappears, but I see that in 18.5 m_hOwner is still passed to CWnd::CreateEx? Should m_hOwner be NULL in this case? The shadow causes the whole application to be unresponsive and cannot be used... I haven't been able to reproduce it with the RibbonSample unfortunately.
	Windows 10, Visual Studio 20157, Toolkit Pro 18.3.0

sbinder Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 22 November 2004 Location: Austria Status: Offline Points: 76	Post Options Post Reply Quote sbinder Report Post Thanks(0) Quote Reply Posted: 02 October 2018 at 2:44am
	And only if FrameTheme is enalbed!

Fredrik Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 22 June 2005 Status: Offline Points: 235	Post Options Post Reply Quote Fredrik Report Post Thanks(0) Quote Reply Posted: 05 October 2018 at 11:24am
	Thanks - yes I know, I was able to temporarily fix the problem by calling 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.
	Windows 10, Visual Studio 20157, Toolkit Pro 18.3.0

astoyan Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 24 August 2013 Status: Offline Points: 304	Post Options Post Reply Quote astoyan Report Post Thanks(1) Quote Reply Posted: 09 October 2018 at 10:18am
	The bug has been fixed for the next update which is due in about a week or so. Please re-test with a new update once it's available and confirm it fixes it for you. Regards, Alexander

markr Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 01 August 2004 Status: Offline Points: 443	Post Options Post Reply Quote markr Report Post Thanks(0) Quote Reply Posted: 09 October 2018 at 8:13pm
	> The bug has been fixed for the next update which is due in about a week or so Can you share any information on why some applications are experiencing this and not others? Many thanks! - Mark R.

astoyan Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 24 August 2013 Status: Offline Points: 304	Post Options Post Reply Quote astoyan Report Post Thanks(0) Quote Reply Posted: 10 October 2018 at 10:09am
	It worked properly in 18.4 because it did not clip the overlapped portion of the shadow which lead to a number of performance related complains, so it's been fixed in 18.5, but the fix introduced a new issue and unfortunately it was not noticed during 18.5 build testing It happens when DPI is above 96 (100%) for DPI unaware applications only. In fact it has turned out to be a bug in Microsoft's DwmGetWindowAttribute with DWMWA_EXTENDED_FRAME_BOUNDS flag, which does not virtualize DPI as it should, which all other SDK functions do properly. This lead to a workaround being added. Regards

markr Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 01 August 2004 Status: Offline Points: 443	Post Options Post Reply Quote markr Report Post Thanks(0) Quote Reply Posted: 10 October 2018 at 7:13pm
	> It happens when DPI is above 96 (100%) for DPI unaware applications only. Thanks for the clarification. - Mark R.

rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 891	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: 25 October 2018 at 9:27am
	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?

rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 891	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: 25 October 2018 at 10:49am
	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.

rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 891	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: 25 October 2018 at 1:17pm
	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?

Fredrik Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 22 June 2005 Status: Offline Points: 235	Post Options Post Reply Quote Fredrik Report Post Thanks(0) Quote Reply Posted: 24 January 2019 at 12:04pm
	... unfortunately - this doesn't seem to be completely solved in v 18.6. If I move my application from a center screen to a left screen (with negative coordinates) a shadow appears and covers about a third of the application. It disappears if I maximize the program, but is back again in restored state. 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.
	Windows 10, Visual Studio 20157, Toolkit Pro 18.3.0