[EXPLORER] Don't use Explorers ID_SHELL_CMD IDs in IShellFolder menu

[whindsaks]

Explorer does not control the IDs used by the CFSFolder::QueryContext menu and therefore cannot share its ID range with it. The range passed to CFSFolder::QueryContext also cannot start at 0 because CTrayWindow::TrackCtxMenu would interpret that as user cancel.

Note: IDs clashing is configuration specific, it depends on the shell extensions you have installed that adds its items to folders.

[whindsaks]

This commit changed the meaning of ID_SHELL_CMD causing the ranges to overlap. I don't want to go back to the way it was because that means changes to the Explorer bands. Isolating the IDs for IShellFolder seems to be the best option.

[HBelusca]

@whindsaks Do you think that the commit you mentioned was trying to be more correct than what was existing prior to it, but didn't go all the way there?

[whindsaks]

was trying to be more correct

I think the previous change simply forgot that startctxmnu.cpp was also using the same ID range.

I'm not going to speculate on what is more correct, I can only point out the two common ways ROS gets IContextMenu wrong:

• You cannot share your ID range with a IShellFolders IContextMenu if you use constant IDs when adding your own items to the menu/interpret them in WM_COMMAND.
• If you want to display the menu with TPM_RETURNCMD, a IShellFolders IContextMenu cannot receive a 0 idFirstCmd (because 0 means the user cancelled the menu).

[HBelusca]

looks OK; I just have a minor question about a code block.

[HBelusca]

Can this code block be run even if the CreateContextMenuFromShellFolderPidl() call from above failed (or wasn't executed because either pidlStart was NULL or some of the if-tests failed) ?

[whindsaks]

Yes, you would then end up with a menu that just has Properties, Separator, Open/Explore All Users.