Print Page | Close Window

shadow causes windows to disappear

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Toolkit Pro
Forum Description: Topics Related to Codejock Toolkit Pro
Printed Date: 17 January 2021 at 11:21pm

Topic: shadow causes windows to disappear
Posted By: rdhd
Subject: shadow causes windows to disappear
Date Posted: 01 April 2019 at 10:06am
We have a modal dialog that lets the user change themes. When we use an office 2013 theme such as white or dark grey, if the frame is not maximized, the frame window updates over the top of the modal dialog. This occurs when CXTPFrameShadowManager::EnableShadow is called. The call to pShadow->Create is what causes this to occur. The modal dialog isn't the only window in our application that is affected. Floating docking panes also disappear behind the application window.

We are on version 18.5.

Posted By: rdhd
Date Posted: 01 April 2019 at 11:01am
I modified the Samples\Ribbon\RibbonSample project. In CMainFrame::OnViewOfficeTheme I added this code:

    CThemeDlg dlg(this);
        XTP_EXCLUDE_THEME_OFFICE2000       |
        XTP_EXCLUDE_THEME_OFFICE2003       |

    // set startup theme


In OnInitDialog I also added a call to EnableAutoPreview(TRUE);

The result is the same as I see with our application. If you make changes to the style, the application jumps on top of the dialog. Bitten by the shadow code once again. Float the "Styles" docking pane and I see it too disappears behind the application window.

As we have had issues before with shadows, I had looked at this ribbonsample code and fashioned our sequence of calls to manipulate the theme the same way the sample did. So we first call the ribbon bar EnableFrameTheme(FALSE) and then call it again later with TRUE (for our app it is always enabled). Now I find that I need to skip the first call to set FALSE. I can do that in our app and the sample and the windows remain as they should. I have a long comment in our code outlining all the issues making these calls "fixed". So I have to start testing what will break if I make this change to work around yet another shadow problem.

Posted By: Fredrik
Date Posted: 01 April 2019 at 3:24pm
Did you patch XTP with the fix from" rel="nofollow -  to set m_hOwner to NULL in CXTPFrameShadow::Create? We just had the problem that 8 out of 10 users on a course had the problem with shadow covering the application so I tried the fix with setting m_hOwner to NULL. But this caused similar effect as yours: after creating another frame window from the main application and closing it, the main application won't appear top most anymore even if you try to activate it. We don't have this problem with 18.6, but the problem with the shadow covering the application is still there.

Windows 10, Visual Studio 20157, Toolkit Pro 18.3.0

Posted By: rdhd
Date Posted: 01 April 2019 at 4:42pm
Hi Fredrick,

No, I never modifed that code. m_hOwner is passed thru CreateEx.

Posted By: rdhd
Date Posted: 05 April 2019 at 10:08am
It turned out my "fix" isn't comprehensive. We still have issues with disappearing windows that float (not just docking panes) if the user simply resizes the application. I have to completely disable the shadow code (again) to avoid the issues. Why is the shadow so hard to implement by CJ?

Posted By: cpede
Date Posted: 10 July 2019 at 3:43am
I think I also reproduced this in the CommandBarSample. When using the Options to first disable Frame Theme and the again use it to enable Frame Theme the entire application turns faded black, and unresponsive.

Product: Xtreme ToolkitPro (19.1.0)
Platform: Windows 10 (x64)
Language: Visual Studio 2017 (C++)

Posted By: rdhd
Date Posted: 10 July 2019 at 8:15am
Covered by the shadow window? Sounds like it might be. I looked at Microsoft Visual Studio's shadow. It is actually 4 windows fashioned just around the edge of the app.

Print Page | Close Window