🚀 go-pugleaf

"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