Registered Classes and Multiple Instances

[dedndave]

i am curious about what happens when you run multiple instances of a GUI app that register the same window class ???
can't really find any specific poop on MSDN

so - hInstance is different, but the class name is the same
i was thinking that the class name had to be unique
is it like this ?

the class name AND hInstance combined make the class unique ?

[dedndave]

ok - i found some info...

http://msdn.microsoft.com/en-us/library/ms633574%28v=vs.85%29.aspx#system

now, i have another question...

in the documentation for CreateWindowEx, it says that lpClassName is optional
however, i cannot find anything about using NULL as a value
what happens if i do this - or - when would i want to ?

[qWord]

I'm sure, that 'optional' means that it can either an string pointer or an class atom.

[dedndave]

usually, it means the parm is not always required
i dunno   :(

[MichaelW]

I think it generally means that the parameter can be NULL, see Header Annotations

But in my test under Windows 2000 passing a NULL in lpClassName, for an application window or a control, prevented the window from opening.

Perhaps within Microsoft there is some disagreement as to what it means, with some interpreting it to mean that a parameter has more than one option.

About Window Classes

Under Class Name:

"Because window classes are process specific, window class names need to be unique only within the same process."

[dedndave]

i suppose it could just be an error in the docs, too   :P
but - i was thinking there may be some special case where NULL is valid
like when you have a window with no class   :lol

(need i say it ? - i had a gal like that, once)

[Twister]

Build and run.

Code Select Expand

include \masm32\include\masm32rt.inc

.data

szWindowName db "Window Test", 0
        hwnd dd 0

.code

start:
invoke CreateWindowEx, 0, NULL, offset szWindowName, WS_OVERLAPPEDWINDOW, \
CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL, FUNC(GetModuleHandle, NULL), NULL

      mov hwnd, eax

      invoke MessageBox, NULL, LastError$(), NULL, MB_OK OR MB_ICONINFORMATION

      invoke ShowWindow, hwnd, SW_SHOWNORMAL
      invoke UpdateWindow, hwnd

      invoke MessageBox, NULL, LastError$(), NULL, MB_OK OR MB_ICONINFORMATION

end start

[dedndave]

i understand that - but, that does not mean that it would always be the case
it may be that one of the other parms must be "something something" in order for it to be valid or meaningful
there are too many combinations to try
i find it a little surprising that there are no remarks in the "community content" section of the MSDN doc page, though
generally, the docs would tell you that it may be NULL, and explain what happens (when optional is specified, i mean)

it isn't important, really - i am just trying to learn about GUI apps   :P

[baltoro]

I think alot of the problem is that most of these structures and associated data (even for GUI) are maintained by the kernel.
...Which means, even EDGAR can't talk about it,...(but, we know that he knows),... :bg

    "In the earlier versions of Microsoft Windows NT, security was a major concern for OS design, so window management and graphics system ran in user address space. This led to so many performance problems that Microsoft made a major change in design by moving the windowing and graphics system from user mode to kernel mode starting with Windows NT 4.0.
    Window management supports the foundation of the Windows graphic user interface by implementing window class, window, window messaging, window hooks, window property, menu, title bar, scrollbar, cursor, virtual key, clipboard, etc. It's basically the kernel counterpart of USER32.DLL, which implements what's defined in the winuser.h portion of the Win32 API.
    Windowing and the graphics system are packed into a single huge DLL, win32k.sys, of around 1.6 MB. If you look at the exported functions from win32k.sys, you can find graphics system entry points—for example, EngBitBlt,PATHOBJ_bMove-To— but not window management entry points. The reason is that window management entry points are never called by other parts of the OS kernel components, while functions in graphics system need to be called by graphic device drivers. GDI32.DLL and USER32.DLL calls WIN32K.SYS through system service calls."