General discussion

Locked

Using "Open With" does not work

By Gerry A ·
Hello. I have XP machines with roaming profiles on a domain. Due to a PDC SID problem, I had to reinstall the server OS, backup the user's profile located on the workstations at c:\Application Data, remove the original profile, log the user on then off again, then restore the profile from the backup to the new local profile folder that was created. All is well, except the user is unable to add programs to the "open with" box when using the browse button. They will click Browse then choose a program, but the program they just chose will not on the list of available programs. I thought it would be a permissions problem, but it happens even if the user is added as a member of administrators. It also happens if I set the GPO for the user with default settings (all rules are set at "not configured"). This also happens when a new program is installed? even if the program was installed as the user. If I log onto the workstation as administrator it works fine. Any help appreciated. Thank you.

This conversation is currently closed to new comments.

6 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Comments

Collapse -

by Gerry A In reply to Using "Open With" does no ...

Correction to above. "backup the user's profile located on the workstations at c:\Application Data" is not correct. I backed up the user's profile located on the workstations at c:\Documents and Settings.

Thanks.

Collapse -

by Gerry A In reply to Using "Open With" does no ...

Point value changed by question poster.

Collapse -

by SixFourtyKilo In reply to Using "Open With" does no ...

I did a quick search in the registry and came up with these two keys found in both HKEY_CLASSES_ROOT and HKEY_LOCAL_MACHINE:

HKEY_CLASSES_ROOT/*/shellex/contextmenuhandlers/openwithlist

HKEY_LOCAL_MACHINE/software/classes/*/shellex/contextmenuhandlers/openwithlist

The "Open With" key contains a CLSID which can be found by searching. Under this CLSID, you'll find a key labeled "MayChangeDefaultMenu". This may or may not be the culprit. If it DOESN'T exist, I'd assume that you'd need to add it.

You should see the CLSID. Under it you should have InProcServer32 and shellex. Under shellex you should find MayChangeDefaultMenu. MayChangeDefaultMenu should have a String labeled (Default) with no value. These can be found in both CLASSES_ROOT and LOCAL_MACHINE.

Worse comes to worse, you could always add the program to the default list in either HKEY_CLASSES_ROOT/shellex/contextmenuhandlers/openwithlist and/or HKEY_LOCAL_MACHINE/software/classes/*/openwithlist

Other than that, make sure that nothing is preventing the user from saving changes in gpedit.

Collapse -

by Gerry A In reply to

Thank you for your help, but that was not it. Another OS reinstall was a solution.

Collapse -

by Gerry A In reply to Using "Open With" does no ...

This question was closed by the author

Collapse -

Another possible cause/solution

by teleping In reply to Using "Open With" does no ...

Hey!

Although this thread is old, after having the same problem and not finding a sensible/"more explanatory" solution, I thought adding my case might help somebody else having this (and not wanting to reinstall OS just because of this).

By the way, I have Windows 7 Ultimate x64, so the registry location might be different (can't check on XP at the moment).

-- WARNING -- : involves possible manual registry editing, at least viewing, which might make your computer totally unstable/non-functional!!
-- Always make a backup of your registry before editing it!! --

So, I had the same problem: I wanted to open a file with a particular program and have the option visible in the Open With submenu. After using "Browse..." to select it, the program still doesn't appear on the "Open With" list.

My problem was that in the registry key
HKEY_CLASSES_ROOT\Applications\PROGRAM_NAME.exe\shell\open\command
the default value was pointing to a wrong directory.

So the solution is simple: just edit the default value of the key to point in the directory where the desired, non-appearing program resides, enclose it in quotes, and add a space and a "%1" last.

There may be other causes for this behaviour too (as in another answer above), so be careful and check if the registry value really is wrong (or not in quotes or missing the "%1" at the end) before editing registry!! AND BACKUP IT ALREADY!!!

Hope this helps someone, so simple a cause and solution, and all I could find was additional utilities to make it work or even tools with which to control the file/program associations, when less 2 minutes of clicking and typing would have worked...

EDIT: The registry key path modified; anything between "less than" and "bigger than" tags disappears.

Back to Windows Forum
6 total posts (Page 1 of 1)  

Related Discussions

Related Forums