I was looking at some source i happened upon a long time ago and noticed the initialization routine for decairing a separate window class was rather short and unique:
InitRollup	PROC


mov RollUpClass.cbSize, SIZEOF WNDCLASSEX
[b] INVOKE GetClassInfoEx, NULL, 32770, ADDR RollUpClass[/b]

mov RollUpClass.lpszClassName, OFFSET szRollUpClass
m2m RollUpClass.lpfnWndProc, OFFSET RollupWindowProc
invoke RegisterClassEx, ADDR RollUpClass

InitRollup ENDP

My question is the BOLD line universally ok? I assume 32770 is the Atom of some typical window used by the OS (such as a button or somthing). Can it be used on all OS's?

Your thoughts please ;)
Posted on 2003-04-15 16:37:35 by NaN
Here is the source...
Posted on 2003-04-15 16:40:12 by NaN
humm, 32770. Might be the dialog template wndclass?
Posted on 2003-04-15 16:46:22 by f0dder
try playinging around a bit with spy++, look at a dialog window.
Class: #32770 (Dialog)
Posted on 2003-04-15 16:47:51 by f0dder
I don't think it's officially fool-proof but you often see '#32770' (=atom 32770) as the classname of dialogs so I assume it's created internally and used by windows to create new dialog windows. I wouldn't rely on it though.


edit: f0dder beat me :)
Posted on 2003-04-15 16:48:23 by Thomas
I dunno if it's a documented thing, and I dunno how universal it is, but I've seen it across multiple windows versions. win2k/sp2/sp3, win98se for sure. Before making wide use of it, you ought to try and find some information on it.
Posted on 2003-04-15 16:53:59 by f0dder
I've noticed the same thing in all windows versions I've worked with but a search on that value in the PSDK and MSDN advanced search leaded to nothing.
Funny thing is that the win64 ATL headers actually hardcode and use this value:

class CWindow
BOOL IsParentDialog()
TCHAR szBuf[8]; // "#32770" + NUL character
GetClassName(GetParent(), szBuf, sizeof(szBuf)/sizeof(TCHAR));
return lstrcmp(szBuf, _T("#32770")) == 0;

So I guess it's pretty reliable but you can never be sure...

Posted on 2003-04-15 17:05:32 by Thomas
Thanks for the effort Thomas!

This looks to me like its fairly safe to assume it will work... If ever there is a change in OS that will affect this, then the MFC stuff in VC packages will have to be upgraded too. At which time it wouldnt me much hassle to redo this in th classical approach of filling out the WNDCLASSEX structure.

I have to admit though this is alot simpler!

If anyone has a problem running the attachment above, please let me know what OS your using. Since this would possibly idicate there is such confict with this approach to registering classes.

PS: To those interested, i have cleaned up the above source into a custom API like function call, where you provide a resource ID to a dialog box, and it does all the dirty work of making it "roll" up and down depending on the cursor position. From a coding point of view it acts like an API similar to CreatDialogParam (I have to admit, its pretty nice ;) )

Thanx again!
Posted on 2003-04-16 12:00:34 by NaN
This link shows three of the #xxxxx classes:


I remember that some Win16 references listed some of these numerically predefined classes.
Posted on 2003-04-16 13:22:19 by tenkey
Appendix A: Supported User Interface Elements Reference
This appendix contains information about the system-provided user interface (UI) elements exposed by Microsoft? Active Accessibility? in Microsoft Windows? 95, Windows 98, Windows NT? version 4.0, Windows 2000, and Windows XP. This support allows client utilities to get information about system-provided UI elements in applications that do not implement Active Accessibility.

Oleacc.dll supports controls that are defined in User32.dll, Comctl32.dll, and Windows UI elements. Specifically, it supports the following types of UI elements (listed by Windows class name).
#32768 USER menus
#32770 USER dialog boxes
#32771 Alt-tab window

Thanks tenkey, this has me 100% sold now ;)
Posted on 2003-04-16 18:06:06 by NaN