What is the process by which the cursor gets set?

Date:	November 21, 2006 / year-entry #391
Tags:	code
Orig Link:	https://blogs.msdn.microsoft.com/oldnewthing/20061121-15/?p=28943
Comments:	10
Summary:	Commenter LittleHelper asked, "Why is the cursor associated with the class and not the window?" This question makes the implicit assumption that the cursor is associated with the class. While there is a cursor associated with each window class, it is the window that decides what cursor to use. The cursor-setting process is described in...

Commenter LittleHelper asked, "Why is the cursor associated with the class and not the window?" This question makes the implicit assumption that the cursor is associated with the class. While there is a cursor associated with each window class, it is the window that decides what cursor to use.

The cursor-setting process is described in the documentation of the WM_SETCURSOR message:

The DefWindowProc function passes the WM_SETCURSOR message to a parent window before processing. If the parent window returns TRUE, further processing is halted. Passing the message to a window's parent window gives the parent window control over the cursor's setting in a child window. The DefWindowProc function also uses this message to set the cursor to an arrow if it is not in the client area, or to the registered class cursor if it is in the client area.

That paragraph pretty much captures the entire cursor-setting process. all I'm writing from here on out is just restating those few sentences.

The WM_SETCURSOR goes to the child window beneath the cursor. (Obviously it goes to the child window and not the parent, because the documentation says that DefWindowProc forward the message to its parent. if the message went to the parent originally, then there would be nobody to forward the message to!) At this point, your window procedure can trap the WM_SETCURSOR message, set the cursor, and return TRUE. Thus, the window gets the first priority on deciding what the cursor is.

If you don't handle the WM_SETCURSOR message, then DefWindowProc forwards the message to the parent, who in turn gets to decide whether to handle the message or forward to its parent in turn. One possibility is that one of the ancestor windows will handle the message, set the cursor, and return TRUE. In that case, the TRUE return value tells DefWindowProc that the cursor has been set and no more work needs to be done.

The other, more likely, possibility is that none of the ancestor windows cared to set the cursor. At each return to DefWindowProc, the cursor will be set to the class cursor for the window that contains the cursor.

Here it is in pictures. Suppose we have three windows, A, B, and C, where A is the top-level window, B a child, and C a grandchild, and none of them do anything special in WM_SETCURSOR. Suppose further that the mouse is over window C:

SendMessage(hwndC, WM_SETCURSOR, ...)
 C's window procedure does nothing special
 DefWindowProc(hwndC, WM_SETCURSOR, ...)
  DefWindowProc forwards to parent:
   SendMessage(hwndB, WM_SETCURSOR, ...)
   B's window procedure does nothing special
   DefWindowProc(hwndB, WM_SETCURSOR, ...)
    DefWindowProc forwards to parent:
     SendMessage(hwndA, WM_SETCURSOR, ...)
     A's window procedure does nothing special
      DefWindowProc(hwndA) cannot forward to parent (no parent)
      DefWindowProc(hwndA) sets the cursor to C's class cursor
      DefWindowProc(hwndA) returns FALSE
     A's window procedure returns FALSE
    SendMessage(hwndA, WM_SETCURSOR, ...) returns FALSE
    DefWindowProc(hwndB) sets the cursor to C's class cursor
    DefWindowProc(hwndB) returns FALSE
   B's window procedure returns FALSE
  SendMessage(hwndB, WM_SETCURSOR, ...) returns FALSE
  DefWindowProc(hwndC) sets the cursor to C's class cursor
  DefWindowProc(hwndC) returns FALSE
 C's window procedure returns FALSE
SendMessage(hwndC, WM_SETCURSOR, ...) returns FALSE

Observe that the WM_SETCURSOR started at the bottom (window C), bubbled up to the top (window A), and then worked its way back down to window C. On the way up, it asks each window if it wants to set the cursor, and if it makes it all the way to the top with nobody expressing an opinion, then on the way down, each window sets the cursor to C's class cursor.

Now, of course, any of the windows along the way could have decided, "I'm setting the cursor!" and returned TRUE, in which case the message processing would have halted immediately.

So you see, the window really does decide what the cursor is. Yes, there is a cursor associated with the class, but it is used only if the window decides to use it. If you want to associate a cursor with the window, you can do it by handling the WM_SETCURSOR message explicitly instead of letting DefWindowProc default to the class cursor.

LittleHelper's second question: "Many programs call SetCursor on every WM_MOUSEMOVE. Is this not recommended?"

Although there is no rule forbidding you from using WM_MOUSEMOVE to set your cursor, it's going to lead to some problems. First, and much less serious, you won't be able to participate in the WM_SETCURSOR negotiations since you aren't doing your cursor setting there. But the real problem is that you're going to get cursor flicker. WM_SETCURSOR will get sent to your window to determine the cursor. Since you didn't do anything, it will probably turn into your class cursor. And then you get your WM_MOUSEMOVE and set the cursor again. Result: Each time the user moves the mouse, the cursor changes to the class cursor and then to the final cursor.

Let's watch this happen. Start with the scratch program and make these changes:

void
OnMouseMove(HWND hwnd, int x, int y, UINT keyFlags)
{
 Sleep(10); // just to make the flicker more noticeable
 SetCursor(LoadCursor(NULL, IDC_CROSS));
}

 // Add to WndProc
 HANDLE_MSG(hwnd, WM_MOUSEMOVE, OnMouseMove);

Run the program and move the mouse over the client area. Notice that it flickers between an arrow (the class cursor, set during WM_SETCURSOR) and the crosshairs (set during WM_MOUSEMOVE).

Comments (10)

Tom says:

November 21, 2006 at 10:30 am

What if an application is busy with something and isn’t processing messages? Does Windows use a default cursor or does it remember and use the registered class cursor… or other?

All the apps on my computer are well behaved enough under WinXP that I can’t think of one to use in an attempt to answer this for myself.
David Walker says:

November 21, 2006 at 11:30 am

“The DefWindowProc function also uses this message to set the cursor to an arrow if it is not in the client area.”

Does “the client area” mean “some application”?

The cursor is not always an arrow if it is not in an application; it’s whatever the user set in the Mouse applet in the Control Panel, on the Pointers tab. It could be a hand from the “Conductor” system scheme.

[“Arrow” was shorthand for “logical arrow cursor, which might look like an actual arrow, or might look like something else if the user customized the logical arrow cursor.” I can’t believe I had to write that. I’m assume you’re all smart enough to figure that out. -Raymond]
Skizz says:

November 21, 2006 at 1:11 pm

That description reminded my of one of Humphrey Lyttelton’s descriptions of the game ‘One song to the tune of another.’ (Listen to http://www.bbc.co.uk/radio/aod/networks/bbc7/aod.shtml?bbc7/clue about 8:20 minutes in for an example.)

Skizz

P.S.
Foolhardy says:

November 21, 2006 at 2:46 pm

I’ve noticed an odd behavior with the cursor’s appearance in processes that are in a job object with the JOB_OBJECT_UILIMIT_HANDLES limit. This limit prevents processes inside the job from accessing USER handles (like HWNDs) not belonging to process inside the job. It’s quite useful in mitigating ‘shatter’ attacks.

Many applications behave normally under this limit, except that they do not always update the cursor correctly. The cursor IS updated if they let DefWindowProc set the cursor according to the the window class’s cursor, but sometimes the cursor will get "stuck" as the I-beam (or some other) cursor after moving over a textbox, and not revert back to an arrow when it’s supposed to.

To try some psychic powers of my own, I suspect that a process under the JOB_OBJECT_UILIMIT_HANDLES limit can only set the cursor while processing WM_SETCURSOR, and not at other times: apps that normally set the cursor in response to WM_MOUSEMOVE have their requests ignored under this limit.

The rationale for this Windows behavior is that you wouldn’t want a sandboxed app just setting the cursor anytime it felt like it, so it’s only allowed to set the cursor when the window manager is sure that the cursor belongs to the app– while handling WM_SETCURSOR.

This behavior can be reproduced in XP or 2003 under the "Restricted" extended SAFER level (which creates a job with the HANDLES limit), or with ulimitnt.exe and the -handles option.

Winamp, for example, won’t update the cursor at all (except in common dialog boxes). Wordpad fails to show the I-beam in the main text area. Visual Studio 2005 doesn’t display the I-beam correctly, and often makes (leaves?) the cursor invisible.

I’m not trying to blame anyone for this: it’s just another example of how not following the rules (i.e. updating the cursor at the right time) can lead to unexepected problems.
David Walker says:

November 21, 2006 at 4:21 pm

Raymond: Well, I could have assumed that you meant "logical arrow cursor" when you wrote "arrow", but I couldn’t be sure.

After all, you were talking about changing the cursor. Sorry I wasn’t more prescient.
steven says:

November 21, 2006 at 8:24 pm

just tested the modified scratch program, why the cursor is crosshair after some mouse moves stop? shouldn’t WM_SETCURSOR is the last message we get?
Chris Becke says:

November 22, 2006 at 3:18 am

The documentation doesn’t make it entirely clear where the WM_SETCURSOR message comes from. Which is sometimes rather important to being able to divine out the messages true life and purpose.

I suspect its generated by PeekMessage/GetMessage when they see that the’yre meant to generate a WM_MOUSEMOVE message, the reason the cursor stays as a crosshair is that the WM_SETCURSOR is generated before, not after, the WM_MOUSEMOVE message.
Miral says:

November 22, 2006 at 7:38 pm

“DefWindowProc(hwndA) sets the cursor to C’s class cursor”

Surely it would set it to *A*’s class cursor? Then
DefWindowProc(hwndB) would set it to B’s cursor, and finally
DefWindowProc(hwndC) would set it to C’s cursor.

Presumably this doesn’t result in flicker because it’s setting some
internal flag telling it to not actually draw the cursor until the
whole chain is complete. Unlike the WM_MOUSEMOVE case.

[There is no internal flag to “delay cursor
changes”. It really does set it to C’s class cursor. It has to, because
the hit-test value refers to C’s window, not A’s (or B’s). If you
wanted to set the cursor to A’s class cursor, then you would need to
have A’s hit-test code. -Raymond]
LittleHelper says:

November 23, 2006 at 4:48 pm

Thanks for explaining!

I still find it strange that cursors are an attribute of the window class, and not of the window instance. Maybe it is remains of constrained resources in older windows.

[??? It’s an attribute of the window instance that’s the whole point of this article! If the window instance chooses not to customize the cursor and lets DefWindowProc decide, then it comes from the class, but it was the window instance’s decision! I guess I completely failed in my attempt to explain this topic. -Raymond]
webionaire » Cursor Flicker says:

May 14, 2007 at 6:18 pm

PingBack from http://webionaire.com/island/?p=175

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:

A "redesign" after 2019 erased thousands of user's comments from previous years. As many have stated, the comments are nearly as important as the postings themselves. The archived copies of the postings contained here retain the original comments.
The blog has changed domains many times and the urls have otherwise been under constant change since 2003. Even when proper redirection has been set up for those links, redirection only works for a limited period of time. For example, all of the internal blog links that were valid in early 2019, were broken by 2020 without proper redirection.
The blog has been under constant re-design and re-theming since its inception. It is downright irritating to deal with a bogged-down site experience as the result of the latest visual themes designed for cell-phone browsers. As of this writing, it is cumbersome to navigate titles with only 10 entries per page. While it is nice that the official site has a search feature, searching using this index (with all titles on a single page) is much quicker (CTRL-F in most browsers).

<-- Back to Old New Thing Archive Index