I have been trying to add context based right click in windows explorer for a file of extension L5X. I have tried HKEY_CLASSES_ROOT\l5xfile\Shell\convert\command and set the (Default) key value to the program I want to have open the file. (I want it to say "Convert" on the context menu) My first issue seems to be that in .NET (even when running elevated) I cannot change the Default key's value. My other issue is changing that Default key value doesn't do anything to the context menu. I would really prefer a no reboot required solution.
Also, I really need this to work on WinXP all the way up to Win7 (including Server 2003, 2008 and 2008R2). If I need to detect OS and do things differently for different OSes, I will but I'm really stuck here.
PS, I tried the solution found here with no luck.
You need administrator rights to write to HKEY_CLASSES_ROOT, HKEY_CLASSES_ROOT is a merged view of HKEY_LOCAL_MACHINE\SOFTWARE\Classes and HKEY_CURRENT_USER\Software\Classes. If you want to install it for just the current user, write to HKEY_CURRENT_USER\Software\Classes
\l5xfile\Shell\convert\command might not be the correct path, when windows looks for context menu entries for a filetype, it first looks in HKEY_CLASSES_ROOT\.EXT, then uses the default value it finds there: HKEY_CLASSES_ROOT\%defaultvaluefrom.EXT%\Shell\*
XP added a new key HKEY_CLASSES_ROOT\SystemFileAssociations designed for non-primary actions where you don't care about the ProgId/Class (The l5xfile part)
MSDN documents all these registry paths and settings, see: File Types and Verbs and File Associations
Related
I'm trying to run a ClickOnce installer and I get this useless error message from Windows 7: "Windows can't open this file".
The file extension is .appref-ms
Has anyone seen this or have any advice?
I had this issue on a client's machine. It appears that the operating system does not know the correct association for the file extension, but in reality .appref-ms is not a normal extension and is not directly associated with any program.
I found the following page eventually:
https://social.msdn.microsoft.com/forums/windows/en-us/9ff7867c-7e57-468c-a632-762a76f66f6d/windows-7-64-bit-unable-to-open-apprefms
This contains some information on restoring potentially damaged registry keys, which can cause this issue. However, in my opinion it gives the wrong advice to associate dfshim.dll with .appref-ms. When I did this, it created an association to that dll in the registry, but upon checking the registry of a working machine, no such association exists. This association also causes .appref-ms files to lose their application specific icons, and display instead this icon:
In addition, this association did not actually launch my application successfully, but for some others it may actually work (I don't know).
The correct solution is to restore even more registry keys, which cascade to allow windows to treat .appref-ms files more like applications than files to be opened with programs. The necessary keys are below (I may have overzealously included a couple that are not strictly necessary, but at least some of them are):
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.appref-ms]
#="Application.Reference"
[HKEY_CLASSES_ROOT\.application]
"Content Type"="application/x-ms-application"
#="Application.Manifest"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Reference\shell]
#="open"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Reference\shell\open]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Reference\shell\open\command]
#="\"C:\\Windows\\System32\\rundll32.exe\" \"C:\\Windows\\System32\\dfshim.dll\",ShOpenVerbShortcut %1|%2"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Manifest\shell]
#="open"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Manifest\shell\open]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Application.Manifest\shell\open\command]
#="\"C:\\Windows\\System32\\rundll32.exe\" \"C:\\Windows\\System32\\dfshim.dll\",ShOpenVerbApplication %1"
This appears to apply to both .application and .appref-ms type files. The first key identifies .appref-ms as class "Application.Reference". The later key under "Classes\Application.Reference" defines how these types are launched. These are not simple "open with" associations that Windows is trying to help you create (and which will be created under HKCU instead of HKLM).
I have my application written in Delphi XE that works with PDF files. Applicaiton is Win32. On start I would like to ensure that there is my item in explorer context menu for PDF files. I would like to be able to specify whether it should be added for active user only or for all users (with UAC I will need to restart with Admin privileges but thats ok).
I started with How to associate a Delphi program with a file type, but only for the current user? and How to add item to windows explorer content menu in delphi? . I tested it with manual registry editing via regedit and it worked fine for "new" extensions. But for .pdf it is more complicated as it will be most probably already present in the registry.
On my PC the .pdf key is referencing AcroExch.Document . But adding shell/something subkey to the AcroExch.Document key is not working because it has CurVer subkey referencing to AcroExch.Document.7. However another PC with another verison of Acrobat had this names a little different. It is no problem for me to follow the CurVer reference but is that a correct approach? And what about situation where no PDF reader is installed, how should I name my keys so Acrobat won't overwrite them when installed?
But more pressing matter is in which root should I put my keys? How to associate a Delphi program with a file type, but only for the current user? is mentioning HKLM (Local Machine) and HKCU (Current user). Its seems rather straightforward but I am unable to set values in HKLM from Delphi. Strangely I can create keys:
var reg:TRegistry;
key := '\Software\Classes\'+keyname+'\shell\'+name+'\command';
reg.CreateKey(key);
but I am getting Access Denied when trying to write the actual value:
reg.OpenKey(key,false);
reg.WriteString('',command);
I am getting the same Access Denied exception even on WinXP, no matter if the applicaiton is running as Admin (Win7), I even tried to set permissions (Everyone full control) for the key via regedit (I can edit the value via regedit without problems). I tried creating the registry with different access modes, all with no luck:
reg := TRegistry.Create(KEY_WRITE or KEY_WOW64_64KEY);
reg := TRegistry.Create(KEY_ALL_ACCESS or KEY_WOW64_64KEY);
reg.Access := KEY_ALL_ACCESS;
reg.Access := KEY_WRITE or KEY_WOW64_64KEY;
reg.Access := KEY_ALL_ACCESS or KEY_WOW64_64KEY;
With HKCU everything works fine.
So I tried writing into HKEY_CLASSES_ROOT and it works and actually puts the keys exactly where I want (into HKLM) if running as Admin. But according to http://msdn.microsoft.com/en-us/library/windows/desktop/ms724475.aspx
The HKEY_CLASSES_ROOT (HKCR) key contains file name extension associations and COM class registration information such as ProgIDs, CLSIDs, and IIDs. It is primarily intended for compatibility with the registry in 16-bit Windows.
I do not like the note about the primary purpose being compatibile with 16-bit Windows. And the actual conditions where the changes will be written is more complicated than I would like.
So basically I have these questions:
What is the advantage of using AcroExch.Document and CurVer instead of pointing directly to AcroExch.Document.7? And what are the "best manners" when adding my keys into this structure? What about the case when the .pdf is not yet associated with anything?
Where should I put my keys and why I am not able to write into HKLM?
Edit:
The problem with Access Denied when writing to HKLM was caused by my error. I did use in previous code openKeyReadOnly and I did not notice that it will swtich the Access property to readonly for all subsequent calls.
To answer your other question, if Adobe is not installed yet then obviously the PDF keys will likely not exist in the Registry yet so you would have to create your own .pdf and ProgID keys so that you can attach your Shell command on it. If Adobe is installed afterwards, it is likely going to wipe out your keys and replace them with its own, so you would have to recreate your Shell command within Adobe's key structure. Your app can query the Registry to check for that condition periodically, such as at startup.
You have asked two separate questions. Since I know the answer to one and not the other, I'm going to answer just one. For future reference, I do recommend that you ask a single question at a time.
Where should I put my keys?
You are correct in discerning that you should not use HKCR. The documentation for HKCR says:
Class registration and file name extension information is stored under
both the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER keys. The
HKEY_LOCAL_MACHINE\Software\Classes key contains default settings that
can apply to all users on the local computer. The
HKEY_CURRENT_USER\Software\Classes key contains settings that apply
only to the interactive user. The HKEY_CLASSES_ROOT key provides a
view of the registry that merges the information from these two
sources. HKEY_CLASSES_ROOT also provides this merged view for
applications designed for previous versions of Windows.
....
If you write keys to a key under HKEY_CLASSES_ROOT, the system stores
the information under HKEY_LOCAL_MACHINE\Software\Classes. If you
write values to a key under HKEY_CLASSES_ROOT, and the key already
exists under HKEY_CURRENT_USER\Software\Classes, the system will store
the information there instead of under
HKEY_LOCAL_MACHINE\Software\Classes.
So, it is reasonable to use HKCR for reading, but for writing you typically need to exert control over whether to write to HKLM or HKCU. And that means that you cannot write to HKCR.
So, write to HKLM\Software\Classes for machine-wide settings, and HKCU\Software\Classes for user-specific settings.
Note that in Windows 7 and later neither of these keys is redirected and so you do not need to worry about using KEY_WOW64_64KEY. However, in Vista and XP64, and the equivalent server editions, these keys are redirected and reflected. Which means that it might be prudent to use KEY_WOW64_64KEY.
Where is in the registry the path executed when I run the "notepad" command in windows "Start->run command" interface? I want to change it for notepad++ (it is required so, although could look not really good)
If you are like me you use windows run command all the time. I hate using the mouse to point and click a shortcut on the start menu. WIN-R are probably the two most over used keys on my keyboard. After thinking about if awhile I hunted down how the run command works. It turns out that it makes a call to ShellExecute, which I guess is not too surprising. The next thing I wanted to find out was exactly how the commands are resolved. The following is an ordered list of how they are resolved ([1]):
The current working directory
The Windows directory (no subdirectories are searched)
The Windows\System32 directory
Directories listed in the PATH environment variable
The App Paths registry key
Naturally the next thing I wanted to do was customize existing commands or add new commands so I do not have to type as much (standard lazy approach). After examining my options which were to put the executable in one of those paths (since it only locates executables and not shortcuts), modify the path environment variable or add a key to App Paths. The App Paths option seems to be the easiest and most flexible to me. Here is a layout of what you need to do to add an App Paths entry ([1]):
HKEY_LOCAL_MACHINE-->
SOFTWARE-->
Microsoft-->
Windows-->
CurrentVersion==>
App Paths-->
file.exe-->
(Default) = The fully-qualified path and file name
Path = A semicolon-separated list of directories
DropTarget = {CLSID}
Disclaimer: Modifying the registry can cause serious problems that may require you to reinstall your operating system. I cannot guarantee that problems resulting from modifications to the registry can be solved. Use the information provided at your own risk.
The minimum needed to add a new entry is to add the key file.exe where file is the string you want to type into the run command and to add the Default entry which is the fully-qualified path to the file you want to execute. Note that even it the file you are going to reference isn't an exe file you still need to put the .exe on the key. Here is a sample registry file that I created to add a shorter keyword for Internet Explorer:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths\ie.exe] #="C:\Program Files\Internet Explorer\iexplore.exe"
After entering that entry into the registry I can simply type “ie” at
the run command to open internet explorer.
Here is a list of some common commands I use at the run command:
cmd – Command prompt winword – Microsoft Word excel – Microsoft Excel
outlook – Microsoft Outlook iexplore – Internet Explorer firefox –
Mozilla Firefox notepad – Notepad compmgmt.msc – Computer Management
Console control appwiz.cpl – Add/Remove programs dialog mstsc –
Microsoft Terminal Service Client regedit – Registry Editor
…
If there is some program that I find myself using all the time I figure out what the run command is for it and if there is not a short easy one I add one to my App Paths as described above. Does anyone else have some other common run commands they use?
I'm trying to programmatically check file associations by the file extension (for example .jnlp files). I keep reading that
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\JNLPFile\Shell\Open\Command
is the Registry key to check. However, if you change the association through Windows Explorer:
Open With > Choose Program > (Always use the selected program)
the change isn't at all reflected in this Registry key. Where else is this information stored?
Take a look in:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\
and the sub-key of that is the extension you reassigned. Under that there will be the UserChoice and OpenWithList sub-keys which will contain your redefinition.
You may also want to read http://support.microsoft.com/kb/950505 which talks about your issue.
Update
As of Windows 8, life has gotten far more complicated. To create an extension association a custom hash needs to get calculated.
Fortunately, someone has reverse engineered the process and created a PowerShell script to do this without having to go through any GUI.
You can find it at the following GitHub link:
https://github.com/DanysysTeam/PS-SFTA
This is a two-part look-up.
First, you look up the default value of HKEY_CLASSES_ROOT\[file_extension]. For your extensions, .jnlp, the value is "JNLPFile". Let's call this the [file_descriptor].
Now you can look up the default value of HKEY_CLASSES_ROOT\[file_descriptor]\Shell\[action]\command (where [action] is the shell action you are interested in, e.g.: Open, Print, Edit, etc.).
On:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.jnlp\OpenWithList
Tip: Edit>Find is pretty handy at these situations. :)
Explanation:
I don't remember about Linux and I don't know about OS X, but in Windows you can right-click a file and select a program to open it. But how does the OS know exactly how to make the program open it? Does it keep track of the "Open file" dialogs the program has? Does the developer have to specify a special event handler or something for these cases?
For Windows, the answer is in the registry. If you're comfortable reading the registry, run regedit.exe on your Windows machine.
Under HKEY_CLASSES_ROOT, you will see a key list of all file types, .doc, .txt, etc. Each of these keys contains a key called "OpenWithList" or "OpenWithProgIds". An application may have a registered "ProgId", also found under HKEY_CLASSES_ROOT, and it can register it's ProgId to the file types it wants to handle in OpenWithProgIds. Otherwise it registers itself in OpenWithList.
In response to the comment to the first answer (cos I don't have enough rep to comment):
You're thinking of DDE, which is a near-enough deprecated technology. The Windows shell executes the application with the selected file as the first parameter.
The Windows Explorer remembers your previous "Open With..." choices based on file extension in the following key:
HKCR\.ext\OpenWithList
Next time you right-click the file, it looks there and build a list of programs you have previously used to open a particular file type.
Say it finds a key named "myapp.exe". It then looks up the application here:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\myapp.exe
fetches the info where the application is installed. And it goes here:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\myapp.exe
follows the GUID stored there to find out the display name of the application.
To add to the fun, the primary associated application is in the list as well, also everything in the OpenWithProgIds key and everything in:
HKEY_CLASSES_ROOT\*\OpenWithList
as well as their respective HKEY_CURRENT_USER counterparts.
The resulting list of applications is then made unique, sorted and displayed. On selection the file is started like any other file you click on - i.e.:
C:\path\to\myapp.exe "C:\path\to\the\file.ext"
http://windowsxp.mvps.org/OpenWith.htm
File associations are stored in the Registry in: HKEY_CLASSES_ROOT.
You can manage them graphically by using Windows Explorer: (WinXP)
Click Tools/Options/File Types
Or with the "Default Programs" applet in Control Panel. (Vista)
Just for some nostalgia the rather brilliant Acorn archimedes had a much better system with each file type having a unique type number, with a manufacturer and application code (rather like a MAC address) which was written with the file.
This means you can have different files all called .bak opened by the correct application - unlike the windows case where a new installed app steals the ownership of every exiting file of that type. Autocad is especialy bad for this, registering about 20 file types.
The operating system runs the specified program sending as parameter the path of the file to open.
For example, in C#, if you want to know which file the operating system wants you to open you'll need to do:
class Program
{
static void Main(string[] args)
{
if (args.Length == 1) //The OS wants me to open a file
openSomeFileJustBecauseTheOSWantsIt(args[0]);
}
}