views:

318

answers:

2

I have an application that gets installed with a Wise installer (EDIT: Wise creates a Setup.exe file, not an MSI). Upon installation, an icon is set for a certain file type:

HKEY_CLASSES_ROOT\.auz\DefaultIcon = C:\Path\To\App\some_icon.ico,0

Right after the installation, however, Explorer chooses to display this icon using the generic "white sheet + application icon" icon, which is different (and not provided by me).

Upon first launch, the application itself registers icons and other file associations, so that the last run version "owns" those documents. At that point, Explorer changes the icon for this file type and displays the correct one, but when I look at the registry, the value for DefaultIcon is exactly the same.

This is what I've tried so far

  • Removing all entries from the registry, and writing them myself.
  • After the installation, "touching" the value of DefaultIcon, and then launching a small little program that only calls SHChangeNotify(SHCNE_ASSOCCHANGED) (my program does this after updating the file associations in the registry).
  • After the installation, killing and restarting Explorer.
  • After the installation, using TweakUI to "repair" the icons on the desktop.

None of these work. The only way to get the correct icon is to let the program itself install it. I can't find any change in the registry. I'm pulling my hair off.

What I would like to avoid

  • Testing with another installer software
  • Changing the installation script too much (I don't have Wise itself, as the installer gets built on another machine on demand).
  • Embed the icons in the executable.

Any suggestions on how to get Explorer to display the correct icon after installation?

A: 

A couple of things come to mind:

  • why do you have the ',0' after the icon in the registry? That would limit the shown icon to one single icon. Better would be to have an icon file which contains several icons (same icon UI but different sizes/color depths) - Explorer has different icon views! Try removing the ',0' if your icon file only has one icon in it.
  • it may be that the registry is written last in the installer, after the explorer got notified of updates?
  • make sure the registry entry is written after the icon file is stored on disk
  • you should use the Wise installers own configuration to register the file type. Not sure, but I think explorer won't take any changes until the whole installation of an msi is finished, so calling SHChangeNotify() manually won't help. The msi has its own table for this, which Wise will add if you use the right configuration.

For Wise, do the following (instead of creating the registry keys on your own):

  1. Under the Feature Details page group, select the File Associations page.
  2. From the Current Feature drop-down list, select Core.
  3. Click Add at the right of the window and select New. The File Association Details dialog appears.
  4. Click the Extension Details tab.
  5. Browse to the QuickFacts directory, select the file QckFacts.exe, and click OK.
  6. In Extension, enter: qft
  7. Leave the defaults for the rest of the fields and click OK. The extension .QFT is added to the installation. When an end user double-clicks a file with this extension on the destination computer, the QuickFacts application launches.
  8. Save the installation

[Edit] You may also missing required registry entries (the icon might not be enough for the shell to show it):

HKEY_CLASSES_ROOT\.auz\(default) = auzfile
HKEY_CLASSES_ROOT\.auz\shell\open\command = C:\Path\To\App.exe
Stefan
Stefan, thanks for the input. The ",0" doesn't seem to be part of my problem, since the software writes that, and it works. Notifying Explorer after installation does not help either, so hypothesis 2 and 3 seem wrong as well. But good points.
Carl Seleborg
A: 

Here's the solution.

Each file type (let's say ".auz" in this case) was registered with:

  • A DefaultIcon key with the path to the icon resource, and
  • A value for the HKEY_CLASSES_ROOT\.auz\(default) value giving a description of the file type, e.g. "Foobar Document".

In addition to this, there was an entry for the "Foobar Document" document type, or more specifically, a key for how to open such documents from the shell:

HKEY_CLASSES_ROOT\Foobar Document\Shell\command\open\(default) = C:\Path\To\App.exe "%1"

Apparently, this key superceeds the value written for the specific file extension. Because the icons are external to the .exe file, Windows Explorer then used the first icon of the application to create an icon for all files of type "Foobar Document" (that "white sheet + application icon" icon I mentioned).

Now, what I had wrong was that the application itself does change the value of

HKEY_CLASSES_ROOT\.auz\(default)

to a slightly different value when starting, say "Foobar 1.2 Document" (the problem with not being DRY). Thus, the link to "Foobar Document" was lost, and the .auz files got their icons after the first launch.

So I fixed this all by simply removing the HKEY_CLASSES_ROOT\Foobar Document key altogether, and voilà!

Carl Seleborg