10554 R-C Explorer can show bogus commands

[chrisjj]

e.g. on

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

[Zoë]

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:
(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?

[Zoë]

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?

[Zoë]

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.