Install-ChocolateyFileAssociation breaks "create new text document" in Windows Explorer

[JVimes]

I try to associate .txt files with Notepad++ with this command:

Install-ChocolateyFileAssociation ".txt" "${Env:ProgramFiles(x86)}\Notepad++\notepad++.exe"

But afterwards, in Windows Explorer when I right-click and select "New", the entry "Text Document" no longer appears on the list. The problem seems to be that "txtfile" is changed to "notepad++.exe" in the default value of HKCR:\.txt.

I'm not sure if this is a bug, or just a very confusing behavior. Either way, we should change something to make sure folks aren't accidentally blowing away entries in the "New" submenu.

I'm on Windows 8.1

[JVimes]

@mwrock, I think you originally wrote the helper. I'm not familiar with the finer details of file association/creation, but maybe Windows Explorer is expecting Notepad++ to have a hook to create .txt files, and it doesn't. Or maybe something is actually inconsistent in the registry.

[ferventcoder]

@JVimes perhaps you can help me on that. I don't know that I ever changed the default value of .txt files, but I don't have the context menu entries for new files in Windows 2012R2. I wonder if it was removed?

[JVimes]

@ferventcoder Let me know what I can do to help. The menu entry is there by default, and it does appear the particular registry data change is what caused the entry to disappear.

[mwrock]

I can look tonight too. Been out of internet reach for a few days.

Sent from my Windows Phone

---

From: JVimesmailto:[email protected]
Sent: ‎9/‎1/‎2014 11:51 AM
To: chocolatey/chocolateymailto:[email protected]
Cc: Matt Wrockmailto:[email protected]
Subject: Re: [chocolatey] Install-ChocolateyFileAssociation breaks "create new text document" in Windows Explorer (#563)

@ferventcoder Let me know what I can do to help. The menu entry is there by default, and it does appear the particular registry data change is what caused the entry to disappear.

---

Reply to this email directly or view it on GitHub:
#563 (comment)

[mwrock]

I just did a little research and experimentation and figured out the issue. The chocolatey helper uses the DOS commands assoc and ftype to manipulate the association which in turn edits HKCR registry entries. This is all a bit wonky. For example if you change associations using the windows explorer gui, it changes a different set in HKCU and will give precedence to that.

Anyways the problem with the "New" context menu is that when ftype creates the new "content type" it does not give it a label. The readable text that appears next to each item in the menu. I tried manually adding that to the registry and then the new item appeared.

So the fix is pretty straight forward. The command will just need to edit the registry entry after calling fype. When I wrote the helper, I wanted to avoid direct registry editing and did not notice the missing New context menu item . As I have many times learned, direct registry editing is a core aspect that makes up the joy of windows automation Therefore I will be happily adding a PR to do just that after I slip into something a little more comfortable a little later.

[JVimes]

Is there perhaps an ftype argument that adds the label? Either way, thanks
for debugging. :) While you're in the code, I noticed the command opens a
new shell window each time. Is that on purpose?

On Mon, Sep 1, 2014 at 8:55 PM, Matt Wrock [email protected] wrote:

I just did a little research and experimentation and figured out the
issue. The chocolatey helper uses the DOS commands assoc and ftype to
manipulate the association which in turn edits HKCR registry entries. This
is all a bit wonky. For example if you change associations using the
windows explorer gui, it changes a different set in HKCU and will give
precedence to that.

Anyways the problem with the "New" context menu is that when ftype
creates the new "content type" it does not give it a label. The readable
text that appears next to each item in the menu. I tried manually adding
that to the registry and then the new item appeared.

So the fix is pretty straight forward. The command will just need to edit
the registry entry after calling fype. When I wrote the helper, I wanted
to avoid direct registry editing and did not notice the missing New context
menu item . As I have many times learned, direct registry editing is a core
aspect that makes up the joy of windows automation Therefore I will be
happily adding a PR to do just that after I slip into something a little
more comfortable a little later.

Reply to this email directly or view it on GitHub
#563 (comment)
.

[mwrock]

Unfortunately there is no argument for adding the label. My hunch is that ftype and assoc are ancient commands and are not getting much love in later windows versions (but I could be way off here) you cant even call these from powershell directly but have to invoke via cmd.exe. The extra shell is due to the fact that chocolatey has to ensure that the call is run with elevated privileges and invokes in a elevated shell to do that.

[mwrock]

Just Submitted PR #564 to address this.

[JVimes]

I manually installed the two modified files and tried it out. After running the command above, it still opens .txt files in Notepad by default, not Notepad++. Windows 8.1 does tell me "you have new applications that can open this type of file" and Notepad++ is on the list. Is that the intended behavior? Also, the New menu now has "Notepad++.exe file" instead of "text file", like it would say if I manually tell it to use Notepad++ as the default .txt editor. It's a step in the right direction, but a little unexpected.

[dragon788]

@JVimes I think this is a new behaviour of Windows (that sucks) where they are preventing programs (potentially maliciously) from taking over file associations. This has meant that web browsers and multimedia programs have to tell you how to change the association, they can't simply do it themselves anymore. I've seen this more in Windows 10, but I do recall seeing it back in Windows 8.x as well.

[JVimes]

I've seen those new instruction prompts, too. I wonder if those apps are limited because they aren't running elevated. Worth a little digging. I see that Ftype txtfile=C:\Program Files (x86)\Notepad++\notepad++.exe %1 works for me in an elevated cmd prompt on Windows 10.