Disappearing ChunkBrowser icons

This may primarily be of interest to Ian, but I thought that I'd post
here to get any general ideas on what's going on, and to hopefully learn
more about how Icons and the ImageManager are supposed to be used.

I haven't figured out how it happens yet, but I've observed a couple of
time where the ChunkBrowser list icons have disappeared or changed. One
time the icons seemed to have completely disappeared. IIRC I ended up
rebuilding the image to correct it that time.

More recently, in a ChunkBrowser that had been open for some time, I
suddenly noticed that the icons in the list had changed to two little
people, instead of dashes. I investigated and found that the
ChunkBrowserChunk.IconIndices dictionary had 170 for #dash.
Displaying:
     IconImageManager current imageAt: 170
gave:
     Icon fromId: 'SMALLTALKOPTIONSFOLDER.ICO'
which is the icon that I was seeing.

By evaluating the initialization code inside of the ChunkBrowserChunk
class >> iconIndices method, the dictionary that maps symbolic names to
indices created by things like "(Icon fromFile: self iconDashFileName)
imageIndex" got recreated, and the normal icons reappeared in the
ChunkBrowser list.

Since the IconIndices class variable uses lazy initialization and
nothing ever changes it, they'll be set once after the package is loaded
and they're first used, and never again. That implies that the indices
of icons are fixed and never change (even across image saves) once
they've been added to an imageList. Is that a safe assumption in
general? Is there anything in normal operation that would remove, change
or replace icon indices? Any ideas on what's going wrong here?

thanks,
-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

Bill,

> Since the IconIndices class variable uses lazy initialization and
> nothing ever changes it, they'll be set once after the package is loaded
> and they're first used, and never again. That implies that the indices
> of icons are fixed and never change (even across image saves) once
> they've been added to an imageList. Is that a safe assumption in
> general?

It's the one I made. I assumed that once the IconImageManager had allocated
an index than it would not change it, even across image saves. That
assumption may be incorrect, but I can't say I have noticed the problem you
describe.  It's easy enough to prevent the ChunkBrowser retaining the cached
indices across image saves (see below) though so you can try adding that to
see if it helps.  If the IconImageManager can change the indices "on the
fly" though that would be a slightly different matter?

The list icons are new for the latest CB version, I previously used existing
icons in the image, so it is quite possible that I need to be a bit more
defensive in this area.

Regards
    Ian

Modify ChunkBrowserChunk class>>iconIndices by adding the following inside
the initialisation block

SessionManager current
    when: #imageSaveStarting
    send: #onImageSaveStarting
    to: self

and then adding

ChunkBrowserChunk class>>onImageSaveStarting
    IconIndices := nil

Ian Bartholomew wrote:

> I assumed that once the IconImageManager had allocated
> an index than it would not change it, even across image saves. That
> assumption may be incorrect, but I can't say I have noticed the problem you
> describe.  It's easy enough to prevent the ChunkBrowser retaining the cached
> indices across image saves (see below) though so you can try adding that to
> see if it helps.

I believe that the assumption you made turns out to be wrong, and that the fix
you proposed is just what's needed.

Starting the image this morning and inspecting, I found that the
ChunkBrowserChunk.IconIndices dictionary had 174 for #dash.
Displaying:
    IconImageManager current imageAt: 174
gives: "value not found: 174"

Did some investigating and found after starting the image, displaying:
    (IconImageManager current imageListWithExtent: 16 @ 16) getImageCount
starts off small. Around 17 when I first displayed it after restarting the
image. Grew slowly as I noodled around. Jumped to 166 after opening a
ClassBrowser. This also seems to be exactly the same as:
    (IconImageManager current instVarNamed: 'images') size

This appears to be the key. An Icon gets it's imageIndex from the
IconImageManager by looking it up in its table of known images. If it's not
there, the call works its way down to WinImageList>>addIcon: which uses
CommCtrlLibrary to add it and get the (seemingly next sequential) index. This is
saved by the ImageManager for subsequent use.

But the evidence above suggests that the IconImageManager is reset somehow when
the image starts. I haven't figured out where that's happening, but it seems
that it must be.

Given all of this, it looks like imageIndices *cannot* be counted on across
image saves. And so your proposed change to ChunkBrowserChunk should take care
of things quite nicely.

regards,
-Bill

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

Bill,

> But the evidence above suggests that the IconImageManager is reset somehow
> when the image starts. I haven't figured out where that's happening, but
> it seems that it must be.

Looks like you are right. GraphicsTool class>>onStartup2, called from
#onStartup, starts off a sequence that clears the IconImageManager lists.
The list will be rebuilt with new indices and pfftt goes my cached values.

> Given all of this, it looks like imageIndices *cannot* be counted on
> across image saves. And so your proposed change to
> ChunkBrowserChunk should take care of things quite nicely.

I'll make it a permanent change.  Thanks for pointing the problem out (I
seem to keep saying that to you lately :-) )

 I also realised why I was not seeing the problem. Although I always load
the ChunkBrowser as part of my image setup I don't actually run it before
saving my working image. The cache is therefore nil every time I start up
the image and, as I very rarely save the image again, never gets saved in a
state where the values are initialised.

Regards
    Ian