Rename shell extension Verb Id 2

[cjee21]

Workaround Windows issue causing shell extension to not appear in classic context menus on certain systems.

Continuation of #997

[cjee21]

@JeromeMartinez I hope is parses numbers before letters. If this does not work then AAAAMediaInfo 😛

[cjee21]

https://mediaarea.net/download/snapshots/binary/mediainfo-gui/20241218-2/MediaInfo_GUI_24.12.20241218_Windows.exe

Still works fine on my system as expected.

[cjee21]

I just noticed something... When right-click a shortcut to a folder, MediaInfo only appears on the classic menu and not the new main menu.

[JeromeMartinez]

When right-click a shortcut to a folder, MediaInfo only appears on the classic menu and not the new main menu.

And with the previous version "CMediaInfo" it is not the case?
Crazy...

Do you see how you could change that? At least we have a machine with this "issue" now :).

[cjee21]

When right-click a shortcut to a folder, MediaInfo only appears on the classic menu and not the new main menu.

And with the previous version "CMediaInfo" it is not the case? Crazy...

Do you see how you could change that? At least we have a machine with this "issue" now :).

I think it always has been like that but I only noticed it. I am very sure previously it is not shown for shortcuts on the new main menu but did not check the classic one previously. Same with a shortcut to a media file. Looks like Windows has different evaluation logic when determining which entries to show for both types of context menu and they only have shortcut resolving for the classic one.

Using the classic context menu on a shortcut will load the target file in MediaInfo and not the shortcut itself. Selecting a shortcut + an actual file at the same time will open the shortcut target only or the actual file + the shortcut file itself depending on which is right-clicked on.

[JeromeMartinez]

Feedback for the user:

this one works, both, files & folders... I needed to restart the explorer process manually but after that everthing fine...

It is so crazy... But if it the way to go, we do that.

[cjee21]

To be clear, the MediaInfo entry on new menu for shortcuts disappeared when we changed * to the list of file extensions. To me this is not an issue/bug but expected behaviour since we did not list .lnk. However, I just discovered that the classic Windows menu has shortcut resolving feature so the shortcut will be resolved to the target and context menu entry behaves like the actual target is the one right-clicked.

[cjee21]

It is so crazy... But if it the way to go, we do that.

My possible explanation that makes this not so crazy is that Windows has a bug that only parses a limited number of shell extensions from 0 - z for the classic menu. When user has many shell extensions installed, the one starting with later alphabets will be missing. So when NanaZip and MediaInfo didn't use "C", it does not work for several people who likely has many extensions starting before "M". When using "C", both apps work for almost all except a very few who maybe has extensions starting with "B" or 0 - A such as "BandiView" as tested by someone in NanaZip thread (NanaZip with "C" prefix stopped appearing as soon as BandiView installed was claimed). As for why Mp3tag and Windows pre-installed apps still work, maybe apps that were already parsed successfully previously are cached somehow. Anyway, I may be completely wrong because who knows how Windows actually works. 😆

[JeromeMartinez]

I think it always has been like that but I only noticed it.

If no regression, I merge this PR.

Looks like Windows has different evaluation logic when determining which entries to show for both types of context menu and they only have shortcut resolving for the classic one.

Maybe Microsoft wants us to resolve the shortcut and show the MediaInfo menu, doable?

[JeromeMartinez]

I may be completely wrong because who knows how Windows actually works. 😆

For the moment, it works, so we do with that, hoping that Microsoft will fix that at some point, before everyone does "000000000000000000000...." stuff...

[cjee21]

Maybe Microsoft wants us to resolve the shortcut and show the MediaInfo menu, doable?

If you want, we need to do shortcut resolving and extension filtering in the shell extension and just put * in manifest so that our shell extension will be called for everything including shortcuts. This way we can open hyperlinks to web media too!

Seems this is what Notepad and possibly other Microsoft apps shell exts does. The manifest has just * and Directory. Notepad entry does not show for directories but shows for all types of files. For shortcuts, invoking the context menu entry will open the target file in Notepad and not the shortcut file itself. Microsoft's and Google's context menu entries seem to take longer to load/appear compared to MediaInfo and Mp3tag so they are doing something there.

[JeromeMartinez]

The manifest has just * and Directory

I was thinking to only shortcuts so ".url" files, and the shell extension dynamically checks if the target extension is what we want.

This way we can open hyperlinks to web media too!

I am fine with that.

For shortcuts, invoking the context menu entry will open the target file in Notepad and not the shortcut file itself.

It is what I expect. resolving that either in the shell extension or MediaInfo (maybe the later, so drag n drop works? Not currently the case)

[cjee21]

I was thinking to only shortcuts so ".url" files, and the shell extension dynamically checks if the target extension is what we want.

If we check target extension in DLL then DLL needs a list of extensions so there is no need to duplicate that list in manifest is what I think. Just * like Microsoft's apps.

Most shortcuts on Windows are .lnk so I am referring to that mostly though it will be nice to have for .url too. Looks like this lnk file is a binary file and requires using COM APIs to resolve. This kind of shortcut also has feature that can automatically find the correct file even after minor changes to paths and filenames.

[cjee21]

My possible explanation that makes this not so crazy is that Windows has a bug...

Another possible explanation is that another shell extension that Windows loads first is somehow causing Windows to stop loading further extensions. This is because it does not really make sense that Windows has a shell extension limit and if so it is unlikely that there are that many shell extensions with verb starting earlier than "C". It is also in line with how a NanaZip user managed to reproduce the issue on a fresh install ("when I finish installing bandiview and hiding the context menu in the settings, it deletes the context menu of nanazip"). I also looked at previous screenshots and noticed that MediaInfo is now higher in the classic menu after the verb rename. As to why the new main menu is not affected, it is a different ordering there (not sure what affects the order) with MediaInfo already at the top. So it could be bugs in other shell extensions but if true, Windows is also at fault for enabling a shell extension to affect other shell extensions.