Auto Wait Cursor

• Download source files - 1 Kb

Introduction

It's recommended practice to change the mouse cursor to an hourglass wait cursor to inform the user that the program is working on something. This is easy enough to do when the programmer knows in advance that something is going to take a while. However, there are often circumstances where you can't predict how long something is going to take, so it's hard to know whether to display the hourglass or not. Ideally, you'd like the cursor to change to an hourglass automatically, as soon as your task had run for more than some time limit, e.g. 1/10 of a second. I needed to do this for a project of mine so I searched through my books and the internet, but couldn't find any applicable code. The closest thing I could find was an article explaining how to do it in Java. It didn't seem like it should be too tough to write a Windows/C++ version, but it ended up taking me longer than I expected to get it working properly so I thought I'd share the results.

Implementation

The basic idea I had was to create a secondary thread that would act as a "timer". The message loop would keep resetting the timer so it normally wouldn't run out. However, if a task took longer, then the timer would run out and the secondary thread would change the cursor to an hourglass. It didn't' take long to set this up, but mysteriously, it didn't work. A little debugging reassured me that my code was working properly, but that the SetCursor call in the secondary thread wasn't working. I guessed that SetCursor didn't work from secondary threads, but a search of the MSDN documentation and the internet didn't find anything about this. Finally, I posted a question to comp.os.ms-windows.programmer.win32 and went home. The first few responses I got didn't really help, but the third response turned out to be the key. The message referred me to an article by Petter Hesselberg in the Nov. 2001 Windows Developers Journal - "The Right Time and Place for the Wait Cursor". I couldn't find the article, but the source-code was online and the key turned out to be using AttachThreadInput. Once I added this to my code, things started to work.

I actually thought I was finished until I discovered that when I pulled down a menu (or brought up a context menu) the cursor changed to an hourglass. The problem was that while the menu was displayed, my message loop wasn't running and so the timer wasn't getting reset. After a certain amount of head scratching I came up with the idea of using a GetMessage hook to reset the timer, since I figured the menu must still be calling GetMessage (or PeekMessage). Sure enough this solved the menu problem. (And probably some related issues like modal dialogs.)

Again I thought I was finished, but I found one last glitch. Just before a tool-tip appeared, the cursor flashed to an hourglass and back. I guess tool-tips don't call GetMessage or PeekMessage while they wait. I fixed this by simply making my timer longer than the tool-tip timer.

My last task was to extract the code, which I'd mixed in with my message loop, into something more reusable. I ended up packaging it into a C++ class. To use the class you simply have to create an instance of it inside your message loop. Something like:

#include "awcursor.h"

...

while (GetMessage(&msg, NULL, 0, 0))
{
    AutoWaitCursor awc;
    TranslateMessage(&msg);
    DispatchMessage(&msg);
}

The AutoWaitCursor constructor "starts" the timer, and the destructor (called automatically at the end of the loop) restores the cursor if necessary. The constructor also looks after creating the thread and the hook the first time around.

If you look at the code, you may notice that the only concession I've made to multi-threading is declaring several of the variables volatile. I don't make any attempt to synchronize the threads or prevent them from accessing variables at the same time. This was a deliberate choice, because I wanted to make the code as fast as possible in order to not add overhead to the message loop. How do I justify this? First, the variables are plain integers, and therefore reading and writing them is atomic anyway. Second, if in some rare case, a synchronization problem occurs, the worst that can happen is the cursor might be wrong momentarily. This is a small price to pay to keep the code simple and fast. In practice I haven't seen any problems.

For simplicity, I've included the definition/initialization of the static class members in the header file. This isn't the best setup since it means you can't include this header in more than one source file. Ideally, you'd put the definitions in a separate .cpp file. However, you normally only have one message loop in your program anyway, so this setup seems acceptable.

I hope you find the code and the explanation useful. Good luck!