What makes RealGetWindowClass so much more real than GetClassName?

There's Get­Class­Name and then there's Real­Get­Window­Class. What makes Real­Get­Window­Class more real?

Recall from last time that the Real... functions were added to support Windows accessibility. The goal with Real­Get­Window­Class is to help accessibility tools identify what kind of window it is working with, even if the application did a little disguising in the form of superclassing.

If you ask Real­Get­Window­Class for the class name of a window, it digs through all the superclassing and returns the name of the base class (if the base class is one of the standard window manager classes). For example, if your application superclassed the button class, a call to Get­Class­Name would return Awesome­Button, but a call to Real­Get­Window­Class would return button. Returning the underlying window class allows accessibility tools to know that the user is interacting with some type of button control (albeit a customized one), so that it can adjust the interaction to something appropriate for buttons. Without Real­Get­Window­Class, the accessibility tool would just see Awesome­Button, and it would probably shrug and say, "I have no idea what a Awesome­Button is."

(I guess you could have the accessibility tool do a strstr for button, but then it would be faked out by classes like Button­Bar or applications which superclass a button but call it something completely different like Awesome­Radio.)

If you read the winuser.h header file, you can see a comment next to the Real­Get­Window­Class function:

 * This gets the name of the window TYPE, not class.  This allows us to
 * recognize ThunderButton32 et al.

What is Thunder­Button32?

Thunder was the code name for Visual Basic 1.0. Visual Basic superclassed all the standard Windows controls and called its superclassed version Thunder­Whatever.

Comments (7)
  1. Alex B. says:

    Thunder! Thunder! Thunder! ThunderButton32!

  2. configurator says:

    Then shouldn't it be called GetWindowBaseClass, then? or GetWindowTypeNotClassEvenIfItsSubclassedBySomethingLikeThunderButton32?

  3. James says:

    The Real… names are horrible.  The base class name isn't any more "real" than the superclassed name; they're both valid names.

    I know it's too late to change now, but maybe adding a more sensible alias via #define would be less confusing. (It'd be a leaky abstraction though since it wouldn't help anyone trying to get it through GetProcAddress.)

  4. kero says:

    But Raymond, why RealGetWindowClass dsn't work with comctl32.dll v.6 ??

    [The information necessary to answer this question is already present in the article. -Raymond]
  5. Henning Makholm says:

    @kero: Specifically "(if the base class is one of the standard window manager classes)". Since there is no static superclassing chain that can be traversed in a standard manner, RealGetWindowClass must somehow depend on the cooperation of the base class — for example, that the standard window manager class handlers for WM_NCCREATE set some hidden field that RealGetwindowClass can later inspect.

    (Of course the window manager might have exposed functionality to set this hidden field, such that comctl32 could use it, but it would probably just have been abused by everone to the point of being useless for its original purpose then).

  6. 640k says:

    Using accessibility isn't abusing the system. It could have been implemented to work more well.

  7. woodswan says:

    May I report that Thunder is the main product name of a Chinese IT company, called xunlei. Such coincidence is always making me amaze that programmers not only like reinventing wheels, but also naming things.

Comments are closed.

Skip to main content