[X] What's New page opens in Visual Studio rather than default browser

Whenever I install a new version and launch it for the first time, the What's New page opens up in Visual Studio rather than the browser. Visual Studio is not the default program for HTML on my browser, nor is it associated with the Edit verb for that file type; I'm not really sure why it is picking VS.

Maybe it is the same problem ...


That does appear to be the problem. .htm files were for some reason associated with Visual Studio. However, the help files and what's new page are .html files, not .htm. I suspect there is still a small bug where they are being launched incorrectly as the wrong file type.


The association of a file type with a certain application is typical of an OS and the local adaptions. So if you have associated the htm files with something strange ... you see the strange result. Mp3tag does not redirect the file association.

Well, if you do a ShellExecute(NULL, "open", "file.html", NULL, NULL, SW_SHOWNORMAL), it will open the file for the .html association, not the .htm association. The OS will never, ever confuse the two, even though we as humans know they are the same. I wonder if the files are instead being opened in a different manner that asks the OS to open the file in a way that does not exclusively rely on the extension of the file.

There are some (local) glitches when for some inexplicabable reason, esp. a migrated system "forgets" which files are linked to which application. This could lead to the effect, that html files are opened with editor and so on.
So re-link the htm files and everything is fine.

Maybe ... any other association in the registry is involved ...
.htm, .html, htmlfile, OpenWithList

Maybe ... Mp3tag uses a special "verb", ....
when invoking the help file "start_whatsnew.html",
... which might be not needed?

Maybe this tool can help to get better insights ...


I'm using FindExecutable to retrieve the path to the executable associated with *.html files and ShellExecute for executing this application with the given file path as parameter.

This way, paths to HTML files containing an anchor (e.g., "file:///start_whatsnew.html#v268") also get opened correctly — assuming that file associations are correct in the first place. If no such association exists, the fall-back option is to use ShellExecute on the file without the (possible) anchor.

I'm marking this topic as [X] No Bug. If you think that you've identified an issue, please come back and we'll investigate further.

Kind regards

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.