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.

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.

@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]

[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.