On a Windows 2000 machine, I have an installer which sets a file association for a "wbd" file. When the installer runs the registry get an HKCR\.wbd key with a sub-key of "xx.yy.zz" which has a sub-key of ShellNew.
The keys all have "(Default)" values, the upper one set to "xx.yy.zz", the others not set.
The installer also creates HKCR\xx.yy.zz\shell\open\command. Under this key are two values: "(Default)" and "command". (Default) has the correct command to start the application.
The "HKCR\xx.yy.zz\shell\open\command\command" value has a unicode string, ending in the arguments which should be supplied to the command (the same arguments are in the (Default) value), but it begins with gibberish which looks something like: "{*8&WwYT5?_ZAw}wW&0*70De4IMjL?@dzgKAe7+*5"
When a .wbd file is double-clicked it elicits the message:
"This file does not have a program associated with it for performing this action. Create an association in the Folder Options control panel."
If the "command" value is deleted, or renamed, and a .wbd file is double-clicked, it launches correctly. (If memory serves me correctly it also did this under the 3.51 installer, which I unfortunately uninstalled and removed the ".msi" file so I cannot reinstall and retest.)
The MSDN information found in:
http://msdn.microsoft.com/library/defau ... eassoc.asp
does not indicate the creation of a "command" value, leaving only the creation of the "(Default)" value, which seems correctly done here. If I edit the command value with regedt32 to put in the correct executable path, it continues to fail. This suggests that the "command" value should not be there.
I cannot find any reference to the 3.51 installer to permit retesting, but I may have to do my own registry work, and not use the file association to get around this problem. If I could get a copy of the older installer I would appreciate that for testing.
Thanks - Tom (tomoke@elluminate.com)
Suggested Articles
Hi,
Unfortunately, we were not able to reproduce this problem (neither on a Windows XP nor on a Windows 2000 OS). Can you reproduce this behaviour on another computer?
The strange looking characters from the "command" registry value data represent a so called "Darwin Descriptor". This registry value is used to install an advertised application through the activation of a file that uses this application as an extension server.
Regards,
Denis
Unfortunately, we were not able to reproduce this problem (neither on a Windows XP nor on a Windows 2000 OS). Can you reproduce this behaviour on another computer?
The strange looking characters from the "command" registry value data represent a so called "Darwin Descriptor". This registry value is used to install an advertised application through the activation of a file that uses this application as an extension server.
Regards,
Denis
Error due to long arg list
In response to your reply I created a dummy application and installer, which just launched on a file association. Worked fine. I took the existing project for the real application and did an association to a dummy file type, with just some default fixed arguments and the "%1" file substitution - also worked.
At this point, starting to feel foolish, I put on the real argument set and retried the application install. Did not work.
I started throwing away static arguments, and when the string reached a certain length, it did work. This suggests an argument length sensitivity.
Using the dummy installer (with a product of: InstallerTest and a Company Name of: TomOke, ProgId of InstallerTest):
If you use the "Arguments" entry of:
"123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1"
(where you use the numeric sequence between the double-quotes) it will launch. If you change the last entry from "1" to "12", it will not launch.
If you then reduce the length of the product name by 1 or more characters, it will launch again. It launched with "C:\Program Files\TomOke\Test\InstallerTest.exe", but did not launch with "C:\Program Files\TomOke\InstallerTest\InstallerTest.exe" when the last group was "12".
This indicates a length sensitivity. When a working command value for the Test product has "Installer" added to it, with regedt32 (to raise the string length) it fails. This would suggest that the problem is not in your code, but instead is in the windows code.
Sorry for the trouble. Now I have to find a way to reduce the argument length.
At this point, starting to feel foolish, I put on the real argument set and retried the application install. Did not work.
I started throwing away static arguments, and when the string reached a certain length, it did work. This suggests an argument length sensitivity.
Using the dummy installer (with a product of: InstallerTest and a Company Name of: TomOke, ProgId of InstallerTest):
If you use the "Arguments" entry of:
"123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1"
(where you use the numeric sequence between the double-quotes) it will launch. If you change the last entry from "1" to "12", it will not launch.
If you then reduce the length of the product name by 1 or more characters, it will launch again. It launched with "C:\Program Files\TomOke\Test\InstallerTest.exe", but did not launch with "C:\Program Files\TomOke\InstallerTest\InstallerTest.exe" when the last group was "12".
This indicates a length sensitivity. When a working command value for the Test product has "Installer" added to it, with regedt32 (to raise the string length) it fails. This would suggest that the problem is not in your code, but instead is in the windows code.
Sorry for the trouble. Now I have to find a way to reduce the argument length.