{"id":108247,"date":"2023-05-25T07:00:00","date_gmt":"2023-05-25T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=108247"},"modified":"2023-05-25T08:53:14","modified_gmt":"2023-05-25T15:53:14","slug":"20230525-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20230525-00\/?p=108247","title":{"rendered":"How can I trigger a recalc of the mouse cursor after I changed some of my internal application state?, follow-up"},"content":{"rendered":"

Some time ago, I described how to trigger a recalc of the mouse cursor after changing internal application state<\/a>. In the bonus chatter, I noted that the cursor you set with Set\u00adCursor<\/code> is used only when the mouse is over a window belonging to the thread that called it. Commenter Stuart Ballard asked,<\/p>\n

\n

Does the Bonus Chatter imply that in theory there’s no need for the<\/p>\n

window == child || IsChild(window, child)\r\n<\/pre>\n
check at all? If I understand rightly, all we’re doing is sending a message saying “the mouse cursor moved”. Is there any reason it’d be bad for an unrelated window to receive a message like that?<\/p>\n<\/blockquote>\n
The danger here is that the window you find may belong to a window from another thread. If you removed the “is for me or my children” check, then you are going to ask that other window to do a cursor recalculation, and that has a few problems.<\/p>\n
First, it reopens the race condition I discussed in the bonus chatter: If the mouse has moved since the time you called Get\u00adCursor\u00adPos<\/code>, then you are going to ask that other window to recalculate based on stale data. And this time, the problem is real: That other window may have already processed the system-generated WM_SET\u00adCURSOR<\/code> message, and then you follow up with a WM_SET\u00adCURSOR<\/code> message with the wrong coordinates, leaving the cursor in an incorrect state.<\/p>\n
There’s also a race condition if the target window reconfigures itself between the WM_HIT\u00adTEST<\/code> message and the WM_SET\u00adCURSOR<\/code> message, and you end up asking the window to set its cursor based on outdated information.<\/p>\n
This was not a problem if the message was for a window belonging to the same thread, because you know that the window cannot reconfigure itself between the WM_HIT\u00adTEST<\/code> message and the WM_SET\u00adCURSOR<\/code> message, nor can it process a newer mouse-move event: Those actions would have to happen on the same thread, and that thread is busy running your<\/i> code.<\/p>\n
Another danger of removing the extra test is that the target window’s thread may be hung. and trying to send a message to that window will cause your thread to hang, too.<\/p>\n
So keep filtering the window before you ask it to recalculate the mouse cursor.<\/p>\n
Bonus chatter<\/b>: Does this mean that you can simplify the test to<\/p>\n
GetWindowThreadProcessId(child, nullptr) == GetCurrentThreadId()\r\n<\/pre>\n
?<\/p>\n
No.<\/p>\n
Cross-thread window hierarchies are valid, and if there is a child window that belongs to another thread, you stil want to tell it to recalculate the cursor. There is no race condition here, however, because cross-thread window hierarchies result in in input queue synchronization, so the other thread won’t receive cursor messages until the current thread has finished.<\/p>\n","protected":false},"excerpt":{"rendered":"
You still need to filter to your window, so you don’t mess up another window on the same thread.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-108247","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
You still need to filter to your window, so you don’t mess up another window on the same thread.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108247","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=108247"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108247\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=108247"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=108247"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=108247"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}