file associations (file types to open with npp)
-
no, it doesn’t,
e.g. I deleted already registered txt file with[-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]and tried yours and no error was shown but when tried to open .txt file it asked what I wanted to open it with
-
I think I fixed it to work in windows 8.1 and windows 7:
https://textuploader.com/1awwn/rawI found out that some files need the “hash” in registry which is awkward,
because I don’t know if it will work in another pc,
but I don’t have another 8.1,
so if anyone wants to test it -
-
:-( - although I can see why securing it might be a good choice. Too bad - at least I learnt something new. :-)
-
With Windows 10, at least, the good old fashioned
HKCR\.ext (Default)=SomeActionandHKCR\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.
-
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. -
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.)
-
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?? -
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 existingtxtfiletype; 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.eko2key exists inHKCU\Software\Classeswhere I put it, and also exists asHKCR\.eko2, but does not exist asHKLM\Software\Classes\.eko2, so I believe that writing toHKCU\Software\Classes\is safer.As another experiment, I created
HKCU\Software\Classes\EkoThreeTypewith(default) = Eko palypse type 3, subkeyshell, subkeyNotepad++ (default)=notepad++...thenHKCU\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 usenircmd shellrefreshandnircmd sysrefresh, using the NirSoft nircmd utility. This avoids having to reboot or log in/out for every change. -
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?
-
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…
- I also removed any *.txt from
- 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
.txtwas gone, and it shows up using the one from your.regsequence (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\.txtassocation (Admin regedit) and remove theHKCU\Software\Classes\.txtassoc (normal user regedit) and refresh, it goes back to using my old assocation. - If there already is a
-
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 -
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.)
-
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\.txtthat 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 undertxt– so you were telling Windows that the user had chosen a different association for.txtthan you were defining, so windows was still using your old “txt_auto_file” rather than the new “txt”. -
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
-
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 /sOther than that, I don’t know what else to suggest.
-
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
