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: 915	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: 915	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: 3 hours 6 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.