Home > Software engineering >  How to get the icon path and index associated with a file type (again, with clarity)?
How to get the icon path and index associated with a file type (again, with clarity)?

Time:01-18

It's a long shot, but does anyone know of a working method to get the associated icon location (= path to an exe/dll/ico file) and ID for a given filename with WinAPI. The point is to create a shortcut to another file (which may or may not be of the same file type) and set THIS exact icon, overriding its default one, presumably with IShellLink::SetIconLocation.

Things that don't work: -ExtractAssociatedIcon -SHGetFileInfo -IExtractIcon

Return random crap with GIL_NOTFILENAME flag set for any of the default file types I've tried (like txt).

There seem to be several topics on SO about this sorta thing, with answers/non-answers suggesting one of the above. This one [1] appears most close to being informative. Their preferred method doesn't work either, but their other notes gave me the hint to try using the registry.

So for the time being, I wrote my own function that uses the registry [2], but it's also not perfect: in some cases, the registry stores 'positive icon IDs' that cannot, it seems, be used with SetIconLocation.

Honestly didn't expect this to be such a year 2023 problem

CodePudding user response:

You don't need to call IShellLink::SetIconLocation if you don't want to override the targets default icon. Just point the shortcut to a .txt file and the shortcut automatically gets the correct icon.

Positive icon IDs most certainly can be used with SetIconLocation, that is the common case. Are you calling PathParseIconLocation?

GIL_NOTFILENAME is just something you have to accept, it usually means the icon comes from the system image list. The shell is mainly interested in going from a file/type to a HICON, not the other way around. The icon for a file may even be dynamic if it is implemented by a shell extension.

You can add AssocQueryString to the list of functions to try that will never work 100% of the time...

  • Related