OS common file open dialog partially skinned

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

   I'm seeing this in our product. When skinning is disabled the OS File Open dialog has the command bar a the top that has "Orginaize", "New Folder" and other buttons like the Help button on it. That part of the dialog is skinned.

Run the CJ SkinSDISample to duplicate the issue. Click the Open Dialog button with iTunes or Le5 enabled. Choose to not skin the dialog. You will see the issue then. I don't know how this is occurring as the window is a DirectUIHWND class and it is created each time the dialog is.

It appears that the OS is detecting system color changes introduced by the skin. Disabling skinning using the API calls made in the sample appears to only avoid hooking windows. We have customers complaining that this part of the open dialog is skinned.

What's the work around? I suspect changing system colors will result in WM_SYSCOLORCHANGE being broadcast to all windows which may then redraw without the expected skin colors.

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
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: 919	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Topic: OS common file open dialog partially skinned Posted: 26 March 2025 at 12:15pm
	I'm seeing this in our product. When skinning is disabled the OS File Open dialog has the command bar a the top that has "Orginaize", "New Folder" and other buttons like the Help button on it. That part of the dialog is skinned. Run the CJ SkinSDISample to duplicate the issue. Click the Open Dialog button with iTunes or Le5 enabled. Choose to not skin the dialog. You will see the issue then. I don't know how this is occurring as the window is a DirectUIHWND class and it is created each time the dialog is. It appears that the OS is detecting system color changes introduced by the skin. Disabling skinning using the API calls made in the sample appears to only avoid hooking windows. We have customers complaining that this part of the open dialog is skinned. What's the work around? I suspect changing system colors will result in WM_SYSCOLORCHANGE being broadcast to all windows which may then redraw without the expected skin colors.

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: 919	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: 23 hours 12 minutes ago at 2:00pm
	Just in case I implemented IXTPSkinManagerWindowFilter and set a filter. The file open dialog contains a DirectUIHWND class and I filtered that out. Though I see the class name passed in as I open the dialog the top of that window that has "Organize ... Help" still is skinned. So whether I disable skinning before bringing the dialog up or try to filter out the window the skin persists. I'm debugging and I see that even though I turned off skinning the CXTPSkinManagerDetoursApiHook::OnHookGetSysColor is still active and there is no check for disabled skinning. The OS file open dialog is making calls to get system colors and CJ is returning system colors. I see calls to that api to get CLR_BTNFACE and CLR_HOTLIGHT when I move over "Organize" which is why this OS dialog is "partially skinned". How do I avoid this problem? Modify CJ code seems to be the only option I have unless I haven't found a way to unhook the hook when I turn off apply new windows/threads.

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: 919	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: 3 hours 23 minutes ago at 9:49am
	I resolved this issue though I'm not thrilled with how. I had to go to the Y:\Codejock\Source\SkinFramework\ApiHook\XTPSkinManagerDetoursApiHook.cpp source code and add code to a number of hook functions to do default processing if I have disabled skinning when I bring the file open dialog up. I did that in all the "theme" related hooks, GetSysColor, GetSysColorBrush and GetModuleHandle(W) hooks too. I still have a gripper issue though so I must have missed something, probably related to an image. It would be great if CodeJock would provide a real fix.

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: 919	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: 26 minutes ago at 12:46pm
	I have been unable to determine why the gripper is messed up when I run the File Open dialog with skinning temporarily disabled (same issue shows up with SaveAs). So I decided to look at other apps. I found the issue with the gripper I see can be duplicated by running the Visual Studio Save As dialog. I have a custom desktop theme applied and the problem shows up depending on what monitor I bring the dialog up on and most likely on the DPI settings. I'm also running remote desktop with both machines having three monitors (RD setting is to use all monitors on the machine to which I am connecting). My laptop is scaled at 125% while my desktop is scaled at 150%. The custom theme I have is using Microsoft's Aero msstyles file in the Windows themes folder. So the remaining issue I have after changing the hookers isn't a CJ issue but rather an OS one. So ignore my comment in the previous post regarding the gripper still being an issue which I thought/implied was a CJ issue.