Using threading to implement a 'busy' cursor (a tale from long ago)
A very long time ago, I spent a year being an Amiga programmer as part of a small team writing an application. We wanted it to have a busy mouse cursor (the general hourglass 'this is going to take a while' cursor good apps put up during long operations), but what with one thing and another, we wound up with two problems:
- we weren't actually sure what user actions would take a long time.
- we got to 'implement a busy cursor' rather late in the whole process.
This left us in a kind of pickle; we couldn't just mark all of the slow operations, and there was no central place to flip to a busy cursor if things were taking too long. In fact, the application didn't even process events during long actions. But the Amiga was a novelty at the time: a personal computer with a preemptive multitasking environment. This led us to a semi-ugly hack: put the busy cursor handling in a second thread.
We added a little 'I am not busy' spot in memory that got flipped on every time we went through the main event loop. A second thread periodically checked the flag and flipped it off; if the flag was already off, it changed the cursor into the 'busy' cursor. Later, the main event loop flipped the cursor back to normal if necessary. The preemptive multitasking took care of everything else.
(The actual implementation was slightly more complicated than this.)
I call this 'semi-ugly' because of the time lag between a long operation starting and the cursor turning into the busy cursor. In the worst case your operation would finish just after the cursor had gone busy, giving the cursor a kind of a time-lag stutter. However, the thread-based implementation was small and really simple, requiring basically no changes to the main application, which meant that we at least got some sort of busy cursor into the program.
I've always had a fondness for this hack; it was the first time where I really used multitasking, and it could only have been done on the Amiga.
|
|