@Alan-Kilborn: To the point of the second camp: I’m not sure whether dragging-and-dropping a file from a Windows Explorer into NPP is a Windows Explorer operation, or a NPP operation, or a strange mix, so I have my doubts whether there is anything you could do in the NPP code to optionally “intercept” that operation – but I’ve never coded a drag-and-drop interface, so I could be wrong.
@MAPJe71 & @Scott-Sumner: Yeah, there was a reason I didn’t explain that “command-trickery”: I had grabbed that command from some website a few years back, and had since forgotten exactly why they did the set trickery.
It seems to work even with the simplified cmd.exe /c (echo "%1" | clip.exe).
Ah, I did some searching, and found the page I think I originally found it from: http://www.askvg.com/registry-tweak-to-add-copy-as-path-option-in-files-and-folders-context-menu-in-windows/ : It turns out that the simplified cmd.exe /c (echo "%1" | clip.exe) will include the newline in the clipboard, whereas the set/p trickery will prevent the newline from being in the clipboard.
And I was also reminded in the article: with a default Vista/Win7/Win8 installation, there is already a “Copy as Path” in the extended SHIFT+RightClick menu – and without the newline – so you don’t even need my registry hack, it should just “be there”. (If you don’t notice it, it’s probably down near “Pin to Start Menu” and above the “Send To…”)
Ah, there we go: http://superuser.com/questions/295484/unhide-windows-7-context-menu-extras-permanently reminded me why I made my own version of the Copy As Path: some of the SHIFT+RightClick menu items can be “unhidden” so it goes into the normal RightClick menu (the extra “shift” annoyed me), but the “Copy as Path” stays hidden.
