Shared Classes Diff Instances

[Adrian Verkuil]

Hi Guys,

According the SDK different instances of the same application can share a registered class, however they should not register a class that has already been registered bye a previous instance.
I tested this with 30 instances without checking and runs fine, but just to be sure I made this:

FUNCTION AvClassExist(ClsName As String) As LONG
LOCAL TmpWc as WNDCLASSEx
FUNCTION = GetClassInfoEx(hInstance, ByVal STRPTR(ClsName), TmpWc)
END FUNCTION


IF ISFALSE AvClassExist ("MyClass") THEN create it!

Question is, is this needed how should we reed SHOULD NOT?

Whitout the check it runs fine , but then windows register 30 classes ?,
would be stuppid if you ask me, so I really think they have something like above already running ?

[Edwin Knoppert]

This has changed for 32bit apps.
Afaik you can not share a window class among processes.

[Michael Mattias]

I can't find that restriction in my SDK , but let's just look at it logically.....

The bottom line is, your code is absolutely correct...

"If this class is not valid in this process (GetClassInfoEx), make it so (RegisterClassEx)"

I would not be surprised if Windows does something similar on RegisterClassEx... it does do that kind of thing for many other system objects. But you could check the return of RegisterClassEx to see if it errors out if the class was already registered in a previous instance of your application.

Maybe it has something to do with the use of the CS_GLOBALCLASS class style in your WNDCLASSEX structure (code not shown)?

[Adrian Verkuil]

MM
Already did that in both cases it runs ok so no error and there is no
GLOBALCLASS set .
Maybe that is what they mean bye "SHOULD NOT" it works but better do this!
Anyway MM just wondered what happens behind the curtains.

[Michael Mattias]

You know, this "should not work but does" might just be... if you are on Windows 9x rather than an NT-class system, the GDI is still the "hybrid" version and the class objects might be shared. Meaning, failure to register in each instance will work fine on Win/9x and fail miserably on NT+

(Operating system and compiler/version not shown).

It's a thought, anyway.

[Edwin Knoppert]

No..

People tend to forget that windowclasses are bound to an instance.
The callback is in an instance of an exe or dll.
The global class style is misused in most cases.

I already mentioned to PB inc that DDT does not support window creation if the class is in a dll and not set to global.

Global had a totally different purpose under 16bit as it's being used now.

32 bit apps register their own set of standard controls.

[Adrian Verkuil]

Ok MM and Edwin ,

Just forgot some details again (Os WIN-XP, Q6600, 4GB, GT-8800)

Tested the following with Mainclass Styles:
%CS_BYTEALIGNCLIENT or %CS_BYTEALIGNWINDOW or %CS_VREDRAW or %CS_HREDRAW

Then register a superclass "Myclass"

Same proggie run 30 instances without my test, and with the test.

No errors without test does 30 times register "Myclass" ?

Then with test only the first instance does a register the other 29 runs fine.

Question is what happens without the test really ?

Testcode again:
FUNCTION AvClassExist(ClsName As String) As LONG
LOCAL TmpWc as WNDCLASSEx
FUNCTION = GetClassInfoEx(hInstance, ByVal STRPTR(ClsName), TmpWc)
END FUNCTION

IF ISFALSE AvClassExist ("MyClass") THEN create it!

[Michael Mattias]

>Question is what happens without the test really ?

No, the question is, "who cares?"

Windows is essentially "all virtual everything" so what happens "under the hood" is both immaterial and subject to change without notice.

I'd probably just register the class in the application without checking anything: I know that works. Good enough for Mr. Petzold, good enough for me.

MCM