E++ no longer expands to shell folders in nav pane. (W11)

[topbanana]

I think this started with Windows 11

Before it all worked great... But now, when go to my "Downloads" folder using a Explorer++ bookmark i created, it no longer expands the tree to that folder in the navigation pane. No folder, or the previous folder is still selected in the nav pane.
This used to work great before, but bloody M$ changed something in the shell to break it i guess.

Using W11 and the latest dev builds from AppVeyor.

Thanks!

[David Erceg]

It looks like the folders no longer compare equal. That is, when you enter the path "C:\Users\{username}\Downloads", the resulting ITEMIDLIST no longer compares equal to the ITEMIDLIST for the "Downloads" folder on the desktop. Which is unexpected, since that works in Windows 10 (where the "Downloads" folder is under "This PC"). "This PC" also isn't considered to be a parent of the "C:\Users\{username}\Downloads" ITEMIDLIST, which is why that path isn't expanded.

It's hard to tell what's going on, since the ITEMIDLIST structure is opaque and undocumented. The comparison function is documented, but works in a similarly opaque way. Explorer does the right thing, but I have no insight into how it performs comparisons.

[David Erceg]

Also, to expand a bit more on why "This PC" isn't considered to be a parent of "C:\Users\{username}\Downloads", the reason is that parsing paths (e.g. paths like "C:\Users\{username}\Downloads") aren't unique in the shell namespace. In the filesystem, they are. You can't have two filesystem items that have the same path, but are actually different. In the shell namespace, you can have multiple items that have the same parsing path, but are different.

For example, the root desktop folder (that appears at the top of the treeview) has a parsing path of "C:\Users\{username}\Desktop", even though it's a different item to the one located at "C:\Users\{username}\Desktop" in the filesystem. You can see that by opening both folders in separate tabs - they have different items and a different context menu. When the user enters "C:\Users\{username}\Desktop", it's ambiguous as to which folder they're trying to access - the root folder or the filesystem folder.

When "C:\Users\{username}\Downloads" is entered, Windows performs the actual parsing step and creates an ITEMIDLIST that doesn't refer to the filesystem folder. That's why "This PC" isn't considered to be a parent. It's likely referring to an item in the shell namespace, though seemingly not the item on the root desktop. It's hard to tell what's happening, since the way Windows performs the parsing is completely opaque.

Personally, I dislike the fact that parsing paths aren't unique in the shell namespace. It means you can't check whether two folders are equivalent by simple performing a string comparison on their paths.

[topbanana]

M$ changing it is one thing... But making the new workings opaque just isn't cricket!!!

It's just bonkers that bookmarking any other non-shell folder in my user folder works just fine... But 'Downloads', 'Documents, etc. doesn't... So it intercepts the path? Crazy.

Hopefully this might one day be documented................................... one day...

Thanks David!

[topbanana]

Hi David,

Has there been any progress wrt these changes that MS made? Knowing how it works now?

It's a constant pain for me, every day, with no way of it expanding to the folders, as it should.

Cheers.

[David Erceg]

From what I remember when I looked into it a few months back:

- When transforming a path like "C:\Users\Username\Downloads" into a shell item, the shell would return a reference to an item on the desktop.
- That item wasn't the same as the "Downloads" item that typically appeared. If you enumerated the desktop folder after navigating to the downloads folder, you'd have two "Downloads" items, since the second item would then appear (you could see that by opening the root desktop folder in another tab).
- The normal "Downloads" item wouldn't be selected because it wasn't the item being referred to.
- Explorer would create the second item in the treeview manually when it needed to select it. Explorer++ doesn't do that, which is why nothing would be selected.

I'm working on another unrelated change now and it looks like part of that change is actually fixing this issue. That is, when I create a bookmark to the downloads folder and click it, the filesystem folder is selected in the treeview. Ultimately, this still appears to be a bug in the shell functionality, but at least it looks like it can be worked around.

[topbanana]

OK, cool!
Fingers crossed this works out.
It will be very much appreciated when you eventually beat this puzzle!

[topbanana]

I'm working on another unrelated change now and it looks like part of that change is actually fixing this issue. That is, when I create a bookmark to the downloads folder and click it, the filesystem folder is selected in the treeview. Ultimately, this still appears to be a bug in the shell functionality, but at least it looks like it can be worked around.

Ooooh!
It seems to be working again!
I have Downloads and Music bookmarked, and they now expand out to show the folder in my user folder...! Yippee!!

Explorer++ version 1.5.0.2361 dev (64-bit build)

Many thanks!