Patch to fix "create new folder" on the desktop.
Without the patch, after creating a new folder on the desktop, the item is NOT automatically set in edit mode for rename. It is necessary to select the item manually and rename it.
With the patch it is automatically enter edit mode for rename.
The patch is not that big, but finding the problem has been a good learning experience
Patch to fix "create new folder" on the desktop.
Patch to fix "create new folder" on the desktop.
- Attachments
-
- patch_30__v163.7z
- (1.48 KiB) Downloaded 524 times
-
- Site Admin
- Posts: 933
- Joined: Sat Apr 18, 2009 1:46 am
Re: Patch to fix "create new folder" on the desktop.
I've taken a look into the issue just now, and it's caused by the difference between the users desktop and virtual desktop. IShellFolder::CompareIDs only compares the relative ordering between items. While the parsing path of the two items is the same, their relative ordering is NOT. That is, IShellFolder::CompareIDs is returning 1 to indicate that the "virtual" item should follow the "real" item, even though they point to the same physical file.
If you examine the pidl structure for the users real and virtual desktops under a debugger, you'll notice that the virtual desktop pidl has cb=0, while the real desktop pidl has cb != 0 (so they're clearly distinct). When a new folder is created from the toolbar, it is placed in the directory given by the parsing path (i.e. C:\Users\David\Desktop). So the pidl that is extracted and sent to QueueRename() is built off the "real" desktops pidl.
Meanwhile, the pidl its compared to in InsertAwaitingItems() is constructed as:
Note that m_pidlDirectory refers to the virtual desktop.
So, these two pidl's are passed to IShellFolder::CompareIDs, which then says that they're relative ordering is not the same. Which IMHO is fair enough, since one item technically resides on the "virtual" desktop, while the other is on the "real" desktop.
It's easy enough to verify this behaviour: set up two pidl's (pointing to an item on the desktop), one built from the real desktops pidl, one from the virtual desktops pidl. Then, compare them using IShellFolder::CompareIDs. You should get the following results:
Argument 1|Argument2 -> Return Value
Virtual|Real -> 1
Real|Virtual -> -1
Virtual|Virtual -> 0
Real|Real -> 0
It's also important to note that when you create a folder using the right click menu, it is put into edit mode successfully. The reason behind this is is that the menu is constructed using a pidl, rather than a parsing path.
Taken all together, this means that parsing paths and pidl's probably shouldn't be mixed. If you want to re-submit a patch for this issue, I'd be happy to look at it. Basically, it needs to ensure that the pidl's that are compared are of the same type (both real or both virtual). A better solution might be to modify CompareIdls so that it will correctly compare pidl's that are real/virtual (i.e. check if the types differ, and if they do, transform one into the other).
If you examine the pidl structure for the users real and virtual desktops under a debugger, you'll notice that the virtual desktop pidl has cb=0, while the real desktop pidl has cb != 0 (so they're clearly distinct). When a new folder is created from the toolbar, it is placed in the directory given by the parsing path (i.e. C:\Users\David\Desktop). So the pidl that is extracted and sent to QueueRename() is built off the "real" desktops pidl.
Meanwhile, the pidl its compared to in InsertAwaitingItems() is constructed as:
Code: Select all
pidlComplete = ILCombine(m_pidlDirectory,m_pExtraItemInfo[(int)itr->iItemInternal].pridl);
So, these two pidl's are passed to IShellFolder::CompareIDs, which then says that they're relative ordering is not the same. Which IMHO is fair enough, since one item technically resides on the "virtual" desktop, while the other is on the "real" desktop.
It's easy enough to verify this behaviour: set up two pidl's (pointing to an item on the desktop), one built from the real desktops pidl, one from the virtual desktops pidl. Then, compare them using IShellFolder::CompareIDs. You should get the following results:
Argument 1|Argument2 -> Return Value
Virtual|Real -> 1
Real|Virtual -> -1
Virtual|Virtual -> 0
Real|Real -> 0
It's also important to note that when you create a folder using the right click menu, it is put into edit mode successfully. The reason behind this is is that the menu is constructed using a pidl, rather than a parsing path.
Taken all together, this means that parsing paths and pidl's probably shouldn't be mixed. If you want to re-submit a patch for this issue, I'd be happy to look at it. Basically, it needs to ensure that the pidl's that are compared are of the same type (both real or both virtual). A better solution might be to modify CompareIdls so that it will correctly compare pidl's that are real/virtual (i.e. check if the types differ, and if they do, transform one into the other).
Re: Patch to fix "create new folder" on the desktop.
Good, thanks for some additional tips David. I will rework the patch.
Modify "CompareIdls" was my original solution, but it did cause some problems (probably due to my lack of knowledge of some things).
Modify "CompareIdls" was my original solution, but it did cause some problems (probably due to my lack of knowledge of some things).