Bug with cursor changes in Juce with Big desktop

I build Juce Demo, using Visual Studio 2008 and run Debug target under Windows 7 64-bit.

Then I run the application. Note that I am using two monitors. One is a 24" running at 1920x1200 and to the right of that is a 30" running at 2560x1600.

Action: Move the cursor from outside the Juce main application window, to just at the window resizing border.

Result: The cursor will change from an arrow to a standard windows resizing cursor. However, for the very first frame of animation when the cursor changes, instead of a correctly appearing resizing cursor, the result is a bitmap that looks like it is being read incorrectly. There is green where there should be white, and the whole thing is stretched horizontally by a factor of 3 or 4. This looks exactly like what happens when you parse RGB data in one format, using the wrong format. A split second later, the problem corrects itself.

By moving the cursor away from, and on to, the window resizing border of the main application window, and looking carefully, you can see this problem.

This is a stock build of Juce, no changes.

Note that this only happens when the Juce window is past a certain point horizontally. Usually from every side of the second screen.

Note(2) this is not reproducible in the Release build.

That’ll be a win32 bug rather than a juce bug. The cursors are preset windows shapes, so if there’s graphical corruption, it must be happening inside windows itself or the video driver. Nothing I could do to change that!

You are right, and I thought the same thing but for some reason I saw it happen a lot with a debug build of Juce demo.

However, I played around with putting non-Juce windows to the far right of my virtual desktop and I was able to reproduce it as well it is just harder to see because it lasts for a shorter instant. It happens for any Windows window. I’m running Windows 7 64bit.

Therefore, this issue is closed.

I remember seeing corrupted cursors like that occasionally back in the XP days, but am surprised that it could still happen in Win7… You’d have thought MS would have got the hang of writing thread-safe code by now!