SHGFI_ICONLOCATION
Tom Ballard
problem: returns a zero length string for icon location
for any file e.g. "c:\command.com" or "c:\windows\notepad.exe" ... behaves
as expected for
any drive or directory e.g. "c:\" or "c:\windows\"
further: always behaves correctly for SHGFI_ICON --
i.e., always returns a valid hIcon for an arbitrary valid path
tiny console app to demonstrate problem:
http://home.carolina.rr.com/ballard/files/shicon.zip
relevant portions:
<begin code>
// get icon location for drive or dir works
dwRes = ::SHGetFileInfo(szDriveOrDir, 0, &shfi, sizeof(shfi),
SHGFI_ICONLOCATION); // non zero result, dll path in shfi.szDisplayName
// get icon location for file doesn't work *********
dwRes = ::SHGetFileInfo(szFile, 0, &shfi, sizeof(shfi),
SHGFI_ICONLOCATION); // non zero result, zero length string in
szDisplayName
// get icon handle for drive or dir works
dwRes = ::SHGetFileInfo(szDriveOrDir, 0, &shfi, sizeof(shfi),
SHGFI_ICON); // non-zero result, valid icon in shfi.hIcon
// get icon handle for file !!!WORKS!!! ?!?!?
dwRes = ::SHGetFileInfo(szFile, 0, &shfi, sizeof(shfi),
SHGFI_ICON); // non-zero result, valid icon in shfi.hIcon (as expected)
<end code>
really need help with this, i really really need icon location not handle
am going slap nuts -- $$$ riding on this bad boy
replies to group or esp. mot_d...@hotmail.com
James Holderness
<wt...@carolina.rr.com> wrote:
>
> goal: use SHGetFileInfo with SHGFI_ICONLOCATION for an arbitrary path
>
> problem: returns a zero length string for icon location
> for any file e.g. "c:\command.com" or "c:\windows\notepad.exe" ... behaves
> as expected for
> any drive or directory e.g. "c:\" or "c:\windows\"
SHGetFileInfo first calls IShellBrowser::BindToObject to get an IShellFolder for
your folder, and then IShellFolder::GetUIObjectOf to get an IExtractIcon
interface for the item in the folder and finally GetIconLocation to get the
actual icon location. Unfortunately, GetIconLocation won't necessarily return an
icon location (look up GIL_NOTFILENAME in the help), depending on the way the
namespace chooses to implement icons.
In my oppinion, there are number of cases when the shell's GetIconLocation
implementation should be capable of returning an actual icon location, but it
doesn't. As far as I can remember, this was attributable to a bug somewhere in
the shell, but since GetIconLocation isn't strictly required to return a
location, Microsoft claimed that this was by design. Either way, there's nothing
you can do about it other than to try and determine the icon location yourself.
Regards
James Holderness
http://www.geocities.com/SiliconValley/4942/
Tom Ballard
What do you do, just load up 50 different hIcons into your Image List, even
though all are identical? Now suppose these are EXE files, most of which
have per instance icons. It gets wierd. Ergo, the desire for Icon
Location, because you can cache the name & index and only load up new ones
as needed.
I tried using SYSICONINDEX and, caching these, only extracting when needed.
But when I tried to use the normal (read-only) type ImageList_ routines to
get the hIcon this way, I ended up getting GDI errors when I went to a
directory with a largish number of files (such as \WINDOWS).
Thanks for your input, and i'm not suprised. I was prepared to forgo my
ICONLOCATION for unusual shell extensions but I figured it would work for at
least stuff on the local HD.
Any suggestions? BTW -- your undoc win95 headers are life savers
-t-
Raymond Chen
imagelist. If you really want an icon, you can use
ImageList_GetIcon, but you probably don't want to do that because
you (as you noted) don't want to have 50 copies of the same icon
wasting memory.
Use ImageList_Draw to draw the image out of the system imagelist.
--
(My return address is intentionally invalid to foil spammers. Delete the
".---" to get my real address. I do this on my own time with my own money;
my responses are not to be considered official technical support or advice.
Personal requests for assistance will be ignored.)