Perhaps this is true for all platforms, but it seems especially true for Microsoft Windows development: because of the number of tricks, code oddities and places where the way things work is completely unclear, it seems that Windows programming experience is measured not so much by length of time, but by the number of battle scars you accumulate fighting some odd little API call or another. You know the feeling: you read MSDN, you make the call you think should work, you’ve got all of the resources in the right place–yet, instead of success you get a null handle or some obscure error code you’ve never heard of.

So off you go to Google, type in the error code–and find about fifty messages in about fifty different sites all saying the same thing: “WTF?” Occassionally suggestions are made–which are about as worthwhile as shaking voodoo sticks and sacrificing chickens to Odin and Thor. Then, finally, you either try shaking your own voodoo sticks or you come across one brief flicker of light amongst the darkness of ignorance–and you discover finally what when wrong. Sometimes it’s an unclear API, or sometimes it’s some odd exception to an existing API that, had you actually had the time to read the entire MSDN article on the subject rather than just skim it looking for the information you need, you would have known about.

Feeling silly and wondering why you didn’t take your mother’s advice to become an Architect, you move on. And another scar hardens on your brain.

I Hate Windows.

As I encounter them, I’ll try to post them here. And I have one that I recently encountered at work with WinCE, though it appears to also apply to the desktop version of Windows.

Where did my help go?

If you press ‘F1’ on your keyboard on Windows, you should get context-sensitive help for your application.

This little bit of magic works by the Windows OS sending your current WinProc an WM_HELP message, which you can then respond to by opening up the on-line help manual to the page which describes the dialog box or window you’re currently working in.

All well and good.

Well, I was converting a bunch of dialog boxes into a tabbed dialog box by using the PropertySheet() call in Microsoft Windows, which worked fairly well.

Except help stopped working.

Scratching my head I discovered that when you live as a property sheet, the callback for your pane looks very much like a DialogProc that you’d pass to DialogBox or some other call like that. Except all of a sudden many messages that have a perfectly valid WM_XXX counterpart–such as WM_HELP–get turned into WM_NOTIFY messages instead.

So, gratuetously, instead of sending you WM_HELP when someone asks for help, you instead get a WM_NOTIFY message with notification code PSN_HELP.

As I was adding the following switch statement to my code:

    case WM_NOTIFY:
    {
        NMHDR *ppsn = (NMHDR *)lParam;
        if (ppsn->code == PSN_HELP) {
            ::SendMessage(hWnd,WM_HELP,0,0);
        } // other notification handlers go here...
    }

I had to wonder–why didn’t Microsoft do this for me? Something perverse? Historic reasons? I dunno, and I suspect resending the message as a WM_HELP message rather than just processing it there at the SendMessage call would be better.

But I wasted a good hour on this one.