Please help: Open++ context menu and Everything

[DVV81]

There is a nice free program Open++ that allows to configure own menu items integrated into system's context menu.
However, with UAC enabled under Windows 7 64-bit, I have the Open++ menu items everywhere except Everything (Everything is running with Everything Service).
Any idea how to make Open++ context menu to work with Everything in this mode?
(I'm using 32-bit version of Everything and Open++.)

[NotNull]

Any idea how to make Open++ context menu to work with Everything in this mode?
(I'm using 32-bit version of Everything and Open++.)

Without knowing Open++ (a link to the program is missing..):
Install the 64-bit version of Open++.
That will create the context menu handlers and CLSID's in the 32-bit AND 64-bit part of the registry.

[DVV81]

The app name "open++" is easily googled; anyway, its home page is http://opencxx.sourceforge.net/
As for Everything, I wasn't quite correct.
The issue is: for some file types it does show Open++ menu entries, for other file types it does not, though any other program (such as Explorer, Total Commander, FAR Manager) show Open++ menu entries for all files, whatever file type is.
For example, for a .txt file it is shown in Everything:


For a .bin file, however, it is not shown in Everything:


Though it is shown for the very same file in the Explorer:


I could only assume that probably (I am not sure in it) Everything somehow detects the existence of "Open with" ("Открыть с помощью") menu item and for some reason does not allow Open++ to appear when there is no "Open with". It's only a guess.

[NotNull]

The app name "open++" is easily googled; anyway, its home page is http://opencxx.sourceforge.net/

From the link you posted:

OpenC++ is C++ frontend library (lexer+parser+DOM/MOP) and source-to-source translator. OpenC++ enables development of C++ language tools, extensions, domain specific compiler optimizations and runtime metaobject protocols.

easily googled, huh?

[DVV81]

easily googled, huh?

Caught me
The official home page of the program seems to no more exist, so it can be downloaded e.g. here:
http://www.softpedia.com/get/System/OS- ... Open.shtml

[NotNull]

For a .bin file, however, it is not shown in Everything:
Though it is shown for the very same file in the Explorer:

I could only assume that probably (I am not sure in it) Everything somehow detects the existence of "Open with" ("Открыть с помощью") menu item and for some reason does not allow Open++ to appear when there is no "Open with". It's only a guess.

Don't think that is what is going on. I bet (still, without testing Open++) that it registers itself under HKCR\*\Shell or HKCR\*\Shellex. That way it got all file extensions covered.

There are some things that might give a clue:
Everything 'sees' files on a low level, without being hindered by permisiions (ACL's) or redirection (for example WOW: Windows-on-Windows; 32 bit application on 64-bit OS)

• No access to the file
  I have noticed that if the user that is running Everything has no access to a file, it will *not* show the Windows context-menu. Just the Everything context menu. Don't know if that is by design or a bug, but thats how it is.
  For example, Everything query:

  Code: Select all

  c:\users ntuser.dat
  

  and open the context menu of the administrator's ntuser.dat.
  It will not show the Windows' context menu.
• Redirection
  There is a lot of file/folder rediction (emulation) going on in Windows. If you run a 32-bit application and want to open/run a DLL from c:\windows\system32, you actually get this DLL from C:\Windows\SysWOW64.
  You can test this by entring this Everything query:

  Code: Select all

  c:\windows\system32 ext:dll
  

  If you look at the filesize of a DLL in the resultlist, you'll get the System32 version (that is what Everything sees, low-level). If you open the file-properties (Alt-Enter), you get a smaller filesize (the 32-bit one from SysWOW64)
  It is very well possible that a file *is* in System32, but not in SysWOW64. In that case, you will not get the context-menu with a 32-bit Everything.

If you use a program that is so close to the core of the Operating System (like Everything or filemanagers), I would always run it in the bit-ness of the OS. But that's just my opinion ..


Long story short:
Try to copy the problematic BIN file to your desktop. If my theories are correct, that will fail. If it does succeed, you will probably get a context-menu for this file.


P.S. Now I think of it, it is strange that you still see the TortoiseGit context-menu. And why are Everything context menu entries like Delete and Rename shown for a file you don't have access to? (EDIT: I was wrong about the Delete/Rename entries: those come from the explorer context menu)

[DVV81]

I've experimented with a folder created by me, where my user definitely has access to all the files, including creation, deletion, editing etc.
The issue seems to be related to file extension, but I can't see any logic in it:




And, as I mentioned, this situation is unique for Everything - other programs show Open++ menu entries for all the files.

[DVV81]

Maybe when Everything adds its items "Open Path", "Copy Full Name to Clipboard" etc. to the context menu, it overlaps the Open++'s menu item, e.g. by using the same menu item id or offset?
I wish I could debug it somehow...

[NotNull]

I wish I could debug it somehow...

I do know how, but I have lost interest in this. And that's mainly because you're asking for help, but keep ignoring suggestions (or fail to report back on those) and instead jump to yet another theory of what might be wrong.
It's hard to zoom in in that way.

Maybe someone else here has less problems with that.

[DVV81]

you're asking for help, but keep ignoring suggestions (or fail to report back on those)

As I clearly stated in my pre-last comment with 4 screenshots, the problem has nothing in common with user access rights to specific files (which I surely tested), but seems to relate to file extensions.
But I realize it's a very specific problem that probably is interesting only to me. (Though, in my opinion, Open++ deserves more interest from the public.)

[vsub]

I am on Win10 Home and the program is working fine
The program is not even installed.I just copy the files from the program folder from my Win7 Pro pc(where it also works fine)to my laptop with Win10 Home,run the OpenXX64 and install the shell extension from the Install\Uninstall Tab

I am also running the x64 version of Everything(the portable version)not as admin and the service is installed
PS.I don't know if it is related but UAC is disabled(I hate that thing)even tho,I still don't have full access

[DVV81]

@vsub,
Could you confirm it works for all file types, including .exe, .dll, .cfg, .bin, .manifest and files without extension?

(Let me remind: for me the Open++ menu appears for all file types in any program except Everything.)

[NotNull]

I am on Win10 Home and the program is working fine
PS.I don't know if it is related but UAC is disabled(I hate that thing)even tho,I still don't have full access

That is by design on Win10. If you disable UAC, you can no longer elevate and you run all programs as some sort of Power User. Not as elevated administrator.

[vsub]

I hate UAC but just for a test,I set it to default level,turn off Everything and uninstalled OpenXX64
Then installed OpenXX64 and run Everything...the Open++ is there again on all mentioned file types

I did not run Open++ as admin,the program is located in "C:\Program Files\Tools\Open++"
I did not run Everything as admin nor I enabled the option from the program,I only installed the service(everything is in "C:\Program Files\Tools\Everything" )

[DVV81]

vsub,
thank you for your testing.
In fact, I'm surprised that everything works for you, because I observe the mentioned issue on 2 different PCs with Windows 7 64-bit and 1 notebook with Windows 8.1 64-bit that I use.
Given that you don't have this issue, maybe it is caused by some application (present on all these machines), however even that assumption would not explain why only Everything is affected whereas everywhere else Open++ works as expected...

[DVV81]

Investigating further, I've found there is a text editor with ability to invoke a file context menu that also misses the Open++ item for some file types. Exactly as in Everything - so it's not alone.
In the same time, as I mentioned, the Explorer, Total Commander (portable, non-admin) and FAR Manager (portable, non-admin) always have the Open++ item in their context menu.
So finally it looks like the issue is connected to the way of how the file context menu is invoked.
Luckily, the text editor, where this issue is reproduced, is open-source and, moreover, the developer usually responds quickly. I'll dig into this direction and report the results here, once any.

[froggie]

Also 7-zip (file compression program) and Norton anti-virus are missing in some context menus through Everything (.gz files, for example). Maybe what these programs have in common is that they use dynamic context menus (with a .dll file) instead of fixed entries in the registry.

[DVV81]

The developer of the mentioned text editor got back to me very quickly. It was just me who slowly prepared to write to him and then slowly returned here to write to this forum.
So, in case of the text editor, the problem was caused by COM interfaces not being cleaned up before the further usage.
Looking at the code, a few lines similar to the following were added:

Code: Select all

hMenuStack->pExplorerSubMenu3->lpVtbl->Release(hMenuStack->pExplorerSubMenu3);

I can confirm that the context menu is always shown correctly after this change.
I don't know whether the problem with the context menu in Everything is similar or not, but the problem is definitely somewhere around the code that invokes (creates) the context menu.
Just as a reference, please find the source code of FAR Manager's EMenu plugin - it always shows the context menu correctly for all file types:
https://github.com/FarGroup/FarManager/ ... Plugin.cpp
Please note that this code creates an additional GUI window to show the GUI context menu because FAR Manager itself is a console application. And basically this is all I can tell about this code, because the lines related to COM look so mad that I just can't understand anything there.

[DVV81]

According to my and froggie's investigations (written above), this problem is not unique to Open++. It is rather a general problem of context menu construction/handling in Everything.
In other words, it is a bug.
Is it planned to be fixed?

[NotNull]

In other words, it is a bug.
Is it planned to be fixed?

What exactly is this bug according to you?

On an almost vanilla Windows 10 system:

2018-09-06 10_01_28-Window.png (38.3 KiB) Viewed 16502 times

2018-09-06 10_00_47-Window.png (37.05 KiB) Viewed 16502 times

2018-09-06 09_57_32-Window.png (36.08 KiB) Viewed 16502 times

Windows 10.0.17134.228 (64-bit)
Everything 1.4.1.895 (x86)
Open++ 1.5 (x86)

[void]

Please try Everything 1.4.1.910.

1.4.1.910 fixes an issue with popup context menu items not appearing when under a menu separator.
I had fixed this for Everything 1.5, but forgot to add it to my Everything 1.4 branch...

[DVV81]

void,
Thank you, now the context menu seems to have all its entries for all file types. Tested with 1.4.1.913 x86 under Windows 7 x64 and Windows 8.1 x64.

NotNull,
The problem was in not having some context menu entries for specific file types (such as ".lng", ".hlf", ".lua" and other - the exact file extensions seemed to vary on different systems).

Please compare two screenshots: the first one is with 1.4.1.913, and the second one is with 1.4.1.895, on the very same machine, very same OS.

[a1ph0r]

Please try Everything 1.4.1.910.

1.4.1.910 fixes an issue with popup context menu items not appearing when under a menu separator.
I had fixed this for Everything 1.5, but forgot to add it to my Everything 1.4 branch...

I'd just like to say thanks for this bug fix. I was having to use Autoruns to disable various ContextMenuHandlers to get RapidCRC Unicode to showup in Everything. Keep up the excellent work!

[stax76]

There is a maintained Open++ alternative:

https://github.com/stax76/OpenWithPlusPlus

[NotNull]

There is a maintained Open++ alternative:

https://github.com/stax76/OpenWithPlusPlus

Nice! ( Currently testing ... )

For others interested: the download location is not obvious. Releases can be found here. Just unzip the most recent OpenWithPP-xxxx.7z and run the executable.


EDIT:
@stax76: Consider changing the order of the screen elements so that TAB-ing through the settings of a context menu entry is less "chaotic".