Why does the win32 API use strings as class identifiers instead of handles?
Author
It seems at odds with the rest of the API. Pretty much everything is based on handles like HWND and HMODULE, so I would expect that RegisterClass(Ex) would return an HCLASS. The ATOM behaves like a handle, but I still have to generate a string in my win32 wrapper. When I wasn't using a wrapper and was just using the naked SDK I usually ended up just using global constants anyway.
So does anyone know?
Like most older things in the API, the decision was probably made based on some condition or restriction that was only an issue 15 years ago.
I would say it's because class names are for more than just registering your own class. There's also the "well-known" class names such as "BUTTON", "EDIT", "LISTBOX", etc. They need to be strings so that you can refer to them in external files (like dialog templates).
That's my guess anyway.
That's my guess anyway.
Author
Quote:Original post by Codeka
I would say it's because class names are for more than just registering your own class. There's also the "well-known" class names such as "BUTTON", "EDIT", "LISTBOX", etc. They need to be strings so that you can refer to them in external files (like dialog templates).
That's my guess anyway.
Yeah, I guess you're right, that's a good reason for their existence.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
