Psychic debugging: Why you can't control page navigation when using PSP

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

Date:	April 18, 2007 / year-entry #135
Tags:	code
Orig Link:	https://blogs.msdn.microsoft.com/oldnewthing/20070418-00/?p=27203
Comments:	6
Summary:	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...

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)

cmov says:

April 18, 2007 at 1:54 pm

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]
Anthony Wieser says:

April 18, 2007 at 5:02 pm

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.
cmov says:

April 18, 2007 at 6:17 pm

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: http://begthequestion.info/ but now I know it should’ve been "This raises the question".
Archangel says:

April 18, 2007 at 7:55 pm

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

April 18, 2007 at 9:44 pm

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

April 19, 2007 at 3:26 am

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.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

A "redesign" after 2019 erased thousands of user's comments from previous years. As many have stated, the comments are nearly as important as the postings themselves. The archived copies of the postings contained here retain the original comments.
The blog has changed domains many times and the urls have otherwise been under constant change since 2003. Even when proper redirection has been set up for those links, redirection only works for a limited period of time. For example, all of the internal blog links that were valid in early 2019, were broken by 2020 without proper redirection.
The blog has been under constant re-design and re-theming since its inception. It is downright irritating to deal with a bogged-down site experience as the result of the latest visual themes designed for cell-phone browsers. As of this writing, it is cumbersome to navigate titles with only 10 entries per page. While it is nice that the official site has a search feature, searching using this index (with all titles on a single page) is much quicker (CTRL-F in most browsers).

<-- Back to Old New Thing Archive Index