Why do I sometimes get classic buttons and sometimes themed buttons depending on the host process?

A customer reported that their printer configuration property sheet page looked different depending on the host process. In some processes, the printer configuration dialog had the classic look of Windows 2000, but in other processes it has the themed look of Windows XP and later versions.

The printer driver calls the Create­Property­Sheet­PageW to create the property sheet page that contains the push-button, radio-button, and other controls. We've confirmed that we call the function with the same parameters each time, but the results are different depending on which program is doing the printing. We've confirmed that both applications are using version 6.0 of the common controls library. Can you provide pointers for investigating why we are getting the old-school look sometimes?

It's clear that the problem is that the property sheet page is being created with a different activation context depending on the host process. If the activation context is a v6 context, then you get the themed buttons; if the activation context is a v5 context, then you get the classic buttons. The fact that version 6.0 of the common controls library is loaded by the process is not relevant; what's relevant is which version is active at the time the dialog is created, since that's the time the class names are resolved.

If the problem were with a regular dialog box, then you can explicitly activate the v6 context before calling Dialog­Box, or you can use isolation awareness to have the activation code generated for you.

However, the case here is a property sheet page. Since property sheet pages are created on demand (when the user selects the page), you don't have direct control over the code that calls Dialog­Box in order to activate your v6 manifest. Instead, use the hAct­Ctx member of the PROP­SHEET­PAGE structure and set the PSP_USE­FUSION­CONTEXT flag in the dwFlags.

Trivia: Fusion was the code name for the feature which includes things like isolated applications, application manifests and redirection files. And because they were apparently a bunch of nerds (quelle surprise!) they named the initial version Hydrogen.

Comments (20)
  1. Bert Huijben says:

    @Raymond, was your post tool somehow delayed? I didn't see your post when I checked on 16.15 CET (7.15 PST).

  2. Adam Rosenfield says:

    Is there a feature/product with code name Fission?  (Cue xpclient mumbling something about removing features)

  3. Karellen says:

    But, but,… the first/simplest product to come from fusion is Deuterium. Or at least Hydrogen-2. (Deuterium would definitely be the coolest product name though :-)

  4. Damien says:

    @Karallen – but who said the product was more important/interesting than the reactant?

  5. alegr1 says:

    Inheriting the behavior from the hosting process is almost certainly the correct behavior.

    Makes more sense than corrupting the host with the guest settings (like some printer drivers did).

  6. John Doe says:

    @Joshua, but that's what happens.

    The hosting process's EXE might not have a manifest, so it probably dynamically creates an activation context with common controls 6.0. However, that only works for the threads where it's done.

    So, if this printer configuration property sheet is created in another thread, it must activate a 6.0 context, which must be like Raymond said for property sheet pages.

    I'm not sure, but it might also be necessary in the event that a 6.0 context was active when creating the dialog that contains the property sheet, but that context is no longer active after its creation (i.e. dispatching messages). I don't know if this is safe either, I've never tried it.

    PS: Less commenting around Christmas? We can't queue comments for the queued posts :)

  7. Christian says:

    The whole stuff with activation contexes was always over my head. Looks really complicated to make both versions of comctrls work together.

    But what would have happened if Microsoft had just updated comctrl like it was always done before (i.e. with IE4). What exactly would have been broken? What kind of incompatibilites are we looking at that was not so bad in the old times?

  8. Clovis says:

    Honestly… what a mess. My Mac OSX applications all have the same style buttons, every time, every version, every day.

  9. Joshua says:

    *shrug* Inheriting the behavior from the hosting process is almost certainly the correct behavior.

  10. BC_Programming says:


    Unless they run on Java. In which case they look different.

    Unless they use Carbon, In which case they look different.

    Unless they use their own custom controls, in which case they will only be consistent with System's they tested.

  11. xpclient says:

    There is a bug in Windows 7 and 8 (fixed in Vista SP2 but not incorporated in W7/8) where even if the EXE has a manifest to use visual styles, they are ignored and the program gets the ugly classic look. To "fix" the bug, run the program once in XP compatibility mode. It then "gets" visual styles and even if you remove the shim after it gets them, it retains its themed look. Anyone at MS wanna fix it?

  12. @Clovis:

    Of course, without that mess you would get people who would have had their apps look bad on upgrade to Windows XP and then suddenly "Microsoft broke my application".

    The styled controls were generally a different size to the un-styled controls, so if the dialogs were of a fixed size, then things would start looking wrong as soon as you applied the visual style. You can see artefacts of this to this very day. One well known installer engine has two buttons overlapping when styles are applied to a certain window.

  13. Drak says:

    @Clovis: Now try (with the help of external programs) to run a pre-Mac OSX application on your lovely OSX. IT looks different too, and OSX can't even run it by itself. So, what exactly is the point you are trying to make?

  14. Ian says:

    @Drak: "with the help of external programs" is the crucial difference of course. Apple and Microsoft have taken very different approaches to backwards compatibility. You wouldn't seriously expect software running in a VM always and automatically to match the look and feel of the host OS, would you?

  15. Drak says:

    @Ian: one of my points is that on his Mac, he can't even run software meant for the previous version of the operatin system without needing special tools. Windows allows this without (for the user) special tools. The fact that all his OSX apps look the same is like saying that all apps written specifically for Win7 do have the same looks and feel (if they use the standard controls).

  16. Ian Boyd says:

    @xpclient. I have an exe that is manifested to use version 6 of the Common Controls library. Common controls then render using visual styles.

    Can you post the additional steps so I can reproduce the bug on my system?

    Note: make sure you are not modifying the manifest after the last as cached it. Reboot after modifying the manifest if you are unsure if you have modified the manifest our not.

  17. xpclient says:

    @Ian Boyd, Can't repro it reliably as it seems to happen only for certain EXEs (haven't noticed which ones: some 32-bit EXEs or some EXEs which have external manifests or only EXEs with older XP manifest). Since it goes away after the manifest is cached, I didn't bother looking further.

  18. DWalker says:

    @xpclient:  you didn't bother looking further, and you don't really know if it's a bug, but you'll still file it away as another example of why everything Microsoft is broken.

  19. xpclient says:

    DWalker, I didn't say it is not a bug or I don't know. I have experienced the bug for numerous legacy apps which are properly themed on XP. I said I don't care about to repro the bug. And where did I file away as "everything is broken"? You must be reading imaginary stuff between the lines. If anyone at MS offers to fix it, then I will find a way to repro it. :) What's the use if the bug is not going to be fixed? Is there even an official open mechanism to file bugs without MS Premier Support (which you have to pay for)?

Comments are closed.

Skip to main content