Why doesn’t my program get fancy drag/drop effects in high contrast mode with CLSID_DragDropHelper ?
When you use the Drag-Drop Helper Object to get Explorer’s fancy drag/drop effects in your own program, you may find that if the system is in High Contrast mode, then there is no visual feedback.
First of all, good job on testing your program in High Contrast mode.
Up until Windows 7, the Drag-Drop Helper Object does not show fancy drag/drop effects in High Contrast mode because it didn’t render in a High Contrast-y way.
Windows 8 updated the graphics to support High Contrast rendering. But for compatibility reasons, you have to opt in by listing Windows 8 among the supported operating systems in your manifest:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
</application>
</compatibility>
</assembly>
Light
Dark
4 comments
My guess is that CDragDropHelper calls GetVersion and changes its behavior depending on the returned value, and VersionLie kicks in if Windows 8 is not declared in the manifest. But the design choice is questionable — CDragDropHelper, as a system component, already knows it’s running on Windows 8, so why doesn’t it just do the High Contrast dance? Is there field testing that shows the new HC effects used by CDragDropHelper causes a compatibility issue? Is it because the new effect uses an API subject to automatic shims so it won’t work unless the process is in Windows 8 mode?
Perhaps because of the very unlikely possibility that an app designed for win7 knows about this limitation and could implement it’s own workaround, thus “conflicting” with the improved behavior in win8+
Yes, unlikely, but at this point the only killer feature of win11 is all the backwards compatibility. And every time they do change how things work it’s monstrous pain with older apps, such as breaking drag and drop for apps of different security elevation, or the file association system.
It’s not VersionLie. The deal is that Windows 7 disabled themes in high contrast mode, but Windows 8 allows them, presumably because somebody went in and did the work to make the themes look good (or at least not-awful) in high contrast. But doing this created compatibility problems because old Windows 7 apps assumed that themes were disabled in high contrast mode. To get themes in high contrast mode, apps have to say “I’m okay with themes in high contrast mode,” and that’s what the manifest declaration says.
I now get the rationale of this design choice, thanks to alan robinson. In my discussion of VersionLie, I guessed that it was how the behavior variation on Windows 8 (dependent on the process) is technically and naturally achieved, not that VersionLie is a root reason of this variation.