Hide cursor for 100ms at the end of Cursor>>showWhile:

[jgfoster]

This fixes #1154 but is an ugly hack. Yet it is the only thing I can find that works after a full day of debugging. This is almost certainly some sort of timing issue (especially since a delay masks the problem), and it may be related to my Windows system being a VM in Fusion. Without this change many busy actions with a changed cursor end up with the cursor not being restored.

My test case is opening and closing tabs in an IdeaSpace and the problem is very consistent (about 50% of the time). Moving the mouse into an area with a different cursor (like a text editor) will get the cursor back, so it is easy to just get in the habit of moving the cursor around after a long-running operation, but it makes these operations seem excessively long-running (they appear to hang).

I can't say that I seriously expect this to be merged, but it serves as a point of reference for those who see the same issue (and I will be incorporating it as a patch in my application).

[jgfoster]

Further use of this change indicates that it does not solve the cursor issues in my application, so this remains more of a mystery. I'll leave the PR open for now as an invitation for discussion in case anyone else has any comments. Do you observe the problem with a stuck busy cursor?

[blairmcg]

I certainly won't be applying it James, because this must be an external bug. I say that because it is actually quite difficult to maintain a persistent cursor in Windows. A call to the SetCursor API simply does not persist very long before the cursor gets replaced. Usually only as long as the mouse remains still. The Dolphin Window class (and the standard controls generally have this too) has a cursor specified (IDC_ARROW, the arrow, or whatever the theme provides in its place), and Windows will restore this class cursor immediately the mouse is moved. It also sends a WM_SETCURSOR on mouse move to provide the Window with an opportunity to override the window class cursor. This is intercepted in MVP to be able to support the current cursor mechanism, and provide other cursors when required. In order for the wait cursor to persist, therefore, it would have to be because there is some onGetCursor: implementation returning it. The standard implementations framework would return the wait cursor only if Cursor.Current is the wait cursor (see Presenter>>#onGetCursor:), or for disabled shells that don't have a modal dialog associated (see ShellView>>#onGetCursor:).

The wait cursor is generally set as Cursor.Current when a command is fired, so if some modal operation is started by the command then it may end up stuck with the wait cursor. I'm aware of at least one example of this - initiating an in-place edit to rename a variable in a method workspace, but if Cursor.Current is nil then the wait cursor cannot be "stuck" because of that mechanism.

1154 certainly doesn't repro for me, and I think it is very unlikely to be a Dolphin bug.

[jgfoster]

Closing as this does not seem to be an effective fix for my situation. We'll continue the discussion in #1154.