10554 R-C Explorer can show bogus commands

[chrisjj]

e.g. on
http://img42.imageshack.us/img42/6673/picu.th.png (http://img42.imageshack.us/img42/6673/picu.png)
shows Explore.

Clicking it doesn't open an Explorer window with the file highlighted, as hoped for. It does nothing.

[Aaron]

If you right-click that exact file in My Computer/Explorer, what right-click menu do you see? Please attach a full screen screenshot.

[chrisjj]

> If you right-click that exact file in My Computer/Explorer, what right-click
> menu do you see?

The expected one - no Explorer

> Please attach a full screen screenshot.

This forum disallows that due to storage limit so I hope this link will do.
http://img440.imageshack.us/img440/475/48894488.gif

[Craig]

Are you running a 64-bit version of Windows? BC is a 32-bit app, so it shows 32-bit shell extensions, which can be different than the ones you'll see in Explorer, since it's a 64-bit app.

[chrisjj]

> Are you running a 64-bit version of Windows?

No:


System:
Microsoft Windows XP
Home Edition
Version 2002
Service Pack 2

[Chris]

BC is just displaying the right click menu for Windows Explorer. Do you see "Explore" after right clicking on the same files in Windows Explorer? Explore should only be listed for folders, not for files.

[chrisjj]

> BC is just displaying the right click menu for Windows Explorer.

Evidently not. Explorer's r-c- menu on a WMA does not include Explore or Paint Shop Pro!

> Do you see "Explore" after right clicking on the same files in Windows Explorer?

No, as this already showed: http://img440.imageshack.us/img440/475/48894488.gif

> Explore should only be listed for folders, not for files.

Agreed :)

[Michael Bulgrien]

Evidently not. Explorer's r-c- menu on a WMA does not include Explore or Paint Shop Pro!

What you have in your screenshot is a combination of Explorer's right-click options for a file and a folder. I could easily duplicate it by selecting a folder, scrolling the selected folder out of view, then pressing the Ctrl key and selecting a file pair. The resulting context menu would give options for both folders and files even though the visible selection is just files.

I don't know why your selection is being treated as a mixed file/folder selection. Neither do I understand the contents of the path dropdown on the right-hand side. If you select a file pair in BC3 under normal local pathnames, you should find that the Explorer sub-menu in BC3 will indeed reflect the Explorer context menu for the same file type.

[chrisjj]

> I could easily duplicate it by selecting a folder, scrolling the
> selected folder out of view, then pressing the Ctrl key and
> selecting a file pair.

No folder selection is necessary here:
http://img38.imageshack.us/img38/1834/97085151.th.gif (http://img38.imageshack.us/i/97085151.gif/) (BC 10721)

> Neither do I understand the contents of the path dropdown on the
> right-hand side.

That's a true display of the (admittedly unusual) base folder pathname, TMK.

> If you select a file pair in BC3 under normal local pathnames

The above screenshot shows the full pathnames, and they look normal to me.

>, you should find that the Explorer sub-menu in BC3 will indeed reflect the
> Explorer context menu for the same file type.

Agreed. But though I do find that for a singleton, I don't for a pair.

FTR, this is Windows XP SP2 and BC was run normally, rather than through Run As... .

Thanks for your input Michael.

[Aaron]

Hello,

I talked with one of our developers about this. BC is actually handling this situation as best it can. The Explorer menu is not generated by BC3, but by Windows.

The problem is that each Shell Extension can expect different information passed to it. When you select 2 files in different subfolders, and then right-click, Beyond Compare's shell extension and a few other text editors can handle this case correctly.

Since this type of selection is physically impossible to do in My Computer, then the "Explore" shell extension does not handle it well. Try to select the same two files in My Computer and right-click to see the selection. You should notice that you can't perform that type of selection, and it will only select one.

[chrisjj]

> When you select 2 files in different subfolders, and then right-click,
> Beyond Compare's shell extension and a few other text editors can
> handle this case correctly.

Can or can't?

[Craig]

It depends on the specific shell extension.

When BC wants to display the context menu it has to give Explorer a base directory and a list of files/folders relative to that base folder. When Explorer shows its own context menu those files/folders are always directly under the base folder, so there's no extra path information. In BC, if you have a selection that spans multiple folders the list will include relative information, like:

Base folder: C:\
File List:
"Program Files\Beyond Compare 3\BCompare.exe"
"Pagefile.sys"
"Users\"
"Temp\File.txt"

Some shell extensions will see those paths and do the correct thing. Others will just see the parent folders in those relative paths ("Program Files", "Temp", etc), and give the listing for those instead of the files.

BC does the best it can in this case, and it's up to the shell extensions to do the right thing. The only alternative would be to not offer the Explorer submenu at all if the selection spans multiple folders.

[Aaron]

I'll help clarify my "BC's shell extension" statement.

It can, in that if you select two files, right click and under the Explorer menu, the BC options (Compare, Select as Left Folder, Comapre to left folder, etc) work based on your selection. So if you select 2 files in BC3, then go to the Explorer context menu, you will see "Compare" and it works as expected since we've programmed this case in. A few other Text Editors and other programs like 7zip also work.

"Explore" does not handle this as well, since My Computer can not present the same list.

[chrisjj]

> BC does the best it can in this case,

In this case, the two selected files are the same type. Why cannot BC simply show the correct Explorer menu for that single type?

[Craig]

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. Explorer generates the menu; we don't have any control over it's contents.

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

[Craig]

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.

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

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

[Craig]

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)

[Craig]

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)

[Craig]

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.