Incorrect file associations

[Thanny]

If I type " foo.jpg", the image is opened in the wrong program.

CMD uses the correct program.

This has been the case for several versions of 4NT/TCMD, up to the latest I have installed (10.0 build 76).

Is there any way to trick it into behaving correctly?

 

[samintz]

I can't explain why CMD behaves differently than TCC. If you type that
same filename from Explorer's Start | Run dialog which program do you get?

>From a TCC prompt the FTYPE and ASSOC commands will show you what the file

type and file associations are.
For example on my PC:

[C:\Program Files\ARM] assoc .jpg
.jpg=Google.PhotoViewer.3.0

[C:\Program Files\ARM] ftype Google.PhotoViewer.3.0
Google.PhotoViewer.3.0="C:\Program
Files\Google\Picasa3\PicasaPhotoViewer.exe" "%1"

-Scott

Thanny <> wrote on 09/17/2009 06:05:03 PM:

> If I type " foo.jpg", the image is opened in the wrong program.
>
> CMD uses the correct program.
>
> This has been the case for several versions of 4NT/TCMD, up to the
> latest I have installed (10.0 build 76).
>
> Is there any way to trick it into behaving correctly?
>
>
>
>

 

[vefatica]

On Thu, 17 Sep 2009 17:05:26 -0500, Thanny <> wrote:

|If I type " foo.jpg", the image is opened in the wrong program.
|
|CMD uses the correct program.

Do you have a ".JPG" environment variable?
--
- Vince

 

[Charles Dye]

Also, what does ASSOC .JPG report?

If you feed ASSOC's output into FTYPE, what do you get? For example, if ASSOC .JPG reports .JPG=JPEGFILE, what does FTYPE JPEGFILE have to say?

 

[Thanny]

Also, what does ASSOC .JPG report?

If you feed ASSOC's output into FTYPE, what do you get? For example, if ASSOC .JPG reports .JPG=JPEGFILE, what does FTYPE JPEGFILE have to say?

ASSOC .jpg says "jpegfile", and FTYPE jpegfile shows the path to MS Photo Editor.

But that's not right. I set the association to a program called PMView (old but efficient program that I originally used under OS/2).

In the registry, the key ".jpg" under HKEY_CLASSES_ROOT has a default value of "jpegfile". The key "jpegfile" has shell->Open pointing to MS Photo Editor. This must be what TCMD is looking at, but that's not the key set by Vista's file association applet, and not what Explorer and CMD look at.

The correct key to look at in Vista appears to be HKEY_CURRENT_USER\ Software\ Microsoft\ Windows\ CurrentVersion\ Explorer\ FileExts (spaces added to help with line breaks). For the JPEG example, the subkey under that is .jpg\UserChoice, and the relevant value is Progid, which I've verified points to the program I selected (or, rather, the registry key - PMView.JPG - under HKEY_CLASSES_ROOT that defines how to launch it).

I worked around the issue by changing the default value of the .jpg key to PMView.JPG, and now TCMD launches the right program. But since that's not how Vista itself handles associations, it should be "fixed" in TCMD, even though it looks as though its behavior makes more sense (why would Vista store system-wide settings under a key for Explorer?).

 

[Charles Dye]

ASSOC .jpg says "jpegfile", and FTYPE jpegfile shows the path to MS Photo Editor.

But that's not right. I set the association to a program called PMView (old but efficient program that I originally used under OS/2).

In the registry, the key ".jpg" under HKEY_CLASSES_ROOT has a default value of "jpegfile". The key "jpegfile" has shell->Open pointing to MS Photo Editor. This must be what TCMD is looking at, but that's not the key set by Vista's file association applet, and not what Explorer and CMD look at.

The correct key to look at in Vista appears to be HKEY_CURRENT_USER\ Software\ Microsoft\ Windows\ CurrentVersion\ Explorer\ FileExts (spaces added to help with line breaks). For the JPEG example, the subkey under that is .jpg\UserChoice, and the relevant value is Progid, which I've verified points to the program I selected (or, rather, the registry key - PMView.JPG - under HKEY_CLASSES_ROOT that defines how to launch it).

I worked around the issue by changing the default value of the .jpg key to PMView.JPG, and now TCMD launches the right program. But since that's not how Vista itself handles associations, it should be "fixed" in TCMD, even though it looks as though its behavior makes more sense (why would Vista store system-wide settings under a key for Explorer?).

I don't think it's a Vista thing. If I'm not mistaken, XP works the same way. Systemwide associations go under HKEY_CLASSES_ROOT; per-user associations go under HKEY_CURRENT_USER. Explorer checks the per-user settings first, then falls back on the systemwide. Take Command checks the systemwide association only, AFAIK.

You can bypass the whole messy, two-levels-of-indirection registry business and set your own association for Take Command (only!) by setting an environment variable:

set .jpg=c:\path\to\pmview.exe

Stick it in TCSTART.BTM, and it'll be set for each new TCC session.

 

[vefatica]

On Wed, 23 Sep 2009 17:19:38 -0500, Thanny <> wrote:

|In the registry, the key ".jpg" under HKEY_CLASSES_ROOT has a default value of "jpegfile". The key "jpegfile" has shell->Open pointing to MS Photo Editor. This must be what TCMD is looking at, but that's not the key set by Vista's file association applet, and not what Explorer and CMD look at.
|
|The correct key to look at in Vista appears to be HKEY_CURRENT_USER\ Software\ Microsoft\ Windows\ CurrentVersion\ Explorer\ FileExts (spaces added to help with line breaks). For the JPEG example, the subkey under that is .jpg\UserChoice, and the relevant value is Progid, which I've verified points to the program I selected (or, rather, the registry key - PMView.JPG - under HKEY_CLASSES_ROOT that defines how to launch it).
|
|I worked around the issue by changing the default value of the .jpg key to PMView.JPG, and now TCMD launches the right program. But since that's not how Vista itself handles associations, it should be "fixed" in TCMD, even though it looks as though its behavior makes more sense (why would Vista store system-wide settings under a key for Explorer?).

It seems to be the other way around. HKEY_CLASSES_ROOT has the system-wide
settings. The entries in HKEY_CURRENT_USER are user-customizations.

Actually, Microsoft seems to consider this somewhat of a problem. See:

http://support.microsoft.com/kb/950505
--
- Vince

 

[rconn]

On Wed, 23 Sep 2009 17:19:38 -0500, Thanny <> wrote:

|In the registry, the key ".jpg" under HKEY_CLASSES_ROOT has a default value of "jpegfile". The key "jpegfile" has shell->Open pointing to MS Photo Editor. This must be what TCMD is looking at, but that's not the key set by Vista's file association applet, and not what Explorer and CMD look at.
|
|The correct key to look at in Vista appears to be HKEY_CURRENT_USER\ Software\ Microsoft\ Windows\ CurrentVersion\ Explorer\ FileExts (spaces added to help with line breaks). For the JPEG example, the subkey under that is .jpg\UserChoice, and the relevant value is Progid, which I've verified points to the program I selected (or, rather, the registry key - PMView.JPG - under HKEY_CLASSES_ROOT that defines how to launch it).
|
|I worked around the issue by changing the default value of the .jpg key to PMView.JPG, and now TCMD launches the right program. But since that's not how Vista itself handles associations, it should be "fixed" in TCMD, even though it looks as though its behavior makes more sense (why would Vista store system-wide settings under a key for Explorer?).

It seems to be the other way around. HKEY_CLASSES_ROOT has the system-wide
settings. The entries in HKEY_CURRENT_USER are user-customizations.

Actually, Microsoft seems to consider this somewhat of a problem. See:

http://support.microsoft.com/kb/950505
--
- Vince

It's twice as awful as you think -- in addition to putting the extensions in (at least) two different places, Microsoft also puts the program to execute in at least two different places (shell\open\command and shell\open2\command). The order these are searched and executed also varies depending on the version of Windows.

 

[mtotman]

The order these are searched and executed also varies depending on the version of Windows.

At least Microsoft is consistent about that. :)