Context Menu Missing Many Items in Recent v6 Releases 🤔

Recent versions of Listary , after v6.0.9.25, are missing many context menu entries (i.e. right-clicking on a search result from the Listary search bar). It previously showed the same menu as you would see in File Explorer, but now the menu is much abbreviated. Menu entries such as Dropbox, security software “Scan with,”, WinRAR, etc. and anything else that contributes to the right-click Explorer context menu via a shell extension, no longer shows up in the Listary menu.

Is this a bug or intended? I am on Windows 10, if that makes any difference. I have reverted back to v6.0.9.25 for now. Hopefully this can be fixed.

Thanks.

For me the full context menu is available if I scroll down over the Listary specific ones…


Windows 11 Home x64 Version 22H2 (OS Build 22621.1778)
Listary Pro 6.2.0.41

Perhaps it’s a Windows 10 issue or something specific to my configuration. Just so that I am clear we are referring to the same thing, can you give me an example of a context menu item that is from a 3rd-party shell extension that you are seeing in the Listary context menu. Then I can check to see if it shows up in mine as well (i’ll install it if I don’t already have it). There are context menu items that are not shell-extension based, and those show up. But those that are registered via dll to the context menu don’t show up for me.

Meanwhile, I will try to test on a Windows 11 machine.

Thanks for your help!

Here you see the beginning of the general context menu entries, many more follow…
You can see for example the WinRAR and Everything context menu entries.
They are the same as in Explorer or my file manager (Total Commander).

The most possible reason is that your Listary is running as 32-bit for some reason. Many software will register 64-bit shell extensions only if they are installed as 64-bit. If Listary is running as 32-bit, then the 64-bit extensions cannot be loaded, and you will only see menu items from 32-bit shell extensions.

You can use the task manager to determine whether Listary is running as 32-bit as in the following pictures.

Or alternatively:

If there is no such a column called “Architecture”, you can right-click the header, choose “Choose Columns…” and select it from the list.

Apologies for my slow response…it’s been a busy week.

First of all, I want to thank Horst for replying and for posting the image… As a result, I decided to do further tests on different machines in order to eliminate my specific Windows configuration is the reason. So I temporarily created a couple virtual machines to test on. I initialized a new/clean installations of both a Windows 10 VM, and a Windows 11 VM. I installed a handful of apps that I usually use, and ones that I know contribute context menu entries (both shell extension entries, and non-shell extension entries).

Specifically, I installed the following programs that use ShellEx (i.e. dll implementation) of context menu entries: Dropbox, WinRAR, LinkShellExtension, and FileMenu Tools.

I also installed Everything Search, and DefenderUI, although these two context menu entries are non-ShellEx based. I.e., they are of the type that can easily be created via editing the registry directly.

Also, with respect to whether Listary running in 32-bit mode was the cause of the issue. I can confirm that this is not the case. As the image below indicates, Listary is running as 64-Bit. Furthermore, the issue for me is not difficult to reproduce. It’s simply a matter of installing v6.0.9.25 and seeing all the context menu entries as expected. Then installing a later version, say v6.2.0.41, and seeing a more condensed Listary menu with missing ShellEx entries. Simply reverting back to v6.0.9.25 resolves the issue. All-the-while Listary is running 64-Bit:

Here are the results of my VM tests:

From my observation, Listary’s menu generally lines up with the File Explorer Shift-Right-Click extended context menu. As such, I have used that File Explorer context menu in my comparison images below. Also, note that images below reflect the context menu generated from clicking on a folder, the same folder, for testing consistency.

Summary Results:

  • Issues remain with missing ShellEx context menu items in Windows 10 when running v6.2.0.41. (Same results as my physical machine.)
  • However, it appears that all is good in Windows 11 (although v6.0.9.25 does have one extra context menu entry than v6.2.0.41, the shell extension entries show up in both and they are generally the same).

So, it looks like it may be an issue specific to Windows 10?

Thanks All!

1 Like