Refresh List Icons Cache???

[jacky]

Ok, I got a problem that I already noticed and is really bugging me.

Luckily it's not just me, so everyone can have fun
- go anywhere you want, and copy there 2 icons (1.ico, 2.ico)
- rename 1.ico to 3.ico
- rename 2.ico to 1.ico
- rename 3.ico to 1.ico

It should looks like it worked then, but poress F5 and you're back with the first icon for 1.ico (even though it's 2.ico now) and same for 2.ico.

The List & statusbar icon (which i think are the same) are now WRONG! You can check this using Preview tab, which will preview that actual icon.

Refresh List Icons Cache : does nothing.
Actually, it does the same as F5. So, when 1.ico shows the icon of 2.ico, rename 1.ico to 1.icoo then back to 1.ico
You now have the right icon shown on List, both F5 or Refresh List Icons Cache will "restore" the wrong one!!

Really, really annoying bug.

FYI I did this with 16x16 8-bit ico file, haven't actually tried any others to see if it was relevant or not.

[admin]

When you close and restart XY it's all okay, right?

[jacky]

When you close and restart XY it's all okay, right?

Yes, that is the only way to get it right again AFAIK. Until the next changes/renames/etc

[admin]

Fixed!

[jacky]

Fixed!

yep, thanks!

[jacky]

Code: Select all

      However, this fix (which was simply NOT to use the cache for these 
      file types) lead to a slight slowdown in listing files. So I 
      hereby make it optional. I recommend to enable this new option -- 
      you won't have any problems until you swap-rename two ICO or EXE 
      files. And even then, menu View|Caches|Refresh List Icons Cache 
      will immediately update any wrongly displayed icons (it won't 
      update the cache, though -- I'm still working on this one...).

Just to say:
- swap renaming isn't the only case. For example, go to a folder with an icon, open it & modify it. If that option is enabled you will still get the old one. For a small tweak it might not be important, but if you copy the "suspend auto-refresh.ico" to "auto-refresh.ico", then recolor it, it would still show up as red, not green! That, might be more confusing.

- Refresh List Icons Cache does work, but only till the next change of location(/tab), or even F5!

Not problems though, just mentionning for the sake of it

[admin]

Code: Select all

      However, this fix (which was simply NOT to use the cache for these 
      file types) lead to a slight slowdown in listing files. So I 
      hereby make it optional. I recommend to enable this new option -- 
      you won't have any problems until you swap-rename two ICO or EXE 
      files. And even then, menu View|Caches|Refresh List Icons Cache 
      will immediately update any wrongly displayed icons (it won't 
      update the cache, though -- I'm still working on this one...).

Just to say:
- swap renaming isn't the only case. For example, go to a folder with an icon, open it & modify it. If that option is enabled you will still get the old one. For a small tweak it might not be important, but if you copy the "suspend auto-refresh.ico" to "auto-refresh.ico", then recolor it, it would still show up as red, not green! That, might be more confusing.

- Refresh List Icons Cache does work, but only till the next change of location(/tab), or even F5!

Not problems though, just mentionning for the sake of it

Okay, thanks for mention[n]ing it.

What I should have mentioned: this is clearly a Windows Shell bug and I did not want to hard-code a Windows bug workaround that's slows down my app, for a bug that surfaces quite rarely, for most people never, and is not critical at all but rather a cosmetic glitch.
Now you have the choice: use the Windows Shell Icon Cache (and live with its tiny bugs) or access your poor old harddisk every time the icon for an ICO or EXE (plus some other types) file has to be retrieved (I'm exaggerating here: of course, the harddisk has it's own read cache, so it's not that bad).

Sure it would be nice if I found a cool way to flush that cache, but up to now I only see some bloody hacks...

[jacky]

What I should have mentioned: this is clearly a Windows Shell bug and I did not want to hard-code a Windows bug workaround that's slows down my app, for a bug that surfaces quite rarely, for most people never, and is not critical at all but rather a cosmetic glitch.
Now you have the choice: use the Windows Shell Icon Cache (and live with its tiny bugs) or access your poor old harddisk every time the icon for an ICO or EXE (plus some other types) file has to be retrieved (I'm exaggerating here: of course, the harddisk has it's own read cache, so it's not that bad).

Yeah well, I do use the Cache option, now that I know whenever I'll need to deal with filename swapping & stuff I can simply disable it

It's a Windows bug alright, yet in Explorer filename swapping or icon being modified doesn't not cause this, Explorer always shows the right icon. Did they know it was bugged and didn't use their own cache system?

[admin]

It's a Windows bug alright, yet in Explorer filename swapping or icon being modified doesn't not cause this, Explorer always shows the right icon. Did they know it was bugged and didn't use their own cache system?

Good question. Looks like the answer is yes.

Another question is: when you quit XY and start again, the "bug" is fixed. Hm. Looks a bit like the cache is cached by XY again. But not as I know of, not in my code. Does VB do some behind the scenes caching? Unlikely, because this is all pure API stuff. Maybe Windows provides an independent system image list per process? Who knows...