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.

[JeromeMartinez]

It appears to be a strange Windows bug that can be mitigated like the following

I am fine with changing that if it is a way to mitigate the issue...

only implement the package identity stuff on Store version of MediaInfo

The feature is good for most users, limiting that to the Store would be sad, it is not because there are a couple of issues that we need to wipe out the feature for most users.

add option in installer to opt-out of package identity

I don't get why we can not just add an option for switching back to the registry and the package just leave like if the option is disabled in that case, no need to remove everything, or do I miss something?

• Menu option unchecked (classic menu option grayed out) = no registry, WindowsShellExtension leaves
• Menu option checked + classic menu option unchecked = no registry, WindowsShellExtension handles it
• Menu option checked + classic menu option checked = registry, WindowsShellExtension leaves

PS: another case at https://sourceforge.net/p/mediainfo/discussion/297610/thread/364aa79842/

[cjee21]

I don't get why we can not just add an option for switching back to the registry and the package just leave like if the option is disabled in that case, no need to remove everything, or do I miss something

After we workaround the Windows bugs, most of the other issues (such as MediaInfo not launching) will likely only be mitigated by complete removal of package identity. Those issues will likely be caused by corrupt Windows or disabling of core Windows services. Even this current bug is caused by packaging and likely before the shell extension is loaded and decides whether to show.

Therefore I do not see much benefit of having an option in Preferences for that. It will add the following:

• More code in MediaInfo GUI
• Another string to translate to so many languages
• Changes to Preferences window which may break things again (like that day) especially if I do it on C++Builder 12 (no idea why only Preferences breaks and not Main)
• Possibility of users asking about what the new option does, what's the difference between the two extensions etc.
• Having to maintain legacy shell extension even after dropping support for Windows 10 < Build 19000 in the far future

[sevastopolcat]

Temporarily (before reinstalling Windows), I bypassed my problem not entirely correct. Installed the installer 24.11.1 and rolled on top of the portable 24.12.
Once the same problem was with Mp3tag. After the next updates of the OS and the program itself, it quietly disappeared.

[cjee21]

Once the same problem was with Mp3tag. After the next updates of the OS and the program itself, it quietly disappeared.

So it can happen to Mp3tag too... Mp3tag Verb Id is Mp3tagShell so starts with M too.

Microsoft Notepad Verb Id is OpenInNotepad and does not seem to have issues? According to NanaZip devs, using OpenTerminalHere1 causes issues too. NanaZipShellExtension also issue but CNanaZipShellExtension or CNanaZip no issues. I see no pattern.

Fun fact: Microsoft registered Notepad shell extension for Directory as well but of course it does not show.

Temporarily (before reinstalling Windows)

@sevastopolcat if you plan to reinstall Windows, you can wait for a new build (#997) with renamed Verb Id first to see if it can bypass the issue.

[sevastopolcat]

...you can wait for a new build...

Of course, I will wait for the new version(s) and inform the results.

[JeromeMartinez]

@cjee21 I received this use case of a user not finding anymore MediaInfo in the context menu:

I use a tool called "Winaero Tweaker" ( https://winaero.com/winaero-tweaker/ )
Luckily this tool explains what it does for (nearly) every tweak it contains and so their explanation for enabling classic context menues is there:
https://winaero.com/how-to-enable-full-context-menus-in-windows-11/

So if we don't go with the idea of an option we may need to check (both in the installer and the GUI?) that HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32 is not set in addition to the test on Windows 11 (I can survive if the user changes his config and is not finding the menu until MediaInfo GUI is launched again)

[cjee21]

@cjee21 I received this use case of a user not finding anymore MediaInfo in the context menu:

I use a tool called "Winaero Tweaker" ( https://winaero.com/winaero-tweaker/ )
Luckily this tool explains what it does for (nearly) every tweak it contains and so their explanation for enabling classic context menues is there:
https://winaero.com/how-to-enable-full-context-menus-in-windows-11/

So if we don't go with the idea of an option we may need to check (both in the installer and the GUI?) that HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32 is not set in addition to the test on Windows 11 (I can survive if the user changes his config and is not finding the menu until MediaInfo GUI is launched again)

I expect this is due to same Windows bug and that it will be working after #997.

When I mentioned

I just tried setting Windows to only use the old menu and MediaInfo is still present there.

in a post above, I am doing it with a similar registry tweak manually. This registry tweak just makes Windows go straight to the classic menu instead of opening the new one, nothing else as far as I know. Same behaviour as holding shift before right click. If it does not appear after this tweak, it will not appear in the classic menu without this tweak either.

As I mentioned earlier, the new shell extension although is needed to appear in the new menu, actually has nothing to do with Windows 11 or the new menu and will still work without the new menu. If it doesn't something is wrong somewhere and reverting to old shell extension will be just a workaround rather than addressing the cause.

The Verb Id Windows bug addressed in #997 actually existed since Windows 10 in 2021. Since Windows 10 only has one type of context menu, it results in totally no entry. NanaZip originally received report of this bug in 2021 and someone only found the workaround in 2022.

[JeromeMartinez]

I expect this is due to same Windows bug and that it will be working after #997.

I asked to test the new build, we'll see.
Note that it seems that it does not resolve the issue for everyone, this person still has the issue with Total Commander.

As I mentioned earlier, the new shell extension although is needed to appear in the new menu, actually has nothing to do with Windows 11 or the new menu and will still work without the new menu. If it doesn't something is wrong somewhere and reverting to old shell extension will be just a workaround rather than addressing the cause.

If we can find the issue for (mostly) everyone, it is fine for me...

NanaZip originally received report of this bug in 2021 and someone only found the workaround in 2022.

And good that you found the thread there!

[cjee21]

Note that it seems that it does not resolve the issue for everyone, this person still has the issue with Total Commander.

If it appears in Windows File Explorer classic menu but not in Total Commander then it is an issue with Total Commander. If it does not appear in Explorer classic menu too then it may be some Windows bug again. In that case reverting to old shell extension is not really a solution as it will then be gone from the new menu.

To better determine causes, think we need info about Total Commander version, is it 64 or 32 bit, how many shell extensions are installed (maybe Windows has a bug that stops parsing verb ids at a certain letter after some limit). I also wonder if Microsoft is aware of the bug since it seems to remain from Windows 10 2021 to Windows 11 2024. If it is really caused by some limits then there may be more issues as more apps installed by a typical user adopt the new shell extension.

[JeromeMartinez]

In that case reverting to old shell extension is not really a solution as it will then be gone from the new menu.

Well, it was working with the old shell extension so it is a solution, but I understand that you want to try to avoid that.

For the moment I wait for feedback from the Winaero user, it the new binary does not work the first thing to implement is to check the indicated registry entry, I think, for checking if this registry entry is a good trigger, I guess. Anyway, let's wait for the feedback.

[cjee21]

We should fix/workaround any bugs with the new shell extension as much as possible first. Else there will be more issue reports from Windows 10 users when shell extension is implemented for the Store version. There will be no old shell extension or new context menu as a workaround in the case of Windows 10 + Store app. It will just be no context menu entry.

Also note that the registry tweak is undocumented and the key may be changed by Microsoft.

[sevastopolcat]

I specifically checked Winaero Tweak Classic Full Context Menu.
With a developer build 24.12.20241216, the menu item is in an Explorer and in Total Commander, on files and folders.

[cjee21]

The ultimate test in a VM...
I have tried installing as many apps with packaged shell extensions that I can think of as well as several third party file managers.
The test files are .mp4 .jpg and a folder.

Conclusion: Everything works fine except two problematic apps.

• Microsoft's VSCode context menu entry does not appear anywhere. No idea why this specific Microsoft app seems to keep having difficulty integrating a shell extension. It is registered correctly and is a 32-bit dll but seems to fail to load the dll with dllhost constantly running.
• Directory Opus only shows entries for folders correctly proving that it does support MediaInfo's shell extension. For files it is missing many entries including Microsoft's pre-installed apps and Mp3tag. It is only showing 5 out of 9 entries for jpg. It appears to not attempt to load the shell extensions that it is not showing at all. It appears those that were loaded are the ones that specify * in their registrations and not file extensions.

So sure, we can add option to keep old shell extension enabled if you want and hope that it will appear (this will cause duplicate entries on all other context menus, including in Directory Opus for folders, as they are all already working correctly). Or alternatively, use * instead of a list of file extensions. The bug is actually in Directory Opus though and they should fix it as other apps are also affected. It is also a paid app so they should provide support.

I am actually using the publicly available MediaInfo 24.12 version for this test so there is no need for our workaround on this Windows installation even with all those other apps installed.

More evidence that Directory Opus supports packaged shell extensions:

Looks like you fixed the integration issues in most machines

Actually from the tests above and many other PCs, there are not any issues in the first place. Just some crazy stuff happening on some PCs for some reason. There is also no fixing done, just a rename of some string 😉

[JeromeMartinez]

The ultimate test in a VM...

Wow, thanks for the tests.

So sure, we can add option to keep old shell extension enabled if you want and hope that it will appear (this will cause duplicate entries on all other context menus, including in Directory Opus for folders, as they are all already working correctly).

It is always the last hope in case the MediaInfo context menu does not show up on some machines, not something I desperately wish :).
but:

Or alternatively, use * instead of a list of file extensions.

This may be the ultimate solution... Could you try method and say if it works with everything?

I am actually using the publicly available MediaInfo 24.12 version for this test so there is no need for our workaround on this Windows installation even with all those other apps installed.

Unfortunately it is not the case everywhere, but I expect that the * solution would be fine with them too so no need of the "aaaa" workaround.

[cjee21]

Or alternatively, use * instead of a list of file extensions.

This may be the ultimate solution... Could you try method and say if it works with everything?

The original design was using * but you didn't want MediaInfo to appear for all files. So if we switch to * but still want an allowlist, need to modify the dll and do the checking there. Can also add shortcut handling while at it if not too difficult.

In this specific Directory Opus case, they seem to be handling shell extensions themeselves rather than using Windows APIs. So it is their developer that has to fix the bug where their expensive paid app is not correctly showing shell extensions that use a list of file extensions. Many shell extensions are affected.

I am actually using the publicly available MediaInfo 24.12 version for this test so there is no need for our workaround on this Windows installation even with all those other apps installed.

Unfortunately it is not the case everywhere, but I expect that the * solution would be fine with them too so no need of the "aaaa" workaround.

* will not solve the previous 'crazy bug' as NanaZip that has been using * all these while is also getting reports of the issue.

[JeromeMartinez]

So if we switch to * but still want an allowlist, need to modify the dll and do the checking there

I would like a allowlist, the same as with the manifest. Something to maintain but if it is the best method for all machines, we do it...

they seem to be handling shell extensions themeselves rather than using Windows APIs.

But the * part would permit to show MediaInfo context menu, right?

* will not solve the previous 'crazy bug' as NanaZip that has been using * all these while is also getting reports of the issue.

The * update would not put a regression there, right?

[cjee21]

But the * part would permit to show MediaInfo context menu, right?

In Directory Opus case, yes. This app is handling shell extensions with * correctly as seen in the 2nd last screenshot. NanaZip, Notepad, Google QuickShare uses *. MediaInfo, Mp3tag, Microsoft Photos, Microsoft Paint uses extensions list in manifest and therefore is not loaded by that app. User should still report the issue to their developer as other shell extensions are missing.

The * update would not put a regression there, right?

Not expecting any regression but I cannot guarantee anything after seeing all these 'crazy bugs' on some systems that are not expected and cannot be reproduced. What I am sure is * works fine in all my previous tests and other apps that use * work fine on all my systems.

[opusman]

Opus developer here. We're happy to take a look at this, but on a quick test using the most recent version (downloaded from here) it seems to work ok for me (when right-clicking a JPG file anyway). Is there anything I need to do to make it stop working?

[cjee21]

Opus developer here. We're happy to take a look at this, but on a quick test using the most recent version (downloaded from here) it seems to work ok for me (when right-clicking a JPG file anyway). Is there anything I need to do to make it stop working?

That's interesting. After getting reports from users that it was not working in Directory Opus, I tested in a Windows 11 24H2 VM and found that only for folders it is showing. For mp4, MediaInfo and Mp3tag were not showing while for jpg, MediaInfo, Clipchamp, Photos and Paint were not showing. Screenshots are in #994 (comment) for folder and jpg. In my tests, the ones that appear happen to be the ones who declare * in their manifests and not ones with file extensions list. Maybe try installing more apps? In my test, the apps installed are in the last screenshot above. I used the publicly released version of each app including MediaInfo which is the same as the one you used.

[niwazukihon]

I did a bunch of tests and found that whether Directory Opus shows MediaInfo in context menu depends on the file type.

Not working: webp, ogg, wav, mp3, webm, wmv, mp4, mov, avi.

Working: ico, tiff, gif, png, jpg.

[rlaphoenix]

I'm on this snapshot and in directory opus it does in fact only show up any UWP stuff on folders, that includes MediaInfo. But not on any files for me.

Can see MediaInfo in Misc -> Shell Extensions settings marked as N/A unloaded along with all other UWP context menu options.

What isn't working:

• Right-click context menu option on ALL files in Directory Opus (unlike @niwazukihon who had it work on some)

What is working:

• Right-click context menu option on files and folders in File Explorer (with both the Windows-11 style menu and the show more option menu)

I've tried:

• MediaInfo 24.12
• MediaInfo 20241229-2 snapshot
• Resetting Directory Opus completely
• Downgrading Directory Opus as far back as 13.8

Only solution for me so far has been to downgrade back to 24.11.1 for now.

Processor	Intel(R) Core(TM) i9-14900K   3.20 GHz
RAM		64.0 GB (63.8 GB usable)
System type	64-bit operating system, x64-based processor
Edition		Windows 11 Pro
Version		23H2
Installed on	‎09/‎05/‎2024
OS build	22631.4602
Experience	Windows Feature Experience Pack 1000.22700.1055.0

[cjee21]

Happy New Year everyone.

I have tried testing this Directory Opus issue again and managed to reproduce it easily in VirtualBox. This issue is confirmed to affect other apps as well and is not something that MediaInfo can fix. It is also not caused by third-party shell extensions as initially suspected as it happens even with just MediaInfo installed or even without MediaInfo installed.

Steps:

1. Install Windows 11 24H2 using official ISO (Win11_24H2_EnglishInternational_x64.iso) from microsoft.com in VirtualBox
2. Install guest additions and restart
3. Install Directory Opus (DOpusInstall-13.12.exe)
4. Install MediaInfo 24.12 publicly released version from mediaarea.net (MediaInfo_GUI_24.12_Windows.exe)
5. Install Mp3tag from Microsoft Store
6. Update Microsoft Photos and Paint from Microsoft Store
7. Check that shell extensions are correctly detected by Directory Opus in its Preferences
   
8. Check that context menus are correctly displayed in Windows File Explorer for Folder, MP4, JPG and BMP.
   MP4:
   
   JPG:
   
9. Test context menu in Directory Opus for Folder, MP4, BMP and JPG
   As can be seen, it only works correctly for folders. For MP4, BMP, JPG and possibly other filetypes, only Notepad appears, MediaInfo, Mp3tag and Microsoft's apps (Clipchamp, Photos, Paint etc.) are not there.
   
   
   
   
10. Monitor shell extension DLL loading with Process explorer
    It is found that in Directory Opus, when right-clicking files, the shell extensions other than Notepad are not loaded at all. When compared to Windows for JPG, only one of 6 (ignore Windows Terminal that is caused by right-clicking on desktop background) extensions that are supposed to be loaded are loaded by Directory Opus.
    Directory Opus folder:
    
    Directory Opus JPG:
    
    Windows File Explorer JPG:
    
11. Uninstalled Clipchamp and Mp3tag but it is still the same. Only Notepad shell extension is working in Directory Opus for files. MediaInfo, Microsoft Photos and Paint are still missing.
12. Uninstall MediaInfo. Microsoft Photos and Paint are still missing.
    Windows File Explorer:
    
    Directory Opus:
    

[JeromeMartinez]

@cjee21 thank you again for all the tests.
wouldn't the * (+ extension filtering inside the shell helper dll) be less problematic?

[cjee21]

wouldn't the * (+ extension filtering inside the shell helper dll) be less problematic?

Only the developer of Directory Opus knows. All the shell extensions work properly in Windows and on other third-party file managers as seen in previous tests so there is actually no issue with not using *. The developer appears to be the only one with all shell extensions working in Directory Opus? This appears to be an issue with Directory Opus and should be fixed there. We cannot expect all apps to use * just for the sake of getting them to work in a single third-party paid file manager.

[JeromeMartinez]

We cannot expect all apps to use * just for the sake of getting them to work in a single third-party paid file manager.

Headache, it seems that Total Commander also has the problem, see https://sourceforge.net/p/mediainfo/discussion/297610/thread/364aa79842/?limit=25#2eb1/3002

If * works, I am interested in it even if it is not pure, else a basic option for using the old behavior may be a good workaround a,d not a big deal (only an option + translation).

I understand that it is not pure but I try to be pragmatic here, my users have an issue and I can mitigate it if I am not the source of the issue.

Currently thinking that the option is the best, at least we permits the old behavior and everyone can have a good thing ("normal" users with the modern style, specific cases have the old style).

[cjee21]

If * works, I am interested in it even if it is not pure, else a basic option for using the old behavior may be a good workaround a,d not a big deal (only an option + translation).

What about you make a test build with a * in manifest (quick easy change) and see if it will work first. If it does then we proceed with the other changes needed like adding extension checking in the dll. If it doesn't, then we only do the * thing when we want to add shortcut handling and we do the option for maintaining legacy shell ext instead.

Total Commander also has the problem

It's working on many systems already so don't know what bug is this. Might be Windows or third party shell extensions as Total Commander is said to use Windows API to construct the context menu.

[JeromeMartinez]

What about you make a test build with a * in manifest (quick easy change) and see if it will work first

Go! :)

[cjee21]

Go! :)

You don't need me for this simple test right?

Anyway here is a patch to make it even easier: patch.patch

[JeromeMartinez]

You don't need me for this simple test right?

I am always afraid of doing something wrong there, it is so uselessly complicated...
snapshot wit *

[JeromeMartinez]

@cjee21 the * thing does not help.

I give up for the workarounds, the only method for making it working again on such machine seems to be the old method, and reason other tools have the option for switching back to the old method, I guess...

[cjee21]

@cjee21 the * thing does not help.

I see a mistake. There should be no dot for the *.

it is so uselessly complicated...

For me, this new method of shell extensions is less complicated compared to the MediaInfo codes dealing with registry entries for the old shell extension

[JeromeMartinez]

I see a mistake. There should be no dot for the *.

Oops.
Your patch was not applying and I did it manually, too quickly...
I do another build.

[cjee21]

Your patch was not applying

I did test git apply the patch on master branch in the root of this repo and it worked

[JeromeMartinez]

New snapshot with *

[JeromeMartinez]

@cjee21 Looks like that * stuff works (source).

[rlaphoenix]

New snapshot with *

That did in fact work for me on Directory Opus, but of course now applies for every single file regardless of type. For me that isnt a huge deal but yeah.

[JeromeMartinez]

but of course now applies for every single file regardless of type.

@rlaphoenix It was for testing that it works before implementing the filter list inside the shell extension DLL (because the list of extensions in the app manifest seems to not work everywhere).

[JeromeMartinez]

@cjee21 but * is not working with Total Commander (source) so still need of the legacy option for it 😭.

[cjee21]

@cjee21 but * is not working with Total Commander (source) so still need of the legacy option for it 😭.

Don't know the cause. The other systems with Total Commander works properly.

So now we proceed with both file extension filtering in dll (and adding shortcut handling if it is not too difficult) as well as option for legacy shell?

---

To @opusman, there is indeed a bug somewhere in Directory Opus that causes UWP shell extensions that has a list of file extensions to not appear in Directory Opus. This affects all shell extensions and not only MediaInfo. Changing AppxManifest of an app to declare * instead of file extensions works around the bug.

[cjee21]

retainlegacyshell.patch

@JeromeMartinez unrelated: I just noticed there are some *.res binary files committed in this repo such as https://github.com/MediaArea/MediaInfo/blob/master/Project/BCB/GUI/MediaInfo_GUI.res. These files are not used during compilation. New *.res files are generated during compilation in the Release folders.