file associations (file types to open with npp)

patrickdrd

ok I’ve found it,
https://stackoverflow.com/questions/17946282/whats-the-hash-in-hkcu-software-microsoft-windows-currentversion-explorer-filee

Eko palypse

:-( - although I can see why securing it might be a good choice. Too bad - at least I learnt something new. :-)

PeterJones

With Windows 10, at least, the good old fashioned HKCR\.ext (Default)=SomeAction and HKCR\SomeAction\command (default)=notepad++ "%1" still works for me, and I thought if it worked in Win7 and works in Win10, it would work in Win8. But I could be wrong.

An example of me recently verifying that the old-style assocation works can be found on superuser. maybe it’s because the .0-.9 extensions were ones that weren’t already being interfered with using the Classes/FilesExts assocation.

Eko palypse

But, afaik, you shouldn’t use HKEY_CLASSES_ROOT as this, itself, isn’t a persistent key.
It’s just another view of keys stored in HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER.
I’m unsure what kind of issue would possibly rise if one corrupts HKCR.

PeterJones

It’s worked with HKCR on every windows (I believe since NT; definitely XP, 7, and 10) for me, and I’ve never had problems with it on any machine at work or at home, where I’ve used this method for years. When I write the one in HKCR, it’s always correctly been copied to the appropriate HKLM/HKCU locations without difficulty.

(edit: that doesn’t mean it’s the “right” way to do it; I’ve just never had a problem with it.)

Eko palypse

Seems one of those things WE do which wasn’t initially planned by MS :-)
But if you replace it under HKCR, is it set in HKLM or HKCU?
If it is HKLM, then isn’t it a security issue??

PeterJones

You are right: if I write to HKCR, it duplicates to HKLM, so that is an issue (of course, if you don’t have permission to write to HKLM, it won’t do that write).

I just tried an experiment where I created HKCU\Software\Classes\.eko2 (.eko was my write-to-HKCR experiment, so wanted a new extension), and pointed it to my existing txtfile type; when I do that and refresh environment, it associates .eko2 file extension with txtfile, and thus opens with Notepad++ when I double-click… When I look back through the registry, the .eko2 key exists in HKCU\Software\Classes where I put it, and also exists as HKCR\.eko2, but does not exist as HKLM\Software\Classes\.eko2, so I believe that writing to HKCU\Software\Classes\ is safer.

As another experiment, I created HKCU\Software\Classes\EkoThreeType with (default) = Eko palypse type 3, subkey shell, subkey Notepad++ (default)=notepad++... then HKCU\Software\Classes\.eko3 (default)=EkoThreeType. It also properly associated.

[HKEY_CURRENT_USER\Software\Classes\EkoThreeType]
@="Eko palypse type 3"

[HKEY_CURRENT_USER\Software\Classes\EkoThreeType\shell]
@="Notepad++"

[HKEY_CURRENT_USER\Software\Classes\EkoThreeType\shell\Notepad++]
@="Eko3 Edit With Notepad++"

[HKEY_CURRENT_USER\Software\Classes\EkoThreeType\shell\Notepad++\command]
@="\"c:\\usr\\local\\scripts\\notepad++.bat\" \"%1\""

[HKEY_CURRENT_USER\Software\Classes\.eko3]
@="EkoThreeType"

So, even using HKCU\Software\Classes, I can associate a file extension and new filetype for myself.

-----
PS: for refresh, i use nircmd shellrefresh and nircmd sysrefresh, using the NirSoft nircmd utility. This avoids having to reboot or log in/out for every change.

patrickdrd

well that example with .eko3 worked for me too (in 8.1),
but when I try the same with .txt, e.g.:

[HKEY_CURRENT_USER\Software\Classes\.txt]
@="txt"
[HKEY_CURRENT_USER\SOFTWARE\Classes\txt\DefaultIcon]
@="\"D:\\Utilities\\PortableApps\\Notepad++\\notepad++.exe\",0"
[HKEY_CURRENT_USER\Software\Classes\txt]
@="Text Document"
[HKEY_CURRENT_USER\Software\Classes\txt\shell]
@="Notepad++"
[HKEY_CURRENT_USER\Software\Classes\txt\shell\Notepad++]
@="Eko3 Edit With Notepad++"
[HKEY_CURRENT_USER\Software\Classes\txt\shell\Notepad++\command]
@="\"D:\\Utilities\\PortableApps\\Notepad++\\notepad++.exe\" \"%1\""

it doesn’t work

can you try the same @PeterJones?

PeterJones

So, based on my experiments, the following worked for me:

If there already is a HKLM\Software\Classes\.txt, you have to delete it using Admin privileges
If there already is a HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.txt, delete it (shouldn’t require Admin, because it’s Current User)
- I also removed any *.txt from HKCU\Software\Microsoft\Windows\CurrentVersion\ApplicationAssociationToasts\ – I don’t know if that’s required (I don’t think so), but I had already done it, so…
Then run your .reg file shown, which will set up the HKCU\Software\Classes\.txt
Then do a refresh (reboot, or logout/login, or nircmd shellrefresh && nircmd sysrefresh)
When I did all that, my old association with .txt was gone, and it shows up using the one from your .reg sequence (I actually used “DRD Text Document” as the name and “DRD Edit With Notepad++” to disambiguate from my other naming scheme)

If I then re-instate the HKLM\Software\Classes\.txt assocation (Admin regedit) and remove the HKCU\Software\Classes\.txt assoc (normal user regedit) and refresh, it goes back to using my old assocation.

patrickdrd

no, I didn’t mean to try my method, I know that the reg works but it contains this hash,
if you found a working way of setting the .txt association without the hash, please post

PeterJones

@patrickdrd ,

The reg file I was talking about was

[HKEY_CURRENT_USER\Software\Classes\.txt]
@="txt"
[HKEY_CURRENT_USER\SOFTWARE\Classes\txt\DefaultIcon]
@="\"D:\\Utilities\\PortableApps\\Notepad++\\notepad++.exe\",0"
[HKEY_CURRENT_USER\Software\Classes\txt]
@="Text Document"
[HKEY_CURRENT_USER\Software\Classes\txt\shell]
@="Notepad++"
[HKEY_CURRENT_USER\Software\Classes\txt\shell\Notepad++]
@="Eko3 Edit With Notepad++"
[HKEY_CURRENT_USER\Software\Classes\txt\shell\Notepad++\command]
@="\"D:\\Utilities\\PortableApps\\Notepad++\\notepad++.exe\" \"%1\""

… which does not contain a hash. Using that file, and the steps I described above, the association worked just fine.

(edit: well, okay, almost that file. I had to add the registry header line, and I converted the path to notepad++.exe to work for my setup.)

PeterJones

Further details:

The hash you are mentioning, from your original post:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.txt\UserChoice]
"ProgId"="txt_auto_file"
"Hash"="q4kw7ShKh2M="

Is part of the HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.txt that I told you to delete – it will delete the .txt and everything under it, including your hash.

While quoting that piece from your original post, I see what may have been going on from the start: You are telling windows that the current user has chosen the program ID (ProgID) of “txt_auto_file”. But then you are defining the details of the file type, not under txt_auto_file, but under txt – so you were telling Windows that the user had chosen a different association for .txt than you were defining, so windows was still using your old “txt_auto_file” rather than the new “txt”.

patrickdrd

well I’ve just tried this:
[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes.txt]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\txt]
[-HKEY_CURRENT_USER\SOFTWARE\Classes.txt]
[-HKEY_CURRENT_USER\SOFTWARE\Classes\txt]
[-HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts.txt\UserChoice]
[-HKEY_CURRENT_USER\Software\Microsoft\Windows\Roaming\OpenWith\FileExts.txt\UserChoice]
[-HKEY_CURRENT_USER\Software\Classes.txt]
[-HKEY_CURRENT_USER\Software\Classes\txt]

[HKEY_CURRENT_USER\Software\Classes\.txt]
@="txt"
[HKEY_CURRENT_USER\SOFTWARE\Classes\txt\DefaultIcon]
@="\"D:\\Utilities\\PortableApps\\Notepad++\\notepad++.exe\",0"
[HKEY_CURRENT_USER\Software\Classes\txt]
@="Text Document"
[HKEY_CURRENT_USER\Software\Classes\txt\shell]
@="Notepad++"
[HKEY_CURRENT_USER\Software\Classes\txt\shell\Notepad++]
@="Edit With Notepad++"
[HKEY_CURRENT_USER\Software\Classes\txt\shell\Notepad++\command]
@="\"D:\\Utilities\\PortableApps\\Notepad++\\notepad++.exe\" \"%1\""

as you can see I’m deleting everything before the operation, so there is no txt_auto_file or anything, however that doesnt work still

PeterJones

I think you might have to delete the whole ...\FileExts\.txt\ key , not just the \UserChoice\ subkey. And don’t forget that to see the changes, you have to initiate a refresh in some manner – whether by nirsoft or windows API or logging out/in, or rebooting.

as you can see I’m deleting everything before the operation, so there is no txt_auto_file or anything, however that doesnt work still

Actually, what you just showed never mentioned txt_auto_file, so I cannot see that you’re deleting everything.

Have you actually verified in regedit that it’s done the additions and deletions that you are expecting?

From a command line,

REG QUERY HKCU\Software\Classes\.txt /s
REG QUERY HKLM\Software\Classes\.txt /s
REG QUERY HKCU\Software\Classes\txt /s
REG QUERY HKLM\Software\Classes\txt /s
REG QUERY HKCU\Software\Classes\txt_auto_file /s
REG QUERY HKLM\Software\Classes\txt_auto_file /s

Other than that, I don’t know what else to suggest.

patrickdrd

well, thank you very much, you found the problem!

which was in deleting the whole

...\FileExts\.txt\

I was able to maintain my machine code too,
here is the new version (final I hope) with my associations,
anyone can adjust it to his needs of course of replace HKLM to HKCU if he wants:

https://textuploader.com/1awwn/raw