Visual Studio

Problem: The Find in Files dialog in Visual Studio (2003, 2005, or 2008, at least) refuses to search the entire solution, claiming "No files were found to look in. Find stopped progress."

Solution: Press Ctrl + Scroll Lock while Visual Studio has focus. Find in Files will then work as expected.

Allow me to add my voice to the dozens of others across the Internet in saying: what the hell? The good news is, I did actually find one voice explaining things. Well, a couple, but they're easily synthesized. The bad news is, it really is as crazy as it sounds.

First, there is Raymond Chen's explanation that Ctrl + Scroll Lock and Ctrl + Break are the same thing as far as the keyboard — the physical electronic device at your fingertips — will ever admit. While perhaps unreasonable, certainly any unreason there is unlikely rightfully to be laid at the feet of Microsoft.

And in fact Ctrl + Break works as well as Ctrl + Scroll Lock. And seems inherently much more plausible, to boot: even without further explanation I could vaguely understand, and even see as plausible, the statement that a Ctrl + Break might jar something loose in Visual Studio's internals. It's normally code for "cancel build", and (disregarding the universal Undo-Cut-Copy-Paste collection) is easily the keychord I use most frequently in VS that doesn't deal with the clipboard; but it's applicable in a much wider range of scenarios than Visual Studio under its nom de guerre of VK_CANCEL.

Unfortunately that latter name is where the problem starts to kick in, and you can see the rest of the explanation here. Find in Files (quite sensibly) runs in a separate thread from the main UI thread, and if you press the 'Stop Find' button on its dialog, the main UI thread will pass a cancellation signal to FiF. However, the FiF thread also pretends to have some right to the UI, and calls GetAsyncKeyState(VK_CANCEL) directly to find out if the user is 'currently' (i.e., whenever the FiF thread happens to check, in between scanning file contents or waiting on crazy-high-latency over-the-network blocking operations) holding down VK_CANCEL.

Leaving aside the immediate implication that it's quite plausible that an irritated-verging-on-enraged user can jab Ctrl + Break several times without FiF noticing — and if you think this isn't normal user behavior, you've clearly not used any recent release of Visual Studio — there's apparently a known bug (see previous link) in GetAsyncKeyState that causes it to sometimes go spung! when accompanied by cross-application focus-shifts. (As if debugging WM_ACTIVATE handlers wasn't bad enough on its own.)