Windows 11 integration need an option for keeping the old context menu

[JeromeMartinez]

Feedback from a user.
When calling the context menu from Total Commander, there is no more the context menu because the Windows 11 Explorer style is not supported, so we need an option for keeping the old context menu as it is done in other tools.

WinRAR:

TreeSize:

[cjee21]

Unable to reproduce. Windows 11 shell extensions work fine in Total Commander including properly opening the file in MediaInfo and Mp3tag.
The entries for Clipchamp, MediaInfo, Quick Share, Mp3tag and Notepad are all Windows 11 new-type shell extensions.

In my opinion the user should contact developer of Total Commander for any compatibility issues instead of requesting changes from each and every app to be compatible with Total Commander. Most apps that implement the new shell extension no longer have the legacy shell extension.

Unrelated note: Many apps do not even have an option to disable the context menu entry. Mp3tag only has option to disable in Store version while the installer version can only enable/disable the context menu during installation.

[sevastopolcat]

Why is this so? WinRAR, EZCDAC & Mp3tag - from main Win11 menu.

[cjee21]

Are both options enabled in MediaInfo Preferences?

[sevastopolcat]

Yes

[cjee21]

If it works properly in Windows File Explorer but not on Total Commander then I have no idea why. It works when I tested in Total Commander. Only the developer of Total Commander will know.

[sevastopolcat]

In Explorer the same thing.
In main context menu - available on files and folders. Shift+context menu - only on folders.

[JeromeMartinez]

If it works properly in Windows File Explorer but not on Total Commander then I have no idea why.

Windows File explorer uses the new package but Total Commandes uses the old fashion registry, so it makes sense up to...

It works when I tested in Total Commander.

This part is weird, it does not work on 1 machine but works on another machine... If Total Commander does not use the new package, how does it get the context menu on @cjee21 machine?
Maybe something remaining from a dev? Does it disappear if options are unchecked in MediaInfo preferences?

[cjee21]

In Explorer the same thing. In main context menu - available on files and folders. Shift+context menu - only on folders.

MediaInfo only creates one entry. Since it appears in the main context menu means it is working properly. The entry in shift+context menu should contain everything that the main context menu has. If it does not then it may be a Windows bug but I have not seen this happen before.

[cjee21]

Maybe something remaining from a dev? Does it disappear if options are unchecked in MediaInfo preferences?

If this refers to my test, I have done the test on a newly set-up fresh-install Windows 11 VM (official ISO direct from microsoft.com) with nothing else installed other than the test apps because I do not want to install shareware/trialware on my main PC so there is no possibility of anything remaining from development or previous installs etc.

[cjee21]

So I dug abit and found this by author of Total Commander:

Total Commander does not create the context menu by itself. It requests it from Windows via the IContextMenu interface, and then adds its own entries. So when context menu entries are missing, then the program which owns these entries is responsible when they are missing in third party programs. Total Commander cannot control that.

MediaInfo's shell extension does not have any features that prevents it from being used/loaded by third party programs. The fact that it appears when a folder is selected in #994 (comment) is evidence for this.

Piecing this together with #994 (comment):

In Explorer the same thing. In main context menu - available on files and folders. Shift+context menu - only on folders.

It now makes sense. This issue is not about old/legacy vs new/packaged shell extensions. It is also not about shell extension not working in Total Commander or third party apps. It is that MediaInfo's entry is missing from legacy context menu when a file is selected but not when folder is selected.

Since #994 (comment) mentions that it is available for files and folders in the main/new context menu, I have no idea why it does not appear in the other. The fact that it appears on the main context menu means Windows has correctly picked up the registration and successfully loaded the shell extension. It also means MediaInfo's shell extension has correctly read the Preferences and enabled itself. In addition, it works on other Windows 11 systems including in Total Commander for both files and folders. It is looking likely that this is an issue with the particular Windows installation and is not something that MediaInfo can solve.

[cjee21]

Feedback from a user. When calling the context menu from Total Commander, there is no more the context menu because the Windows 11 Explorer style is not supported,

This line in the initial post is now proven to be false by screenshots in #994 (comment) and #994 (comment).

Note: It is actually not 'Windows 11 style' as it is supported since Windows 10 Build 19000 (4 years ago) and is the only method that can be used by Store apps.

[JeromeMartinez]

It now makes sense. This issue is not about old/legacy vs new/packaged shell extensions. It is also not about shell extension not working in Total Commander or third party apps. It is that MediaInfo's entry is missing from legacy context menu when a file is selected but not when folder is selected.

I am completely lost.
Fact is that I receive feedback because something has changed, but the exact issue seems different depending on the machine.

Let's try to summarize, on specific machines:

• Before the switch to packaged, there was a menu in e.g. Total Commander
• After the switch to package, this menu is no more there, regression
  It means that at least one thing was not well "converted" from legacy to packaged, what? I don't know.

Additionally, I just received this email:

since MediaInfo 24.12 the context menue entries from MediaInfo are missing on Windows 11 x64 though the settings are set to enable them. I guess you removed the classic context menue entries and only install the "new" M$-Store-forced context menue... This is a bad solution as I set windows to use classical context menues and do really not want to do 2 more clicks to get my context menue and the M$-entries are almost the least interesting ones for me...

Would you mind reimplementing classical context menue entries or could you @ least provide a regfile to reenable the classical context menu entries..?

It seems that we have an option somewhere for the classic context menu on Win11...
For the moment the easiest solution I see is to keep the legacy menu in addition to the packaged menu, maybe without option so easier, if I understand correctly it would not create duplicate entries because it is not at the same place, so does it hurt? If duplicate entry, we add an option for people having uncommon configs...

is not something that MediaInfo can solve.

Something was working in the past and is not working anymore, so we can solve that at least by reverting to the previous code, but we could also find a way to have everyone happy.
changing something is not easy, different configs, different people, different usages. Now you know why I am reluctant to change something ;-).

[cjee21]

Windows will automatically populate both new and old context menus when a context menu entry that is registered by a package is present.

This means @sevastopolcat that has entries for new menu but not the old one and only for files but not folders is an issue unrelated to MediaInfo but is something going wrong in Windows. In this case it is expected that it does not work in Total Commander too since this app uses Windows API to build the old style menu.

It also means doing "For the moment the easiest solution I see is to keep the legacy menu in addition to the packaged menu" will cause duplicate entries.

For "This is a bad solution as I set windows to use classical context menus", something else is the issue as well. I just tried setting Windows to only use the old menu and MediaInfo is still present there.

So in conclusion, all the issues so far are not directly due to the new shell extension.

In addition, right now, MediaInfo will only remove the old shell extension when the new one is found in the registry.
@JeromeMartinez can try removing this if statement and the old one would not be disabled.

MediaInfo/Source/Common/Preferences.cpp

Line 827 in 886b555

if (ModernReg->OpenKeyReadOnly(__T("PackagedCom\\ClassIndex\\{20669675-B281-4C4F-94FB-CB6FD3995545}"))) {

[cjee21]

If anyone still has the wrong idea about Windows 11 context menus,
This new shell extension method is supported on Windows 10 Build 19000 onwards.
Although this method is required to appear in new Windows 11 context menu, it has nothing to do with Windows 11 or the new context menu.
This new shell extension does not only work on the new context menu but works on existing/legacy context menus since Windows 10 Build 19000.

So it is not about replacing old shell extension with new one equals will not work if new context menu is disabled or third party app does not support new context menu. Replacing old with new should have no difference other than ability to open multiple files in the same MediaInfo instance. If it breaks something, then there is an issue somewhere and putting back the old shell extension would be just a workaround and not a solution to the underlying issue.

[cjee21]

we could also find a way to have everyone happy

My idea (one of the following):

• only implement the package identity stuff on Store version of MediaInfo (guarantees no issues with users of exe installer as it will be exact same as before but without Windows 11 integration)
• add option in installer to opt-out of package identity (users who mess with their Windows such as disabling services that are not meant to be disabled will still encounter issues due to embedded manifest in MediaInfo.exe)

[cjee21]

After some more digging, turns out this issue (entry not appearing in legacy menu on certain PCs and in some cases only affects files and not folders; third party apps also will be missing the entry in this case) has been encountered by other apps before. It appears to be a strange Windows bug that can be mitigated like the following: https://github.com/M2Team/NanaZip/blob/e54855e1cfbc775f586a08a6298248b52559e2f8/NanaZipPackage/Package.appxmanifest#L276-L277

Comparing the IDs of a few apps, I see no pattern in what causes it to not work on certain PCs. It is not known what factors on a PC triggers the issue too.