Windows cannot find <full-dir-path>/<file-core-name>.txt in TextPad 5.0
To fix this problem:
Explorer / Tools / Folder Options / File Types / Extension /
Select: TXT -- Text Document:
Delete / YES / Close
Make sure that Text Documents are defined the way you want in
TextPad, and TextPad will take care of the rest.
Apparently, there is some glitch among the setting for TextPad
4.x (or before), user defined document types, registry settings,
and possibly also the internal 'cmd.exe' 'assoc' command and Mr.
Bill's retirement.
Windows cannot find...
Moderators: AmigoJack, bbadmin, helios, Bob Hansen, MudGuard
I had the same issue. The file always opened, but Windows still reported that it could not find the file.
I had to fix this via the registry. I don't want to get into too much detail as I don't know how comfortable you might be with the registry.
But if you *are* comfortable, I removed all the Classes entries for TextPad under HKEY_CURRENT_USER\Software\Classes. I then went in and re-set all my file associations. That corrected the problem for me. I think this was an issue for me because it was an upgrade and the information already existed from prior version.
I would strongly suggest you backup that HKCU\Software\Classes key before you begin so you can re-import if it becomes necessary.
I had to fix this via the registry. I don't want to get into too much detail as I don't know how comfortable you might be with the registry.
But if you *are* comfortable, I removed all the Classes entries for TextPad under HKEY_CURRENT_USER\Software\Classes. I then went in and re-set all my file associations. That corrected the problem for me. I think this was an issue for me because it was an upgrade and the information already existed from prior version.
I would strongly suggest you backup that HKCU\Software\Classes key before you begin so you can re-import if it becomes necessary.
windows cannot find [file]
I am having same problem as reported by LDR. I upgraded from 4.7.3 to 5.0.3 3 days ago. I run Windows XP SP2 and Firefox 2.0.0.4 (and Windows Explorer 7 only when forced to).
I used to right click on a filename and see Open File with ... TextPad. I often don't see this option. I look at files of many types (most of them not .txt). TextPad opens the file OK and then I get a message "Windows cannot find [the file]".
Any ideas as to why things have changed from what I am used to? Why I often don't get "Open With"? And how to fix this, hopefully other than by modifying the Registry which I am afraid to do.
I used to right click on a filename and see Open File with ... TextPad. I often don't see this option. I look at files of many types (most of them not .txt). TextPad opens the file OK and then I get a message "Windows cannot find [the file]".
Any ideas as to why things have changed from what I am used to? Why I often don't get "Open With"? And how to fix this, hopefully other than by modifying the Registry which I am afraid to do.
Windows cannot find [file]
Solution to problem posted yesterday. It's apparently a registry problem. My guru removed Textpad 5; then edited the registry, deleting all references to Textpad 4 and 5, reinstalled Textpad 5. Voila! Everything works properly (as it did before updating from 4.7.3 to 5.0.3). Can open any type of file with right click on filename and left click on "Textpad" on the options list. Happy, happy.
LDR's fix works for version 5, too
I tried LDR's fix (delete in explorer; set in textpad), and it worked for my version 5 textpad. (He had thought it a problem in earlier versions only.)
Before this, Textpad would open the file, but complain (or MS Windows would) that it couldn't find it. And if there were spaces in the path, it wouldn't do even that.
I did delete all Textpad associations first; I don't know if that made a difference.
Strangely enough, it always worked for certain extensions.
Before this, Textpad would open the file, but complain (or MS Windows would) that it couldn't find it. And if there were spaces in the path, it wouldn't do even that.
I did delete all Textpad associations first; I don't know if that made a difference.
Strangely enough, it always worked for certain extensions.