The other day I showed a very simple bug. So simple, it simply shouldn't happen. If I ever check in files with that kind of bug, I don't have any defense. Today, I'll show you another bug that's slightly more interesting.
What made the last bug simple was that the entire dialog was self-contained. Everything I needed to know about it, I could see in my localization tool. Turns out, it's pretty common that this is not the case.
Look at these two dialog boxes, as shown in my localization tool:
These look good, hotkey-wise. However, if I'd hand off these files, you can bet that a tester would come back with these bugs:
Ok, that's not good. What happened here is that the dialog I saw in my localization tool was combined with some other gunk at runtime. In this particular case, the gunk comes from comctl32.dll - the file used for almost all properties dialog boxes and wizards in Windows.
Everything looked pretty in my localization tool and that static hotkey check, the one I mentioned yesterday, didn't report any problems. Still, I should have known that this would happen. All the information I needed was there:
There are more hints, but this should really be enough. When I localize, I should be able to figure out how these dialogs are used. But -- if I'm still not careful, how can I detect duplicate hotkeys before runtime?
See, that's trickier. My localization tool can not know how these dialogs are used. Therefore, it can't figure out that #1 above is a property page, therefore it'll be merged with some other dialog in some other DLL (one that's not part of the localization project), and therefore it needs to check all hotkeys here with some hotkey somewhere else.
You could however build some check with logics that iterates through a project and makes a guess based on the hints I describe above. Or you could build and maintain a table of all dialogs in all files that are wizards or properties pages. Since the hotkeys for Apply, Back and Next are known and won't change, the check could fairly accurately find these duplicate hotkeys. It could be done.
But I haven't bothered.
Instead, I use a more... pragmatic approach. I simply never use the hotkeys for Apply, Back or Next anywhere but on those very buttons. This way, I'm sure never to introduce this type of hotkey bug. It might sound heavy handed, since there are plenty of dialog boxes where you could use those hotkeys without trouble. But from what I've seen, if you do that, next time you auto-translate that string with a hotkey on "&n" will spread to a wizard dialog, and you will have an unnecessary bug.
During Server 2003, I changed almost all strings that has the same hotkey as Apply, Back and Next, and I don't use those any more. Since then, I've only had a handful of these bugs.
This posting is provided "AS IS" with no warranties, and confers no rights.