CXTPPopupControl, skins and Office2013 theme
Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Controls
Forum Description: Topics Related to Codejock Controls
URL: http://forum.codejock.com/forum_posts.asp?TID=22394
Printed Date: 21 November 2024 at 9:11pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com
Topic: CXTPPopupControl, skins and Office2013 theme
Posted By: rdhd
Subject: CXTPPopupControl, skins and Office2013 theme
Date Posted: 28 August 2014 at 11:01am
|
We have a window derived from CXTPPopupControl. Originally the CXTPPopupControl::TrackMove method had code that dispatched all WM_PAINT messages near the top of the method. That code was removed a number of versions ago. while (GetCapture() == this ) { MSG msg; while (::PeekMessage(&msg, NULL, WM_PAINT, WM_PAINT, PM_NOREMOVE)) { if (!GetMessage(&msg, NULL, WM_PAINT, WM_PAINT)) break; DispatchMessage(&msg); } ... Without this code, when I move my window, especially over the ribbon area (groups area in particular), there is a constant stream of un-updated areas on the ribbon bar. The display doesn't update until I quit moving the window. It looks terrible. So we put this code into our class and that fixed this display problem. But now I think I know why this code was removed by CodeJock. If I skin the application using CJ skinning, the app locks up when I go into that loop if I have a combobox child window in the popup control. I stepped thru a ton of call frames to see why I was locking up and when DispatchMessage for WM_PAINT is called I found OnCtlColor just keeps getting called for dialog containing the combobox as the "CodeJock themed combobox" code is trying to draw the control. That is, DispatchMessage is called for WM_PAINT and I am hosed as that call never returns. If I remove that loop, we don't completely lock up when using skins but some of the controls on the popup get a constant stream of WM_UPDATEUISTATE messages as seen by Spy++. I didn't determine the exact reason or the lockup but I never got out of the "hooking" code that is redirecting the message processing. I have stepped out of the CJ call frames after OnCtlColor is called and deep into Windows code (assembly mode) and in Windows "pfnDispatch"ing code, when I try to "step out" of the frame, I get back to the CDialog::OnCtlColor where I have a breakpoint again for the same combobox. It is almost as if a hook isn't removed when it should be. So I cannot use skins due to that issue (I posted this lockup problem on the skins forums). Now I have added code to support the Office2013 ribbon theme as we have given up on CodeJock skins for now as they simply don't work with the popup window. I load the Office2013 ribbon them using "white" INI and that same popup window comes up with a transparent/translucent background and when the window is displayed, some of the static text boxes are corrupted - they pick up pixels of what is under the static text window's background when it first displays and that data remains for the life of the window (moving doesn't fix the display but it doesn't cause more pixels from under the window to be pulled into the popup window either). This occurs even if I have our OnLButtonDown code call the CXTPPopupControl::OnLButtonDown and/or have our TrackMove method just call the CJ TrackMove method (and then return without executing any of our code). Note I have no such issues using the Office2007 ribbon theme (blue, black, silver or aqua). Also on the dialog we insert into the popup, we implement OnCtlColor and set the background for static text objects to be transparent. I don't think CJ is handling static controls with a transparent background set in OnCtlColor appropriately. So it appears that CJ has problems drawing a popup bar using the Office2013 white ribbon theme. I have examined the INI file but I don't see what setting CJ is using that is affecting my popup control, which isn't even on the ribbon to begin with. I have never noticed any other themes affecting this popup window. Our popup window is not a window on the ribbon. We display it in our viewing area and it hosts dialog boxes used by some commands. In fact, we have support for the window being a layered window and whatever CJ is doing, my calls to Windows to set the layered attributes no longer have an effect when running with Office2013 white. Even if I don't set the attributes or the layered window style, the background is not displayed and my text objects have their display corrupted. So why does the Office2013 white theme affect my popup window? And more importantly, how can I avoid having that window affected by this display problem? Why did CodeJock remove that loop from their TrackMove method causing the update issues we see if we don't put the code back and what can I do to fix that problem too without causing skinning to lock us up? |
Replies:
Posted By: rdhd
Date Posted: 28 August 2014 at 11:08am
|
By the way, here is a snapshot of the Office2013 effect and the popup window with the corrupted display. I originally moved the window over the ribbon. We remember the position. That way the next time I ran and displayed it it initially displayed over the ribbon. You can see that the background of the popup has the contents of what was under it (After initial display I moved the window down from the ribbon and slightly to the left from its first displayed position - you can see the icons etc. that were under it before moving it). |
Posted By: rdhd
Date Posted: 28 August 2014 at 11:11am
|
Posted By: rdhd
Date Posted: 28 August 2014 at 11:13am
|
Sorry about that. The second post looked just fine but after I posted and saw the post, I see my image is not available. I tried again and instead of using control-v to paste in my image, I used the CJ control to upload an image. In that dialog, the image looked good but now I see a very small image. I hope you can get to the image and display at a resolution that shows the problem with my popup window! |
Posted By: rdhd
Date Posted: 28 August 2014 at 1:54pm
|
It looks like deadlock. I have one thread doing this: ntdll.dll!NtWaitForSingleObject Unknown KernelBase.dll!WaitForSingleObjectEx Unknown nvoglv64.dll!0000000068feaf9a Unknown nvoglv64.dll!0000000068eedccb Unknown nvoglv64.dll!0000000068eef57c Unknown nvoglv64.dll!0000000068feaad9 Unknown > ToolkitPro1631vc110x64UD.dll!CXTPSkinManagerApiHook::ThreadProcHook Line 1297 C++ kernel32.dll!00000000770059ed Unknown ntdll.dll!RtlUserThreadStart Unknown Meanwhile the main thread is waiting too: user32.dll!ZwUserGetMessage Unknown user32.dll!GetMessageW Unknown > cmdsptd.dll!SEActionHandlePanel::TrackMove Line 1681 C++ cmdsptd.dll!SEActionHandlePanel::OnLButtonDown Line 2160 C++ SEActionHandlePanel is one of our CXTPPopupControl derived windows that we have that uses the original PeekMessage/GetMessage/DispatchMessage code to avoid the display issues that come about when CJ removed that code from CXTPPopupControl::TrackMove. Sometimes I can move the window and sometimes not. Sometimes I can move it a bit and have no lockup and then move it again and it locks up. Sometimes after it locks up for a while it will start tracking again. Quite unpredictable. Is this a hooking and threading issue? |
Posted By: rdhd
Date Posted: 28 August 2014 at 3:17pm
|
Well at least I solved the issue with the transparent background. We were using the command bars paint manager and calling LoadImage to load "RIBBONGROUPS" and then using that image for our background. That call fails when using Office2013 (white) ribbon theme since that image is not in the DLL. We'll need to find another way to paint our background so our window appears to be "themed" along with the app. |