10554 R-C Explorer can show bogus commands

[chrisjj]

> As I said, the only thing that BC does is generate a base directory and a list
> of relative paths, which we then pass to Explorer.

Well, yes, that does seem to be the cause of the problem.

You said BC was doing the best it can. Why can it not do the better thing I suggested?

[Zoë]

I thought I was clear. BC has no control whatsoever over what the menu includes. We give Explorer a list of filenames, not a list of file types. We do not read from the registry, we do not talk to the shell extensions. We say "here's a list of files" and Explorer says "here's the menu for those files". There's no special tricks or low-level hacks we can do to improve the situation. The only choices are the current behavior or no menu.

[Michael Bulgrien]

If you select multiple files that reside in different folder paths, IE returns a combined context menu for folders and the file type you have selected. If you select multiple files from the same folder, IE returns the context menu for just that filetype.

Craig: If the selected files have the same file type on both sides of the compare, and the selection does not span multiple folder depths, why not just give IE the list of files from one side of the compare. It seems like this would be an easy check, and would give an accurate context menu for normal file-pair selections. If the user selects multiple files at different folder levels... then they have to deal with what they get.

[Zoë]

If the selected files have the same file type on both sides of the compare, and the selection does not span multiple folder depths, why not just give IE the list of files from one side of the compare.

Are you suggesting that if a pair of files are selected we'd only pass in one of them? In that case, which one? We've carefully avoided using "Mine" or "Theirs" in the interface, and I know for a fact that there's a good mix between customers that primarily work with files on the left and those that do so on the right.

[Michael Bulgrien]

If the file types are identical, does it matter which side? How about the side that currently has focus? If one side is local and one side is remote, perhaps the local file?

Perhaps I am missing a piece of the puzzle. If you only send in the paths from one side of the compare, does that change the execution of the explorer context menu item (i.e. not perform the activity on the other side)? Or can you apply the action to both sides even though you only send in a file list from one side to build the context menu?

[Michael Bulgrien]

Also, forgive my ignorance... I am not trying to be difficult, just trying to look at all the options. When IE returns the contents of the context menu, can BC3 reconstruct a copy of the context menu? Or is BC3 blind to the items in the IE context menu?

If BC3 can iterate through the context menu without displaying it, you could send both sides to IE as separate lists then combine the results in a reconstructed context menu. If its not possible, fine. Just trying to think outside of the box...

[Zoë]

File types have nothing to do this this.

The API is basically this:

Menu = Explorer.GetMenu(Base Directory, List Of Files)
IndexOfSelectedItem = Menu.Popup
Menu.InvokeCommand(IndexOfSelectedItem)

So yes, if we only send in the files from one side of the compare it will have vastly different results than passing in the files from both sides.

[Michael Bulgrien]

File types included in the "List of Files" is what determines the items in the IE context menu... that's all I was suggesting. A file list of the same file types from either side would result in the same content in the IE context menu (which differs from the bogus file menu options returned if the file list contains files from both sides).

If it were possible to apply the results of the API call to more than the original file list, then it would be possible to code a work-around to the strange entries on the context menu when you choose two files with the same format from two different folders.

For example:

Confirm that file types in selection are the same on both sides, then:

Menu = Explorer.GetMenu(Base Directory, List Of Files from one side)
IndexOfSelectedItem = Menu.Popup
Menu = Explorer.GetMenu(Base Directory, List Of Files from both sides)
Menu.InvokeCommand(IndexOfSelectedItem)

[Zoë]

IndexOfSelectedItem is only valid for a particular menu. As soon as you pass in a different list of files the indices will all change.

[Michael Bulgrien]

And.... my point is that if you have a single file pair, with the same file format on both sides (as ChrisJJ was complaining about), the context menu should be the same for both files, and the indeces should match.

For a bigger selection, if the list of filetypes on both sides match exactly, then the context menu should be the same for both lists.

I can understand not wanting to mess around with a large selection of files, but I would think it would be fairly easy to implement with a single file-pair...would not take much coding effort, and would be extremely easy to back out if testing proves that it doesn't work as well as anticipated. Just my thoughts...

Menu = Explorer.GetMenu(Base Directory, List Of Files from one side)
IndexOfSelectedItem = Menu.Popup
Menu.InvokeCommand(IndexOfSelectedItem)
Menu = Explorer.GetMenu(Base Directory, List Of Files from other side)
Menu.InvokeCommand(IndexOfSelectedItem)

[Zoë]

Invoking a command for a single file one after the other is not the same as invoking for a pair of files. Winzip's "Add to Zip" is a trivial example, since it pops up a dialog box. Beyond Compare's own "Compare" vs "Select Left For Compare" is another.

There is also absolutely no guarantee that the menus for two files with matching types will be the same. You could quite easily have a shell extension that looks at the content of a file, or its DOS attributes, or its size, and is only present if it sees something it likes. To continue picking on WinZip, it shows completely different menu items for self-extracting zips vs regular exes.

The behavior is what it is, and as I already said, there isn't a clever way to combine menus, filter menus, or make it "do the right thing". If you have a shell extension that doesn't support what BC is doing you can ask them to fix it. We can't. End of story.

[Michael Bulgrien]

It never hurts to brainstorm... I'm sorry you are getting so frustrated with this conversation. Like I said earlier, I wasn't trying to be a pain by suggesting something unreasonable... I was just trying to look outside the box.

If it were me behind the code, I would probably try it... I don't know what methods are available, but find it hard to believe that you couldn't get the context menu from each side indepenently, look at the menu items...and if they match, display a popup from one side and execute the command against both sides. If they don't match, get the menu from the combined list. I wouldn't make it core code, but would consider making it a tweak.

But I'm not the one behind the code... and I'm not going to get bent out of shape about it regardless of the decision. Your "End of story" is fine with me so long as you've considered your options with an open mind...and percieved inconsistency in how a menu is displayed and processed is probably as good a reason as any not to do it.