01-08-2015 02:50 PM
After spending most of the day fighting a problem and thinking it was yet another LabVIEW bug, I finally figured out the real problem, so I thought I'd share.
I typically build LabVIEW applications using the default icons, and one of the last things I'll do is create the custom icons. I was working with 2014 SP1 and I kept having a problem where the desktop icon would not be correct, but the file explorer icon (16x16) would. I kept thinking there was some bug in the icon editor, or some icon was being cached by NI. No matter what I did, I couldn't get the correct icon to display when I would Send to ->Desktop (create shortcut). (Note - this was on a Vista laptop, although there are reported problems with 7 as well).
AI finally got to thinking that maybe Windows did some kind of icon caching. After doing some research, yes, there is a hidden database file with cached icons called IconCache.db. I tried deleting it and rebooting, but that didn't help. I finally found a solution that does work, and best of all does not require a reboot. See below. If this helps just one person keep from shouting expletives at work, it was worth spending the time to post this.
Create the following batch file, call it something like ClrIconCache.bat and keep it handy on your desktop. If you run it, your most recently modified icon will magically appear 🙂
@echo off
taskkill /IM explorer.exe /F
cd /d %userprofile%\AppData\Local
del IconCache.db /a
start explorer.exe
01-08-2015 04:22 PM
Thanks for the info.
I've had corrupted icons before, and it never had to do with LabVIEW or any .exe's I had ever built. Just icons for files on my desktop have an icon that was unrelated to what it always did. Sometimes reboot would help. There was never any rhyme or reason, and googling for answer found hundreds of threads of people talking about it, but very few solutions. One thing I do remember was there was a setting somewhere (registry?) that defines the size of the icon cache. I think making that number larger would help my corrupted icon cache. If the original default was a binary sized number like 1024, then changing it to 2048 or 4096 would be what I'd do.
It seems to me that you shouldn't have to do anything special like you showed to fix the problem, that somehow after enough time, and perhaps after rebooting, Windows should be able to clean up the problem you are having itself.
I just wonder how Microsoft planned for this whole process to actually work. But your information seems like it could help other people who run into a similar problem.
01-09-2015 07:42 AM
This may not be an issue for most people, because it only occurs if you create a shortcut using a certain named file, and then try to change the icon and create the shortcut using the new .exe file. I was really perplexed because I was creating custom icons for two apps that previously used the LabVIEW icon, and one app's icons worked and the other one's didn't. I later realized that I had also change the name of the .exe file in my Build Specification for one app, and that is the app that work because no icon was cached for it. It really is a pain when you're testing out your build spec and you can't see your updated icons on your desktop. And rebooting doesn't help.
Windows does cause a lot of frustrations. I was also working with USB COM Ports yesterday, and dealing with the frustration of having about 10 ports declared as 'in use' by Windows when only one device was connected. This was due to me using different USB devices such as emulators and embedded eval boards over the years, and new COM ports being assigned to each one. I think I had about 7 FTDI COM ports declared as being in use! This too is something that requires you to go deep into the bowels of the registry to clean up, whereas a simple method to remove 'in use' status on disconnected ports could have easily been put into Device Manager. I wanted to assign a descriptive name to some isolated RS-485 ports in my apps (I have two related apps that each use one port of a dual port USB->RS485 converter, and I wanted to make it clear to the user which COM port was for which app), but to do that I needed to know their COM port number. I was concerned that the lower COM ports could suffer from this 'in use' problem, so my solution was to display the generic friendly name by default, but if the user wants to display the descriptive name in the apps they have to go into Device Manager and assign COM ports 20 and 21 to ports 1 and 2 of the device. Not ideal, but should work for most cases.