Skin Framework - ApplyColors option and RegisterClass failure

ApplyColors option and RegisterClass failure

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Skin Framework
Forum Description: Topics Related to Codejock Skin Framework
URL: http://forum.codejock.com/forum_posts.asp?TID=7827
Printed Date: 23 November 2024 at 12:17pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com

Topic: ApplyColors option and RegisterClass failure

Posted By: fbeguec
Subject: ApplyColors option and RegisterClass failure
Date Posted: 17 August 2007 at 10:40am

Hello

I have a strange problem with Skinning.
I have a piece of application with skinning turned on (autoApplyWindows TRUE, and AutoApplyThreads FALSE) that manage VST plug-ins.

Here's the problem:
- I have a dialog window in which I display a child window provided by a VST plug-in (external DLL).
- When I first show the interface, there's no problem : the VST plug-in's interface window is registered and created by the plug-in at this moment, and everything is displayed fine.
- Then I hide the plug-in's interface, the VST plug-in's destroy its window and unregisterClass, since this was the only instance of it.
- Then, finally, I show the plug-in interface, so the plug-in try registering its window's Class again and should Create the window. Actually, at this time, the RegisterClass fails, and the plug-in's interface does not create. So the parent dialog remains empty where the plug-in's interface should display.
If I do the same xtpSkinApplyColors option OFF the problem does not occur.

Since the problem is not easy to explain, I have prepared a sample based on SkinMDISample showing the problem. This sample contains copyrighted code so I can't share it publicly. For this reason I sent a private message to Oleg where I give an FTP location to download this sample with screenshot of steps to reproduce the problem.

Thanks

Replies:

Posted By: fbeguec
Date Posted: 17 August 2007 at 10:49am

Oh by the way, I could not sent Private message to Oleg, seems that PM is full.. any other way to communicate FTP details?

Posted By: fbeguec
Date Posted: 21 August 2007 at 8:53am

Hello

I finally got explanation to my problem through the support, so I think it's worth to share information here.

see below..

----------------------------------------------------------------------------------------------

Chernyahovskii, Oleg:
21-Aug-2007 2:12AM

Thank you for good description and sample.

Skinframework catches GetSysColorBrush and returns Skinned brush instead of System. So don't pass brush from SkinFramework to RegisterClass, but replace it to (HBRUSH)(COLOR_BTNFACE + 1)

windowClass.hCursor = LoadCursor (NULL, IDC_ARROW);
windowClass.hbrBackground = (HBRUSH)(COLOR_BTNFACE + 1);
windowClass.lpszMenuName = 0;

or just
windowClass.hbrBackground = 0
if you draw all client in WM_PAINT handler.

----------------------------------------------------------------------------------------------

Beguec:
21-Aug-2007 7:03AM

Hello Oleg

Thanks a lot for your analysis and solution.
So it works, but the problem is that this solution is not applicable since VST plug-ins are 3rd party products and we don't have control on source code. Most of those plug-ins use this code (provided by the VST plugins SDK from Steinberg) for creating of their window. On top of that, the number of VST plug-ins products is really huge, and we just can't ask every VST plug-in developer to recompile/re-release.

What I understand is that Windows takes care not to destroy their system Brush when Unregistering class using such brushes; and thus, my problem here is that the first UnregisterClass causes the Skinned Brush initially return by "hooked" GetSysColorBrush to be destroyed.

Maybe I'm wrong, but in the very same way, to avoid the skinned brush to be destroyed in such cases, is it possible that CXTPSkinManagerApiHook hooks DeleteObject calls on XTPSkinManager's Skinned brushes occuring when UnregisterClass is called ?

Thanks

----------------------------------------------------------------------------------------------

Chernyahovskii, Oleg:
21-Aug-2007 8:01AM

Hello,

yes its rigth. from MSDN:
hbrBackground - The system automatically deletes class background brushes when the class is freed. An application should not delete these brushes, because a class may be used by multiple instances of an application.

Yes, we already hook DeleteObject method and don't give chance to delete this brush in Application + dlls code, but we can't catch it if DeleteObject comes from user32.dll

As weird workaround you can modify SkinFramework sources to recreate brush after unload plugin.

----------------------------------------------------------------------------------------------