🚀 go-pugleaf

Oops, TListItem parameter is of course not "const", but it doesn't change my
question at all :)

On Thu, 1 May 2003 10:24:39 +0400, "Dmitry Mikhilov" <dm1@fromru.com>
wrote:

>Hello,
>
>I got weird problem when trying to show icons representing file types in an
>"explorer-like" list view (style is vsReport so small images are used, file
>icons are shown as StateImages)....

Your first call (for obtaining the image list handle) should be:

DWORD ImageHandle = SHGetFileInfo("", 0, &info, sizeof(info),
SHGFI_SMALLICON | SHGFI_SYSICONINDEX);

The next call (for obtaining the icon index):

SHGetFileInfo(AFileItem->Name.c_str(), 0, &info, sizeof(info),
SHGFI_SMALLICON | SHGFI_SYSICONINDEX | SHGFI_USEFILEATTRIBUTES);

AListItem->ImageIndex =  IsDir() ? FDirIconIdx : info.iIcon;

You should cache the index for a folder as follows:

 char   Buffer[MAX_PATH];
 ::GetTempPath(MAX_PATH , Buffer);
 SHFILEINFO    info;
 SHGetFileInfo(Buffer, 0, &info, sizeof(info), SHGFI_SMALLICON |
SHGFI_SYSICONINDEX);
 FDirIconIdx = info.iIcon;


-- 

Nick B. Cassos

Thank you, Nick, but nothing has changed after applying your sample.

...I wonder, is it correct that I obtain the handle of the system image list
and assign it to TListView->StateImages->Handle only once at startup of my
application? Can the handle of the system image list  be dynamically changed
by Windows somehow and thus the old handle becomes invalid?

NB. There are only files whose icons I try to show,  so there are no folders
at all.

Dmitry


"Nick B. Cassos" <nbc@no_spam.ath.forthnet.gr> wrote:
news:18t1bv0lpjgqv1tblq09gh7u0j87hjtj2i@4ax.com...
> Your first call (for obtaining the image list handle) should be:
>
> DWORD ImageHandle = SHGetFileInfo("", 0, &info, sizeof(info),
> SHGFI_SMALLICON | SHGFI_SYSICONINDEX);
>
> The next call (for obtaining the icon index):
>
> SHGetFileInfo(AFileItem->Name.c_str(), 0, &info, sizeof(info),
> SHGFI_SMALLICON | SHGFI_SYSICONINDEX | SHGFI_USEFILEATTRIBUTES);
>
> AListItem->ImageIndex =  IsDir() ? FDirIconIdx : info.iIcon;
>
> You should cache the index for a folder as follows:
>
>  char   Buffer[MAX_PATH];
>  ::GetTempPath(MAX_PATH , Buffer);
>  SHFILEINFO    info;
>  SHGetFileInfo(Buffer, 0, &info, sizeof(info), SHGFI_SMALLICON |
> SHGFI_SYSICONINDEX);
>  FDirIconIdx = info.iIcon;
>
>
> -- 
>
> Nick B. Cassos

Sorry for typoo, assigning is to the handle of TImageList->Handle of the
imagelist attached to the StateImages property of TListView, actually:

IconList->Handle =
SHGetFileInfo("",0,&Si,sizeof(Si),SHGFI_SMALLICON|SHGFI_SYSICONINDEX);
MyListView->StateImages = IconList;

"Dmitry Mikhilov" <dm1@fromru.com> wrote:
news:3eb10399@newsgroups.borland.com...
> Thank you, Nick, but nothing has changed after applying your sample.
>
> ...I wonder, is it correct that I obtain the handle of the system image
list
> and assign it to TListView->StateImages->Handle

"Dmitry Mikhilov" <dm1@fromru.com> wrote in message
news:3eb10399@newsgroups.borland.com...

> Can the handle of the system image list  be dynamically
> changed by Windows somehow and thus the old handle
> becomes invalid?

Possibly.  However, if that were to occur, you would be seeing the problem
effect Windows as a whole, not just your particular application only.  In
such cases, the icon cache has probably become corrupted and needs to be
rebuilt.  Either via recovery tools designed for that, or else by simply
rebooting the machine.


Gambit

No, Windows are working as expected. But I noticed strange thing - when I
fill relatively short lists with file icons, everything is OK. But when I
show more than around 30 files (calling SHGetFileInfo in a loop), wrong
icons sudedenly start to appear. Since that, new short lists become more or
less regularly corrupted too - SHGetFileInfo starts to return wrong icon
indexes :(

There is no place in my code to corrupt anything and CodeGuard is silent as
always :). Just adding TListItems and picking StateImage's indexes for
them...

Dmitry

"Remy Lebeau (TeamB)" <gambit47@yahoo.com> wrote:
news:3eb14f98$1@newsgroups.borland.com...
>
> "Dmitry Mikhilov" <dm1@fromru.com> wrote in message
> news:3eb10399@newsgroups.borland.com...
>
> > Can the handle of the system image list  be dynamically
> > changed by Windows somehow and thus the old handle
> > becomes invalid?
>
> Possibly.  However, if that were to occur, you would be seeing the problem
> effect Windows as a whole, not just your particular application only.  In
> such cases, the icon cache has probably become corrupted and needs to be
> rebuilt.  Either via recovery tools designed for that, or else by simply
> rebooting the machine.
>
>
> Gambit
>
>

"Dmitry Mikhilov" <dm1@fromru.com> wrote in message
news:3eb15950@newsgroups.borland.com...

> Just adding TListItems and picking StateImage's
> indexes for them...

Any particular reason why you are using StateImages instead of just Images?
They are separate properties of the TListView.

Also, it is hard to tell from your code, but are you passing a full path to
SHGetFileInfo() when retrieving an index?  I'm guessing that you are only
passing a filename without any path as well.

Also, when calling SHGetFileInfo(), you removed your SFGAO_SHARE flag.  You
should leave that in there:

    FileIcons->Handle = SHGetFileInfo("", SFGAO_SHARE, &Si,
sizeof(SHFILEINFO), SHGFI_SMALLICON | SHGFI_SYSICONINDEX);
    FileIcons->ShareImages = true;

    SHGetFileInfo(FileName.c_str(), SFGAO_SHARE, &Si, sizeof(SHFILEINFO),
SHGFI_ICON | SHGFI_SHELLICONSIZE | SHGFI_SYSICONINDEX | SHGFI_SMALLICON);


Gambit

On Thu, 1 May 2003 15:22:27 +0400, "Dmitry Mikhilov" <dm1@fromru.com>
wrote:

>Thank you, Nick, but nothing has changed after applying your sample.
>

Strange, the snipet i posted is used in a file manager of mine (for
two years), without problems in Win 98/Me/NT4/2K/XP.

The only think I didn't post is the assignments. Sorry, I should
copy/paste a few more lines...

...

FShellIcons->Handle = ImageHandle;
FShellIcons->ShareImages = true;

LargeImages = FShellIcons;
SmallImages = FShellIcons;

...

No need to assign StateImages for simple viewing.

-- 

Nick B. Cassos

"Remy Lebeau (TeamB)" <gambit47@yahoo.com> wrote:
>
> "Dmitry Mikhilov" <dm1@fromru.com> wrote in message
> news:3eb15950@newsgroups.borland.com...
>
> > Just adding TListItems and picking StateImage's
> > indexes for them...
>
> Any particular reason why you are using StateImages instead of just
Images?
> They are separate properties of the TListView.

Yes, I know. But I use SmallImages for representing the status of the files
(i.e. are they locked or not) which are either linked or embedded  to
database whilst StateImages represent their filetypes (checkboxes are not
used, so stateimages are free); ListView is always in report mode. Also
SmallImages are used to show sorting marks on column headers.
I tried to swap image lists for SmallImages and StateImages, but in this
case wrong icons appeared as SmallImages, as you could possibly expect.

> Also, it is hard to tell from your code, but are you passing a full path
to
> SHGetFileInfo() when retrieving an index?  I'm guessing that you are only
> passing a filename without any path as well.

Already tried both approaches before attempting to bother Borland community
:). Tried to point to really existing files giving their fully qualified
path without providing SHGFI_USEFILEATTRIBUTES flag; tried to pass only file
extensions and set SHGFI_USEFILEATTRIBUTES flag. Doesn't make any
difference.
And it happens on every computer where I attempt to launch my application...

> Also, when calling SHGetFileInfo(), you removed your SFGAO_SHARE flag.
You
> should leave that in there:
>
>     FileIcons->Handle = SHGetFileInfo("", SFGAO_SHARE, &Si,
> sizeof(SHFILEINFO), SHGFI_SMALLICON | SHGFI_SYSICONINDEX);
>     FileIcons->ShareImages = true;

Yes, I did it exactly in this way from the very beginning. SFGAO_SHARE was
removed when I tried to use the example provided by Nick Cassos.
Of course, FileIcons->ShareImages is set to true - this list doesn't own
images provided by Windows.

>     SHGetFileInfo(FileName.c_str(), SFGAO_SHARE, &Si, sizeof(SHFILEINFO),
> SHGFI_ICON | SHGFI_SHELLICONSIZE | SHGFI_SYSICONINDEX | SHGFI_SMALLICON);
>

Exactly, but in vain :( I feel that the problem is very simple, but
nevertheless is beyond my comprehension...

Dmitry.

"Nick B. Cassos" <nbc@no_spam.ath.forthnet.gr> wrote:
news:4mo2bv8uvumsmlbe932e84jh8sa459i6di@4ax.com...

> Strange, the snipet i posted is used in a file manager of mine (for
> two years), without problems in Win 98/Me/NT4/2K/XP.

As I mentioned, this code "nearly" works, but sometimes icon indexes are
wrong.

> The only think I didn't post is the assignments. Sorry, I should
> copy/paste a few more lines...

Thank you, but I understood that, these lines are a must anyway :)

>
> FShellIcons->Handle = ImageHandle;
> FShellIcons->ShareImages = true;
>
> LargeImages = FShellIcons;
> SmallImages = FShellIcons;
>
> ...
>
> No need to assign StateImages for simple viewing.

I use both SmallImages and StateImages simultaneously for representing
accordingly file state and file type in report style TListView.

Dmitry

"Dmitry Mikhilov" <dm1@fromru.com> wrote in message
news:3eb18101@newsgroups.borland.com...

> I use SmallImages for representing the status of the files
> (i.e. are they locked or not) which are either linked or
> embedded  to database

That is what StateImages should be used for instead - the "state" of each
item.

> whilst StateImages represent their filetypes

That is what Small/LargeImages should be used for instead - the "icon" of
each item.

> I tried to swap image lists for SmallImages and StateImages,
> but in this case wrong icons appeared as SmallImages, as
> you could possibly expect.

Yes.  But better that SmallImages be messed up then StateImages.  You
wouldn't want an item appearing as locked when it's really not, etc.

> Yes, I did it exactly in this way from the very beginning. SFGAO_SHARE was
> removed when I tried to use the example provided by Nick Cassos.
> Of course, FileIcons->ShareImages is set to true - this list doesn't own
> images provided by Windows.

ShareImages only tells TImageList that the image list is shared.  But
SHGetFileInfo() should also be told as well that the image list is shared,
so it can optimize itself internally as appropriate.

> I feel that the problem is very simple, but nevertheless
> is beyond my comprehension...

Please create and post an actual compilable sample project to the
.attachments group that demonstrates the problem you are seeing.


Gambit

"Remy Lebeau (TeamB)" <gambit47@yahoo.com> wrote:
news:3eb187be$1@newsgroups.borland.com...
>
> "Dmitry Mikhilov" <dm1@fromru.com> wrote in message
> news:3eb18101@newsgroups.borland.com...
>
> > I use SmallImages for representing the status of the files
> > (i.e. are they locked or not) which are either linked or
> > embedded  to database
>
> That is what StateImages should be used for instead - the "state" of each
> item.
>
> > whilst StateImages represent their filetypes
>
> That is what Small/LargeImages should be used for instead - the "icon" of
> each item.
>
> > I tried to swap image lists for SmallImages and StateImages,
> > but in this case wrong icons appeared as SmallImages, as
> > you could possibly expect.
>
> Yes.  But better that SmallImages be messed up then StateImages.  You
> wouldn't want an item appearing as locked when it's really not, etc.

Remy, I understand what you mean, but the problem is that column headers
take their images from SmallImages list, not from the StateImages one. So,
if I shall assign system image list to SmallImages of a listview, then how
can I draw my own images (which are not part of system image list) at
ListColumns?

<skipped>

> Please create and post an actual compilable sample project to the
> .attachments group that demonstrates the problem you are seeing.

I shall try.

Dmitry

"Dmitry Mikhilov" <dm1@fromru.com> wrote in message
news:3eb18d9b@newsgroups.borland.com...

> Remy, I understand what you mean, but the problem
> is that column headers take their images from SmallImages
> list, not from the StateImages one.

Perhaps, but you have to be careful with the StateImages property.  State
images have additional special processing on them, both by the ListView and
the OS in general.  This is because state indexes are not true absolute
indexes in the ImageList.  Firstly, they are 1-based, not 0-based.
Secondly, they are actually masked with other values, and as such they need
to be translated back to indexes when needed.  In fact, now that I think
about it, that's probably why your images are getting messed up
periodically, since you've swapped the ImageLists so the ListView/OS is
probably ending up doing its extra processing on the wrong list.  That would
probably produce the incorrect indexes you are seeing.

> So, if I shall assign system image list to SmallImages
> of a listview, then how can I draw my own images
> (which are not part of system image list) at ListColumns?

Honestly, I don't think you're going to be able to do what you're trying to
do, at least not by using the native behaviors.  ListView controls simply
weren't designed to properly handle everything you're tying to throw at it
at once.  You really should swap your ImageLists, but then you lose your
header images.  Leave the ImageLists as they are so the header images work,
and you mess up your image indexes.  You may have to simply disable the
ListView's native header and use a separate THeaderControl instead.  Then
you can give the THeaderControl its own separate ImageList.  But then you
have the new chore of keeping the two components in sync with each other if
the user resizes columns as such.  Its a win-lose situation anyway you look
at it.


Gambit

Remy, I've checked icon indexes returned by SHGetFileInfo for each
consecutive list item which shows information about particular file. Wrong
icons start to appear when icon indexes for StateImages are greater than 14.
For SmallImages there is no limit and everything is shown correctly.
So, the range which "seems to be" safe for StateImages is only 1-14. Knowing
this limitation, I will reorganize the interface and get rid of the idea to
use StateImages voluntarily.
Drawing something on a column headers isn't really a problem, but first of
all I had to realize that in my case I can't do it "normally" via
SmallImages :)
It's a pity that in the help files for TListView it is only told that
StateImages property "Provides a list of additional icon images to display
next to each item in the list view" without mentioning any restrictions.

Thank you very much for your time and patience.

Dmitry

"Remy Lebeau (TeamB)" <gambit47@yahoo.com> wrote:
news:3eb196e8$1@newsgroups.borland.com...
>
> "Dmitry Mikhilov" <dm1@fromru.com> wrote in message
> news:3eb18d9b@newsgroups.borland.com...
>
> > Remy, I understand what you mean, but the problem
> > is that column headers take their images from SmallImages
> > list, not from the StateImages one.
>
> Perhaps, but you have to be careful with the StateImages property.  State
> images have additional special processing on them, both by the ListView
and
> the OS in general.  This is because state indexes are not true absolute
> indexes in the ImageList.  Firstly, they are 1-based, not 0-based.
> Secondly, they are actually masked with other values, and as such they
need
> to be translated back to indexes when needed.  In fact, now that I think
> about it, that's probably why your images are getting messed up
> periodically, since you've swapped the ImageLists so the ListView/OS is
> probably ending up doing its extra processing on the wrong list.  That
would
> probably produce the incorrect indexes you are seeing.
>
> > So, if I shall assign system image list to SmallImages
> > of a listview, then how can I draw my own images
> > (which are not part of system image list) at ListColumns?
>
> Honestly, I don't think you're going to be able to do what you're trying
to
> do, at least not by using the native behaviors.  ListView controls simply
> weren't designed to properly handle everything you're tying to throw at it
> at once.  You really should swap your ImageLists, but then you lose your
> header images.  Leave the ImageLists as they are so the header images
work,
> and you mess up your image indexes.  You may have to simply disable the
> ListView's native header and use a separate THeaderControl instead.  Then
> you can give the THeaderControl its own separate ImageList.  But then you
> have the new chore of keeping the two components in sync with each other
if
> the user resizes columns as such.  Its a win-lose situation anyway you
look
> at it.
>
>
> Gambit
>
>

"Dmitry Mikhilov" <dm1@fromru.com> wrote in message
news:3eb20988@newsgroups.borland.com...
> Remy, I've checked icon indexes returned by SHGetFileInfo
> for each consecutive list item which shows information about
> particular file. Wrong icons start to appear when icon indexes
> for StateImages are greater than 14. For SmallImages there is
> no limit and everything is shown correctly. So, the range which
> "seems to be" safe for StateImages is only 1-14.

As previously mentioned, state indexes are *not true indexes* you can't use
SHGetFileInfo() to get absolute indexes for state images as-is.  They have
special requirements.  If you understand what the API is actually doing,
you'll understand why it is failing.

Let's take 14 as an example.  State images are 1-based, not 0-based.  So the
index actually becomes 15.  If you look at the binary representation for 15,
it is 00001111.  According to the Win32 API docs, the state index must then
be bit-shifted 12 bits to the left.  That produces a binary value of
1111000000000000 (decimal 61440).  That value must then be masked using the
LVIS_STATEIMAGEMASK mask, which is defined as 0xF000 (binary
1111000000000000, decimal 61440).  So, the final value that is assigned to
the item's state is 1111000000000000.  When the OS reverses that process
when displaying the actual image (masks the value, shift the bits to the
right 12 places, and then subtract 1), it gets back 14, which is the correct
index into the image list.

If you'll notice, LVIS_STATEIMAGEMASK is a mask with only 4 bits enabled.
That means that state indexes cannot be larger than 4 bits.  You can only
fit a maximum of 15 different values with only 4 bits available.

Now, lets see what happens with 15 as an example.  Add 1 to it, producing 16
(binary 00010000).  Now shift the bits 12 places to the left, producing
00000000000000010000000000000000 (65536).  Mask it with LVIS_STATEIMAGEMASK,
producing a final value of 0.  Reverse the process and you ultimately get -1
(or 4,294,967,295 if converted to an unsigned value) as the state index.
Obviously, that is not the same value as the original index of 15.

See the problem now?  As you've figured out, StateImages is limited to a
total of 15 possible states, plus 0 (-1 in the VCL) to disable the state.
Now you see why you have to swap the ImageLists in order to support the
system image list correctly?  The system image list must be used as the
SmallImages only, and your custom icons as the StateImages.  UI
implementations do not have more than 15 different states for a given list
item, but it may have almost infinite icons for the same icon.

> Knowing this limitation, I will reorganize the interface and
> get rid of the idea to use StateImages voluntarily.

There's nothing wrong with usng StateImages - just use the correct ImageList
for it, which you are currently not doing, because of your desire to use
Header icons as well.

> It's a pity that in the help files for TListView it is only
> told that StateImages property "Provides a list of
> additional icon images to display next to each item in
> the list view" without mentioning any restrictions.

You have to read the Win32 API documentation for the underlying List View
control to understand what's really happening.  There is a whole topic on
working with item states.


Gambit

"Remy Lebeau (TeamB)" <gambit47@yahoo.com> wrote in message
news:3eb215a7$1@newsgroups.borland.com...

>You can only fit a maximum of 15 different values with
> only 4 bits available.

Small correction - "You can only fit a maximum of *16* different values with
only 4 bits available."


Gambit

Remy, if you could write your own documentation for BCB I would be the
happiest man in the world, 'cause you would save me eons of time. Thank you
for being a genius (no smiley).

Dmitry

"Remy Lebeau (TeamB)" <gambit47@yahoo.com> wrote:
news:3eb215a7$1@newsgroups.borland.com...
<skipped>

> You have to read the Win32 API documentation for the underlying List View
> control to understand what's really happening.  There is a whole topic on
> working with item states.
>
>
> Gambit
>
>