{"id":91401,"date":"2015-10-09T07:00:00","date_gmt":"2015-10-09T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/20151009-00\/?p=91401\/"},"modified":"2019-03-13T12:20:27","modified_gmt":"2019-03-13T19:20:27","slug":"20151009-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20151009-00\/?p=91401","title":{"rendered":"How does a shell namespace extension provide icons for virtual items that track the standard icons set by the user’s file associations?"},"content":{"rendered":"

A customer asked, “What is the correct way to retrieve the icon associated with a file extension? We are writing a shell namespace extension that holds virtual file content, and we want to show the icon that would have been shown if the file were a physical file on disk rather than a virtual one. We tried using SH­Get­File­Info<\/code>, expecting it to return the icon location and index, but the szDisplay­Name<\/code> comes out as a blank string. (See sample program attached.) What’s the right way to get the location so we can return it in our own Get­UI­Object­Of(IExtract­Icon)<\/code> handler?” <\/p>\n

\n#include <windows.h>\n#include <iostream>\n\nint main()\n{\n SHFILEINFOW info;\n ::CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);\n ::SHGetFileInfoW(L\".txt\", FILE_ATTRIBUTE_NORMAL,\n    &info, sizeof(info),\n    SHGFI_ICONLOCATION | SHGFI_USEFILEATTRIBUTES<\/a>);\n std::wcout << info.szDisplayName << std::endl;\n std::wcout << info.iIcon << std::endl;\n return 0;\n}\n<\/pre>\n
The location is coming out blank because the file location returned is GIL_NOT­FILENAME<\/code> so there is no file name to return. <\/p>\n
But let’s look past the question to the problem. The problem is that you want to implement IShell­Folder::Get­UI­Object­Of(IExtract­Icon)<\/code> for your shell namespace extension. Your plan is to create a custom implementation of IExtract­Icon<\/code> and tell it to report the information you obtained from SH­Get­File­Info<\/code>. The catch is that this information is lossy because IExtract­Icon::Get­Icon­Location<\/code> returns additional information that is not captured by SH­Get­File­Info<\/code>. <\/p>\n
Avoid the loss of fidelity by removing the middle man. Just ask for the standard icon extractor and return that<\/i>. <\/p>\n
We start with a helper function that takes its inspiration from Get­UI­Object­Of­File<\/code><\/a> but applies a little seasoning from Create­Simple­Pidl<\/code><\/a>: <\/p>\n
\nHRESULT GetUIObjectOfVirtualFile(HWND hwnd, LPCWSTR pszPath,\n    REFIID riid, void **ppv)\n{\n  *ppv = nullptr;\n\n  WIN32_FIND_DATAW fd = {};\n  fd.dwFileAttributes = FILE_ATTRIBUTE_NORMAL;\n  CComHeapPtr<ITEMIDLIST_ABSOLUTE> spidlSimple;\n  HRESULT hr = CreateSimplePidl(&fd, pszPath, &spidlSimple);\n  if (FAILED(hr)) return hr;\n\n  CComPtr<IShellFolder> spsf;\n  PCUITEMID_CHILD pidlChild;\n  hr = SHBindToParent(spidlSimple, IID_PPV_ARGS(&spsf), &pidlChild);\n  if (FAILED(hr)) return hr;\n\n  return spsf->GetUIObjectOf(hwnd, 1, &pidlChild, riid, NULL, ppv);\n}\n<\/pre>\n
This helper function is like Get­UI­Object­Of­File<\/code> except that it uses a simple pidl to get the UI object for a file that doesn’t actually exist. <\/p>\n
We can use this function to get the icon extractor for an arbitrary file extension. <\/p>\n
\nHRESULT GetIconExtractorForExtension(\n    HWND hwnd,\n    PCWSTR pszExtension,\n    REFIID riid,\n    void **ppv)\n{\n *ppv = nullptr;\n\n wchar_t szPath[MAX_PATH];\n HRESULT hr = StringCchPrintfW(szPath, ARRAYSIZE(szPath),\n                              L\"C:\\\\a%ls\", pszExtension);\n if (FAILED(hr)) return hr;\n\n return GetUIObjectOfVirtualFile(hwnd, szPath, riid, ppv);\n}\n<\/pre>\n
and then use this function when handling the request for IExtract­Icon<\/code>. <\/p>\n
\nif (interfaceId == IID_IExtractIconW ||\n    interfaceId == IID_IExtractIconA)\n{\n  return GetIconExtractorForExtension(hwnd, L\".txt\", riid, ppv);\n}\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
Forward to the standard implementation.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-91401","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Forward to the standard implementation.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/91401","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=91401"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/91401\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=91401"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=91401"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=91401"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}