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.

Mac OS X 10.4 parental controls vs. Microsoft Office 2004

Tonight, I set up Microsoft Office 2004 to run in a Simple Finder configuration under the parental controls of Mac OS X 10.4 (Tiger), but it took a lot longer to get running than it should have. The first application I tried to enable was Microsoft Word. Although the parental controls window clearly showed Word as having been enabled, Word did not appear in the applications window when I logged in as the user in question. After many frustrating attempts to rectify the situation, I finally got lucky. I enabled the full Finder and launched Word, which went through its "first run" ritual for the user in question. Office applications, of course, need to perform this ritual once for each user. After I logged out and back in again, Word appeared in the Simple Finder window. My theory is that the parental controls in Tiger know that this configuration is not capable of supporting the first run of an Office application, and so they quietly hide the app from the user. This is a user-hostile way to handle the issue; I would have preferred to see Word try and fail to perform its first run ritual.

turn off Visual Studio 2005 automatic manifest resource generation in converted projects

When Visual Studio 2005 upgrades an old project, it turns on a setting which tells the linker to create a manifest resource in your program file. This resource seems to express a dependency on a DLL version of the C/C++ standard libraries. This causes the system to refuse to load your program unless said DLL is present. Your users will get an error indicating something about an invalid configuration and suggesting they reinstall. Apparently, the relevant libraries are not present on Windows XP SP2 (I haven't checked Vista), which causes the system to believe it should not even try to run some otherwise perfectly good programs.

This is a particularly vexing because some applications, including some bundled with Windows, install these libraries, and it can be difficult to figure out why some systems fail and others do not. One such application is, you guessed it, VS2005, so you will never be able to reproduce this problem on the system with which you built your program. Another seems to be Internet Explorer 7, so anybody who's got automatic updates turned on won't be able to reproduce this problem, either. Anybody who's still running IE6 (or earlier) without VS2005 probably will not be able to run your program.

Adding insult to injury, my programs already contain carefully constructed manifest resources and/or have carefully chosen linker options so that they don't take external dependencies which may or may not be present on deployment systems.

Fortunately, the fix was simple. There's a new linker option which controls generating this manifest resource. I turned it off and things went back to normal. It seems I could also have directed users to the Microsoft web page where they may download the C/C++ runtime libraries from VS2005. (Perhaps Microsoft ought to add these libraries to Windows Update.) Or, it seems, I could have redistributed these libraries with my programs (after deciding I am compatible with the relevant legalese).

I understand why Microsoft would want to add the capability of generating a manifest resource to the linker, but I don't understand why they would want to turn it on by default in such an annoying way. This cost me hours. It's partly my fault for not reading the upgrade report carefully; it did mention something about manifests. Had I been super-careful, I would have looked deeper into this potential problem and perhaps found the actual problem earlier. But since it didn't cause any trouble right away, I was lulled into a false sense of security that Microsoft had not done anything risky to my project.