Psychic debugging: Why you can’t control page navigation when using PSP_DLGINDIRECT

Here's a problem that floated past a few years ago.

We switched our wizard from using dialog resource IDs to using PSP_DLGINDIRECT because [reasons deleted since they aren't important]. But once we did that, the Next button doesn't work! Anybody have any ideas what's going on?

I made things a little easier by deleting the information that isn't relevant to the problem. See if you can solve it before reading further.

Here's my reply:

My psychic powers tell me that your wizard navigation code is still trying to navigate by ID even though you aren't using IDs any more.

The PSN_WIZNEXT and PSN_WIZBACK notifications allow you to control navigation by returning the dialog identifier of the page you want to go to. If you change from dialog identifiers to indirect dialogs, you have to remember to update your page-switching logic as well.

But how do you specify pages when you aren't using dialog resource IDs?

Let's take a step back and look at the way dialogs are specified. There are three ways to do this:

  • By dialog resource ID: psp.pszTemplate = MAKEINTRESOURCE(n)
  • By dialog resource name: psp.pszTemplate = TEXT("name")
  • By dialog resource indirect: psp.pResource = lpTemplate. If you use this method, you also have to set the PSP_DLGINDIRECT flag.

If you look at the property sheet page structure, you'll also notice that the pszTemplate and pResource members are actually unioned together; they are just alternate names for the same thing.

If you specified your page via dialog resource ID, you can return that dialog resource ID; but what if you used a dialog resource name or an indirect dialog? Well, since the dialog resource ID, resource name, and indirect dialog are all stored in the same place, you just pass whatever you passed in the PROPSHEETPAGE.pszTemplate / pResource originally. All the property sheet manager does is compare the value you pass in with the value you specified in the PROPSHEETPAGE. (As of this writing, the documentation doesn't make this clear; I've submitted a doc change request to fix it.)

This technique works with PSN_WIZNEXT, PSN_WIZBACK, and PSN_SETACTIVE. It should work in principle with PSM_SETCURSELID and PSM_IDTOINDEX, except that there was a bug on 64-bit Windows XP (fixed in Windows Vista) that prevented it from working: The value you pass in was accidentally truncated to a 32-bit value. Oops.

Comments (6)
  1. cmov says:

    Now this ofcourse begs the question (sorry if it’s answered already): “How do I work around that problem in 64-bit Windows XP?” (not using PSP_DLGINDIRECT and moving back to resource IDs isn’t a valid answer).

    [Are you asking out of curiousity or because you are running into this problem? I would rather not spend the time researching a problem that nobody is actually encountering. (P.S., that’s not what “begs the question” means.) -Raymond]
  2. Anthony Wieser says:

    From an app compatibility point of view, could Microsoft fix this bug in a service pack, since presumably whatever workaround people use to get round it at the moment will continue to work and the rest of us can just write to how it should work, or is it likely to stay as it is, as time has moved on, and we’re on to Vista?

    I’m just curious as to what the general philosophy is on correcting and/or documenting this sort of mistake at Microsoft, and how that feeds back to MSDN documentation.

    Currently, searching for PSM_SETCURSELID with BUG, PRB or truncated turns up nothing on MSDN or google on my cursory view.

  3. cmov says:

    I’m not actually running into the problem. I’ll get back to you when I do (probably never). Can’t tell for everyone though.

    And yes, you are right about BTQ. I don’t understand most of the grammatical mumbo jumbo here: but now I know it should’ve been "This raises the question".

  4. Archangel says:

    Am I the only one wondering what a "curse lid" was at first when I saw PSM_SETCURSELID? :)

  5. Mr Cranky says:

    Yeah, you probably have evil thoughts when you go to Pen Island’s website, too.  

  6. cmov says:

    That’s nothing, I’ve had to use a clueless web proxy that blocked requests for like RegisterClassEx and InitCommonControlsEx. The MSDN pages themselves would work but I couldn’t find them -_-‘

Comments are closed.