How do I control the order of the pages in property sheets from my shell extension?


A customer wanted to know whether a shell extension can control the order of the property sheet pages in a property sheet. The IShell­Prop­Sheet­Ext interface lets you add pages and replace pages, but nothing about rearranging them. Naturally a shell extension can control the relative order of its own pages (by changing in the order in which it calls IShell­Prop­Sheet­Ext::Add­Pages) but how can it affect the order of pages from other shell extensions?

Imagine if that were possible. Every shell extension would set itself to be first!

The customer was kind enough to explain what they were doing. "We were more concerned about consistency, because our tab appears in different positions depending on whether you are viewing a file or folder. Nothing critical. It just looked nicer if our extension always appeared in the same location."

Well, sure, it looks nicer for you if your extension always appears in the same relative position. But consider:

Folder
General Sharing Awesome
File
General Awesome

If you imposed a consistent position for your extension, it would have to go into position 2, but then that means that Sharing is no longer in the number 2 position when available. Maybe users like it when Sharing was the second page when available?

Even if you manage to remain in the same position, it might not be in the same position due to changes in text length.

Folder
General Sharing Awesome Previous Versions
File
General Previous Versions Awesome

Sure, your awesome extension is always in third position, but since the length of the string Sharing is not the same as the length of the string Previous Versions, its position is not visually consistent.

Now, sure, maybe Explorer could have a flag Consistent­Position that a shell extension could specify to indicate that it wants a consistent position, and let Explorer figure out how to arrange the tabs in order to achieve that. In the second example above, you would get

Folder
General Awesome Sharing Previous Versions
File
General Awesome Previous Versions

but that's easy because you have only two cases to reconcile and because you have only one person who specified Consistent­Position.

Let's say that there are two shell extensions which specify Consistent­Position. The Awesome extension applies to files whose extensions contain the letter A, and the Brillant extension applies to files whose extensions contain the letter B. You now have the following cases:

.A
General Awesome
.B
General Brillant
.AB
General Awesome Brillant

Now there is no placement of property sheet pages such that Awesome and Brillant can both have a consistent position.

And I'm not even counting the cases where property sheet extensions hide their pages conditionally at runtime, so this sort of static analysis becomes impossible.

So no, you cannot force your property sheet page to appear at any particular position.

Comments (18)
  1. Paul says:

    I wish people would think things through. They stop at what is intuitive and make everyone else do the work. Ugh.

  2. Jeff says:

    So many of these requests still stem from the fact that most people think of computers as a smart person who thinks really fast. If it were a person it could make a visual assessment, judge priorities, in every case, and rearrange accordingly.

    Of course, computers are not people so they need the rules defined ahead of time, and therefore can't know what to do with undefined cases.

    I think a lot of this comes from movies creating unrealistic expectations of what a computer really is.

  3. Danny says:

    @Jeff – Hackers with Angelina Jolie have computers both awesome and brilliant :P.

  4. Or Explorer could define a well-ordering (e.g., alphabetically by title) and then the order would be deterministic.

    Awesome

    Brillant

    General

    Sharing

    Previous Versions

    But then the AddPages order would be irrelevant, so this would be a reduction in the amount of control that extension authors have.

    On the other hand, if the user is looking for a particular page, this makes it easier for them.

  5. Damien says:

    @Maurits – yes, because sorting alphabetically didn't lead to any attempts to "game the system" in e.g. telephone directories.

    "Hello, you're through to AAAAAAAAAAAAAAAAAAAA Window Cleaners, how can I help you?"

  6. Begemoth says:

    @Mauritis – How about a case when you install an extension with say English only interface (and English page title) onto a localised Windows (e.g. Russian).

    Naturally Explorer would sort pages using  Russian language alphabet, which is very different from English. What does Explorer need to do? Place English pages first, the last?

  7. Rick C says:

    @Danny, we're talking about brillance, not brilliance.  If you haven't clicked the link in the post, you should, to get the little Easter Egg Raymond left us.

  8. Aidan says:

    @Maurits – Alphabetically in whose locale?

    (if it changes depending on the user locale, you'll need to be able to read the user's language in order to know which tab to click on)

  9. Kevin says:

    Unicode already solved the "how do I alphabetize arbitrary strings" problem with the Unicode collation algorithm.

  10. @Mauritis: Consider single shell extension adding multiple tabs. Likely, there is some logical connection between the tabs so they should be next to each other.

  11. I agree that it makes sense for the well-ordering to consider not only the names of the tabs but also whether the tabs are from the same shell extension.

  12. cheong00 says:

    @Mityador: Agreed. I'm also thinking about similar scenario when I'm reading this, only that I'm thinking about multiple extensions of same company instead of one.

    If single extension needs multiple tabs, I think it should consider opening popup like the "Advanced" button in "Security" tab.

  13. asdbsd says:

    Yeah, I think they may have been asking about consistent ordering. After all, even default tabs don't always appear in the same location.

  14. John Doe says:

    @Raymon, since the customer was asking about *relative* position, why did you have the trouble of ranting with 2 examples of *absolute* position?

    On the other hand, why would there be a need for a Consistent­Position flag? Would every thing else be consistent too? If they weren't, the consistent relative position of Consistent­Position = true tabs wouldn't actually be consistent. Maybe you'd group the consistent (first or last)?

    However, consistency should be global, we're talking UIs and UX here. Thus, it would make more sense for Explorer to (try to) be consistent, as long as you don't promise/document such consistency. One way is to remember in which order tabs were created since Explorer started. It would not be consistent between Explorer instances, but it would be consistent throughout a "normal" session. Predictability would increase, and so would user confidence.

    And in the end, your last paragraph still stands, but now with a little more effort implemented in Explorer.

    [If you look past the words to the meaning, you can see that they want the same absolute position: They want the tab to appear "in the same location." Perhaps even the same absolute pixel position (150 pixels from the left edge). -Raymond]
  15. DWalker says:

    @Paul:  Right you are!  "Imagine if that were possible."  I don't understand why more people don't do that.

    You don't, and shouldn't, have control over "other people's things".  Including what order they appear in relative to your things.

    Of course, now that the better-looking standard for a lot of options is to have category selections down the left side, the tabs at the top of a property sheet page look a bit outmoded.

  16. Joshua says:

    [If you look past the words to the meaning, you can see that they want the same absolute position: They want the tab to appear "in the same location." Perhaps even the same absolute pixel position (150 pixels from the left edge). -Raymond]

    Potential solution: flag that says I always show up (General would have it). All property sheets that always show up appear before all property sheets that don't always show up.

    [That doesn't solve the A/B/AB problem, though. Or perhaps you're saying "If you want a fixed position, you must be marked 'always show'." -Raymond]
  17. Joshua says:

    [That doesn't solve the A/B/AB problem, though. Or perhaps you're saying "If you want a fixed position, you must be marked 'always show'." -Raymond]

    Yup. If it always shows, then it will be in the same position to the user all the time barring only install/uninstall of shell extensions.

  18. Angry sibling says:

    It's not fair. I want the position that my sibling has. Whatever that is.

Comments are closed.

Skip to main content