Custom cursor problem on PC for some people

In a CView in one of our plug-ins, we change the cursor based on certain conditions in the onMouseMoved() function. (Some of those cursors use custom bitmaps, but that is not relevant to this issue as far as I can determine.)

We have seen that on the PC, for some reason, the cursor switches back to the default (arrow) cursor unexpectedly. Our software still thinks that it is using the cursor that we set (via the CFrame’s setCursor() function), so it doesn’t bother calling setCursor() gain, and so the cursor remains as the system cursor after that point. On some systems, this happens quickly, on others it takes more movements of the mouse before it happens. It won’t restore to our cursor until moving the mouse off the CView and back on (because of code that handles entering and exiting the view).

Because of this problem, on the PC only, we now always call setCursor() to set the cursor when onMouseMoved() is called on the CView. However, what happens now is that whenever the mouse cursor switches to the system cursor, we immediately set it back again. For some users this makes the mouse cursor repeatedly flash back and forth between the custom cursor and the system cursor, over and over again as the mouse is moved over the graph.

Unfortunately for me, trying to debug the problem, it does not happen very often. I only see it flash every once in a while. But even wore, if the transport is running the user moves the mouse and they have a system on which is flashes back and forth often, it leads to a CPU overload (or something similar) that causes audio drop-outs and glitches, which is NOT acceptable (obviously)!

I have not been able to find any reason why the arrow cursor keeps being set for the window. I do not know if it is a system difference, a graphics card/driver difference, something in Cubase, or something in the VSTGUI SDK that is resetting the cursor shape. And since I don’t KNOW what the cursor shape is, I cannot tell that it has happened, and thus cannot trace when it happens to see who caused it to happen.

Anyone know what might cause the cursor to change shapes like that without our own code causing it? Anyone know how we might fix it???


After some more tests, I have found that even on my system, the cursor is being set to the system cursor every time the mouse moves. It’s just that on my system it rarely has a chance to actually change, because my code changes it back to our custom cursor so fast. If I only let the cursor change back to our custom cursor after a delay, I see the same behavior others have reported, with it immediately changing to the system cursor when the mouse moves.

I have not been able to locate anything in the SDK that causes this change. Also, it does not happen in our AAX software, which also uses VSTGUI. It appears to be something in the host or related to the type of window that the plug-in is hosted in, but I just can’t tell.

Anyone else using setCursor() out there, and seeing this behavior (or not)?

Can’t you set a breakpoint somewhere to find out what’s changing the cursor back? I’m surprised that it’s demanding enough to cause dropouts. Are you calling invalid() anywhere? I ask because calling invalid()–especially on the entire frame–involves a lot of drawing and might explain the dropouts…and maybe (I really have no idea), it might be causing your cursor to reset.

I DID set breakpoints everywhere that the cursor is set, in my code and in the library code. It seems to be at the window or system level that this is happening. As far as I can tell, nothing seems to be telling the cursor to change within the VSTGUI libraries or within my code, it simply changes. And it changes EVERY time the mouse moves, so that I have to change it BACK on every mouse move. I only get the audio dropouts if I change the cursor, which does not involve any drawing or invalidation on my part, only code that determines the appropriate shape and then the call to setCursor(). Apparently, that constant back-and-forth is enough to overload something on SOME machines, causing audio dropouts. I do not get audio dropouts on my machine, but I have to trust that my testers on that point.

If I remember correctly, on some graphics cards the change of a cursor is taken a long time when the cursor size is bigger than 16x16. And because the graphics driver is doing this with the highest priority (don’t know why they think they should do it this way) the audio threads get interrupted.
Try to use cursor sizes that are not bigger than 16x16.
And that the cursor is reset on mouse move is a bug in Cubase > 8.0.


And that the cursor is reset on mouse move is a bug in Cubase > 8.0.

Ah, that explains why our tester using Cubase 7 did not see it. Thanks!