vanjac
Suggestion on detection of text files
On src/CreateItemWindow.cpp#L45, the detection is done by comparing the preview handler CLSID with the current Windows text preview handler CLSID. This is not robust as the next version of Windows could use a different CLSID for text preview, and other software might override the text preview handler with its own CLSID.
From the business logic, the purpose of detecting this Windows text preview handler is to provide editor functionality for text files. The suggested way to test whether a file is text file is to query its perceived type using AssocGetPerceivedType function and check whether the perceived type is the predefined enumeration value PERCEIVED_TYPE_TEXT.
You're right, that code is very fragile.
I do want to have the option to override the text editor with a different preview handler in some circumstances. For example, if a .md file was perceived as Text, but the user had a Markdown previewer installed, I would want to show the Markdown previewer instead.
The windows TXT previewer is registered as the default handler for all perceived Text files which don't have some other handler installed (under HKCR\SystemFileAssociations\text). It would be nice if I could detect when Windows is falling back to this default option, and only then substitute my own text editor. I'll need to look into this more.
And eventually I'm hoping to add configurable file type associations (#155), since neither preview handler associations nor perceived types are easily user-editable. So once I add that, maybe it will be less of an issue to show the text editor for all Text files.
By the way, thank you for your blog post on hosting preview handlers, it was very helpful for this project as you can see!
To query the Windows text preview handler CLSID robustly, we can do this:
ASSOCIATIONELEMENT perceivedText[1] { { ASSOCCLASS_SYSTEM_STR, nullptr, L"text" } };
IQueryAssociations *pqa;
AssocCreateForClasses(perceivedText, 1, IID_IQueryAssociations, (void **)&pqa);
// Use pqa->GetString to obtain the preview handler CLSID for perceived type "text".
For checking whether Windows is falling back to that handler (the user might have set the handler for a specific type to the Windows text preview handler, even if that type is already perceived as text), I have no good idea. But I think your point applies if the user installs a generic preview handler for perceived type text, not just Markdown --- in that case, using the user's custom preview handler might be the better choice.