Re: CWnd::SetTimer, limited global resource.
"Geoff" <geoff@invalid.invalid> wrote in message
news:hc0mh3hs78ifu0mvp8s1qvd26sh2p6j4cp@4ax.com...
Under old Windows the timers were limited to 16 or 32 instances. I
think it was only 16, which was extremely limited and made for some
interesting problems for applications that wanted to use a lot of
timers for polling. You were supposed to do this:
idTimer = SetTimer(hWnd, 1, wTimerRate, NULL);
if (!idTimer) {
MessageBox(hWnd, "Not enough Timers!",
"myApp", MB_OK | MB_ICONSTOP);
DestroyWindow(hWnd);
return (FALSE);
}
Since the return value was and still is the ID of the timer, you
should ALWAYS get the return value so you can use it later when
calling KillTimer. Failure to capture a return value from a function
that returns its error state is bad coding style.
I'm not sure if it is good style to abort the entire program just because a
timer (which may or may not be truly needed) could not be acquired. In
fact, I would say it indicates a failure to think through the ramifications
of such an event about the same severity as ignoring the failure entirely.
The difference is, the code to try to recover and continue the app when
SetTimer() fails is bound to be quite convoluted, whereas ignoring the error
does not add code bloat or reduce program readability at all. I'm saying
that in some (not all, but some) cases, ignoring the
almost-never-occurs-and-if-it-does-mere-mortals-can't-recover-very-well-anyway
failure is the responsible thing to do.
BTW, on success, the return value from SetTimer() is the id that you
requested in the first parameter, so you already know what it is and need
not check the return value just for that.
-- David