VS2005 and vswprintf

When you upgrade an existing C++ program to Visual Studio 2005, the compiler will tell you any calls to vswprintf lack an argument specified by the C++ standard. Through the magic of C++ function overloading, your code still works, because Microsoft provides both the old-style proprietary three-argument function and the new-style standard four-argument function. The compiler tells you about the new function by means of a warning, and if you're a smart programmer, you've told the compiler to treat warnings as if they were errors in the sense that they prevent an object module from being generated, so there is a fair amount of motivation to adopt the new function so that the warning will go away.

The new parameter is the count of characters in the output buffer. After reading the documentation for this parameter, you might assume that, like the return value, the parameter does not include the terminating 0 character. But that assumption would be wrong; if you pass the number of characters you expect as a return value, the function will return -1 and errno will be set to ERANGE. You need to add 1 to the parameter (after, of course, making sure your buffer is large enough for the terminating 0). MSDN does not document this, and after having guessed at it myself, I searched the web until I found a Linux man page which told me my guess actually coincided with somebody's reality. I've chosen to assume Microsoft plays by the same rules.

Microsoft hell

This story confirms the sense I have gotten over the past few years that the Microsoft work environment has descended into hell. I personally know demonstrably bad people who've been hired there, and there is of course the ongoing suppurating sore that is Mini-Microsoft, and Ballmer is a blatant loser dork who desperately cries out for amputation. But the story puts it in terms geeks can understand.

mouse "moves" when it doesn't move

MSDN claims you'll receive WM_MOUSEMOVE when the mouse moves, and that's true as far as it goes. However, you'll also receive WM_MOUSEMOVE at a number of other times, notably when your window activates or another window moving reveals part of yours. So the real meaning of WM_MOUSEMOVE is "please act as if the mouse moved." That's fine most of the time, even though it means you might do some redundant work. But if you really want to know whether the mouse moved, you need to cache the last known mouse location, call GetMessagePos, and compare the result to your cached value. If the mouse really did move, then update your cache in addition to the other work you do.

Update 7 Dec 2006: St. Chen has already covered this topic. Big surprise.

tooltip message handling nightmare abated

I recently spent a boggling amount of time — a couple of weeks, on and off — second-guessing Microsoft's tooltips message handling code. Not only does it have at least one nasty bug, but it seems designed to make easy cases easy, which is a diplomatic way of saying it tends to make anything beyond that very difficult. Do try it, and see if it works for you, but if you spend more than a day scratching your head and trying to overcome limitations, my recommendation is to skip TTM_RELAYEVENT, turn off all tool flags other than TTF_TRACK and TTF_ABSOLUTE, and get real cozy with TTM_TRACKACTIVATE and TTM_TRACKPOSITION. Oh, and write your own equivalent of TTF_SUBCLASS. Once I realized I ought to give this approach a try, I was out of the woods in just a couple days, and I've written some C++ classes which will relieve me from ever having to deal with this madness again.