endless WM_COMMAND/BN_CLICKED

When the user selects a radio button, the button sends a WM_COMMAND/BN_CLICKED notification message to the button's parent. This lets the program which owns the parent take action based on the new selection.

This works fine as long as nothing could possibly go wrong during said action, but of course that's almost never the case. Suppose the action involves allocating a lot of memory and the allocation fails; what then? A good program will know which radio button was set before the user clicked and restore that button (before or after informing the user of the failure).

Now the fun begins.

If the program restores the old radio button while processing the message, Windows* decides to send an identical message for that very same button as if the button had been clicked again. This doesn't happen right away; it's deferred in some tricky way, and believe me it's not worth trying to second-guess the deferral. A straightforward program is likely to find itself in an endless loop not of its own making. The user clicks the radio button, the program tries to allocate a bunch of memory, fails, restores the old radio button, Windows sends another message as if the user clicked the radio button again, the program tries to allocate a bunch of memory... and hilarity ensues.

The way out of this madness is to observe that the radio button is not set the second time the system informs the program that it was clicked. When the radio button is set, act; when it's not, don't. It's not intuitive that one must make this test, but one must.

* My testing was on Vista only.