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

Date:February 27, 2006 / year-entry #73
Tags:code
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20060227-12/?p=32133
Comments:    12
Summary: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...

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. 8 says:

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

  2. 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. 8 says:

    But what if the busy window is disabled?

  7. pUnnk 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. emassey says:

    pUnnk:

    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. pUnk says:

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

  10. LittleHelper 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. Norman Diamond 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. That’s why they’re called class properties.

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index