What can reset cursor shape apart from SetCursor?

Question

I maintain a C++ application that uses flash ocx to play SWF file.

When user hovers on button in SWF, flash internally makes a call to WinAPI SetCursor function to set IDC_HAND cursor - I can see that when I monitor WinAPI calls to cursor-related function via API Monitor V2 (rohitab.com). However, in my case the cursor is not changing, i.e. stays IDC_ARROW.

The application itself does not call SetCursor at all. The window of the application processes WM_SETCURSOR message as following, i.e. does not restore the cursor:

case WM_SETCURSOR:
    {   
        static bool restoreCursor = false;
        if (LOWORD(lParam) != HTCLIENT)
        {
            restoreCursor = true;
        }

        if (restoreCursor)
        {
            restoreCursor = false;
            // DefWindowProc will set the cursor
            break;
        }
        return 1;
    }

Can anyone please let me know who can reset/change cursor shape in this case?

Update: The interesting part is the fact that I have 2 similar setups that produce the opposite results.

The application I maintain actually installs a WH_GETMESSAGE hook on "SysListView32" and launches a thread that creates Flash player. So the setup is not that straight-forward.

However, if I just create a simple example that creates a player at, basically, winmain, then the code above works perfectly and cursor gets changed.

So it appears that something does reset the cursor state in the first case. How to find out what resets the cursor?

Answer 1

OK, the real answer on this question is that non-GUI thread cannot change the cursor directly. See the comments in the bottom of the page http://msdn.microsoft.com/en-us/library/windows/desktop/ms648393%28v=vs.85%29.aspx

Another solution can be detouring/hooking the SetCursor function to ours that just sends a user message to GUI thread, signalling to set the cursor.

Both solutions have their pros and, of-course :), cons.

Answer 2

Your window (the parent) gets a crack at overriding the cursor and returning TRUE (1) indicated that you handled it and halts further processing. The arrow is probably coming from your WNDCLASS registration or from DefWindowProc.

So, it seems to me that you'd want to return FALSE to allow the child button a crack at actually setting the cursor. Or, remove handing WM_SETCURSOR altogether.