Changing a window class affects all windows which belong to that class

Sometimes you need to state the obvious, and that's fine. You can learn a lot from the obvious. For example, the first topic in my PDC talk consisted of simply stating the obvious.

Occasionally, when you state the obvious, you have to follow up by stating the obvious.

When I pointed out that the effect of SetCursor lasts only until the next SetCursor, one commenter proposed as an alternative solution to the problem of how to prevent the cursor from reverting to the arrow,

What about calling SetClassLongPtr() with the GCLP_HCURSOR param? Is this an acceptable alternative, or does this have issues of its own?

Being busy is a state of a particular window instance, not a state of the window class. Therefore, the setting of the cursor must be done by the window instance, not by the window class. If you change a window class, then it affects all windows which belong to that class. In particular, changing the class cursor changes the cursor for all windows that belong to the class.

In other words, consider the case where you have two windows on the screen that belong to the window class. One of the windows becomes busy, so you change the class cursor to an hourglass. When the user moves the mouse over the window that is busy processing, the cursor turns to an hourglass, as you would expect. But when the user moves the mouse over the window that is not doing any processing, the cursor will turn to an hourglass there also, even though that window is perfectly fine.

It is important to understand the scope of what one is changing. Don't make a global change to solve a local problem.

Comments (12)
  1. Anonymous says:

    So another workaround would be to have a window class for each used mouse pointer, and then reassign window classes instead, LOL ^_^

  2. Anonymous says:

    You laugh, but I think that creating a new window class (or window of a special window class) isn’t a terrible way to go.

    You throw your invisible pane in front of the window in question, it changes the cursor…

    Miller time.

  3. Tim Smith says:

    Maybe I am missing the obvious, but if SetCursor only is valid until the next WM_SETCURSOR, then why have SetCursor and just return the HCURSOR in the WM_SETCURSOR message?

    It seems that having the routine has caused confusion.  Obviously, I am not saying that Windows should change.  I am just wondering why we have SetCursor.

  4. If your window is too busy to process messages, then it won’t be able to resopnd to WM_SETCURSOR.

  5. Tim Smith says:

    And there is the obvious answer. :)

  6. Anonymous says:

    But what if the busy window is disabled?

  7. Anonymous says:

    Related question: anyone know if there is an api for causing a WM_SETCURSOR to be generated? Or is this a case of putting the pieces together yourself? I.e., find the window under the cursor, put together the params for WM_SETCURSOR, and send or post.

  8. Anonymous says:


    The following trick has been successful for this kind of thing from NT 4.0 through XP…

    POINT ptCursor;

    if (GetCursorPos(&ptCursor))

    SetCursorPos(ptCursor.x, ptCursor.y);

    This seems to trick the system into treating this like a normal mouse move.  I’ve used this in a scrolling window to get the mouse cursor to update while scrolling with the keyboard (i.e. the mouse stays in sync with what’s under it)

  9. Anonymous says:

    Thanks emassy – I’m going to go with that – and hope it doesn’t cause headaches for Raymond down the road. :)

  10. Anonymous says:

    Why is cursor associated with class and not window?

    Many programs do call SetCursor on every WM_MOUSEMOVE, is this unrecommended?

    I ask because I don’t find the answers obvious.

  11. Anonymous says:

    Monday, March 06, 2006 5:43 AM by LittleHelper

    > Many programs do call SetCursor on every

    > WM_MOUSEMOVE, is this unrecommended?

    Isn’t it necessary?  Consider for example Internet Explorer.  If the mouse moves to an area of plain text, the mouse cursor looks almost like a text cursor.  If the mouse moves to a link, the cursor looks like a finger pointing.  If the mouse moves to most other parts of a page, the cursor looks like an arrow.  If the mouse moves to a divider of some sort, the cursor looks like a different kind of double-ended arrow to indicate that the user can move the divider.

    > Why is cursor associated with class and not

    > window?

    Yeah when you find that out, please let me know too.

  12. Anonymous says:

    That’s why they’re called class properties.

Comments are closed.