![]() 01:42:55 INFO - virtual nsresult LaunchDefaultWithFile(nsIFile* aFile) = 0 01:42:55 INFO - /builds/worker/workspace/build/src/uriloader/exthandler/nsMIMEInfoImpl.h:108:20: note: overridden virtual function is here 01:42:55 INFO - virtual nsresult LaunchDefaultWithFile(nsIFile* aFile) 01:42:55 WARNING - /builds/worker/workspace/build/src/uriloader/exthandler/win/nsMIMEInfoWin.h:36:20: warning: 'LaunchDefaultWithFile' overrides a member function but is not marked 'override' 01:42:55 INFO - In file included from /builds/worker/workspace/build/src/uriloader/exthandler/win/nsOSHelperAppService.cpp:13: Or do we already know that that doesn't work (if so, I missed it in the preceding comments, unfortunately.)īacked out changeset 841580134756 ( bug 1263176) for bustage at nsOSHelperAppService.cpp on a CLOSED TREE. That uses AssocQueryString, which based on should maybe also work here? Haven't had a chance to try it yet, but seems simpler than having to dig through the registry ourselves. So this is interesting, because while I was looking at this, I noticed that we already fixed this for protocol handlers (ie different from file/mime handlers), in bug 1260483. (In reply to Molly Howell (she/her) from comment #8) Hopefully I'll have time soon, or anyone else is obviously welcome to it in the meantime. That pretty much fills in the last piece, but I have a few other things going on right now so I can't work on this immediately. Plus apps that have associations seem to keep their Capabilities keys in there, and those are where you find the specific strings intended for use in file/protocol association UI. This is probably the better place to look. Shell/Open also contains PackageId that can be used as a key into HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\Repository\Packages and each one there has a DisplayName. That does work, thank you! For some reason I was assuming it would only work for Win32 resources (the first two bullet points under Remarks), and I didn't find this when I searched the docs before. I see that sometimes they are just strings sometimes indirect strings. I think you can use to load strings starting with so you should be able to translate ApplicationName and Description. (In reply to Marco Bonardo from comment #7) If anybody has a way to do that, I think that's what's needed to fix this properly. And that's the missing piece I can't find how to resolve and access the contents of an ms-resource: URL from outside of the associated app. So I think a correct solution here would involve resolving that URL and using the description string it points to. The problem is that for most applications, this value contains a URL to a resource in the app package instead of just a string description (presumably this is for localization reasons). There's a key called Application located in the HKCR\$ key for UWP apps, and it contains a promising-sounding value called ApplicationDescription. So we need another path through this function to get the correct description for a UWP app. So that's why we think every UWP app is called TWINUI. Unfortunately, the same DLL is always used to launch all UWP applications, which is twinui.dll. That DLL is then taken by GetDefaultAppInfo to be the correct thing to pull the VersionInfo from. This is a COM thing it contains a CLSID which can then be used to look up the path to a DLL containing an in-process COM server implementation (if that fails we look for an out of process one, but here we don't get that far). For UWP apps, that key won't exist, so we'll fall back to look for a DelegateExecute value. The first way it tries to find the right file is to look in the shell open command line key. On the code path we're interested in here, this function looks up a given ProgID string in HKEY_CLASSES_ROOT (for a UWP app, the ProgID is a string starting with "AppX" and then some random characters) and attempts to resolve it to a human-readable description by finding the file used to launch the associated application and looking up the description from that file's VersionInfo resource. We initially get the string "TWINUI" from the function nsOSHelperAppService::GetDefaultAppInfo. I was inspired to spend a bit of time looking into this, and I don't have a solution, but I know more about what's going on, so I though I'd leave some notes here.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |