If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Why doesn't a folder work in HKLM SW MS W CV App Paths?
Why doesn't a folder work in the App Paths key?
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\folder.exe Value Data = c:\data\folder1\folder2\folder3\ A "file" works just fine when I add a "new key": HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\file.exe Value Data = c:\data\folder1\folder2\folder3\file.ppt When I type Start Run filereturn, up pops the file. But when I type Start Run folderreturn, the folder does not open. Why not? |
Ads |
#2
|
|||
|
|||
Why doesn't a folder work in HKLM SW MS W CV App Paths?
On Tue, 18 Apr 2017 02:17:00 -0000 (UTC), Tomos Davies wrote:
Why doesn't a folder work in the App Paths key? HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\folder.exe Value Data = c:\data\folder1\folder2\folder3\ A "file" works just fine when I add a "new key": HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\file.exe Value Data = c:\data\folder1\folder2\folder3\file.ppt When I type Start Run filereturn, up pops the file. But when I type Start Run folderreturn, the folder does not open. Why not? Because the "App Paths" registry key serves as a lookup dictionary for application file's paths, not folder paths. This key is similar to the PATH environment variable (i.e. for searching a file), so you can't use it with a folder. Also, "App Paths" only works if the inputted name is handled by the shell. So, it won't work if you type the file from the CMD command prompt unless you use the START command. See below for details about the "App Paths" registry key: https://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx |
#3
|
|||
|
|||
Why doesn't a folder work in HKLM SW MS W CV App Paths?
Tomos,
Why doesn't a folder work in the App Paths key? .... Why not? Simply said: Those registry keys are not causing the effect you think you are getting with that second example* see: https://msdn.microsoft.com/en-us/lib...121(v=vs.85).a spx Specifically, read, under "To register and control the behavior of your applications with the App Paths subkey", what the "Path" key is ment for. *that document - executable connection is caused by some registry keys HKEY_CLASSES_ROOT. See all those entries starting with a dot ? Yup, those are the recognised file extensions. Regards, Rudy Wieser Question: does "folder.exe" actually exists ? I bet you it doesn't. Does "file.exe" exist ? I bet you it does. Suggestion: try to change, in that second example, "file.exe" into "does not exist.exe" and try again. I think it will not work either. The registry entries you're showing seem to be ment to connect a specific *document* to a specific *program*. As such it won't work for folders (which neither is a document, nor needs a(n external) program to be able to be opened). Regards, Rudy Wieser P.s. You *might* have a chance to get the path accepted and send to a program, but thats about it Tomos Davies schreef in berichtnieuws ... Why doesn't a folder work in the App Paths key? HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\folder.exe Value Data = c:\data\folder1\folder2\folder3\ A "file" works just fine when I add a "new key": HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\file.exe Value Data = c:\data\folder1\folder2\folder3\file.ppt When I type Start Run filereturn, up pops the file. But when I type Start Run folderreturn, the folder does not open. Why not? |
#4
|
|||
|
|||
Why doesn't a folder work in HKLM SW MS W CV App Paths?
In , R.Wieser suggested:
Question: does "folder.exe" actually exists ? I bet you it doesn't. Does "file.exe" exist ? I bet you it does. Thank you and everyone for your advice. I think most were correct, but wrong in one area. All the App Paths "keys" I make end with "exe" even though there is no exe named "file.exe" (and "file" was just a bogus name anyway, like "foobar", where foobar.exe wouldn't exist either). You were correct that an app handler had to be registered, and the target file must exist, but those are minor details in the scheme of things (since this has been working for many years). Suggestion: try to change, in that second example, "file.exe" into "does not exist.exe" and try again. I think it will not work either. Let me clarify that this process works just fine: 1. Create the target text file (which can be empty). c:\ dir c:\folder1\folder2\foo.txt 2. Make a note that "foo.exe" does not exist! c:\foo.exe 'foo.exe' is not recognized as an internal or external command, operable program or batch file. 3. Create an App Paths key (which must end in exe!). HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\foo.exe foo.exe=c:\folder1\folder2\foo.txt 4. Test it out (it works every time!). Start Run fooreturn 5. That opens the file in the registered editor. But, it doesn't work for opening directories. I'm sure it "would" work for opening directories if we had a way to run the Windows File Explorer via a command from the start run dialog though. For example, this works just fine to open up the desired folder! Start Run c:\folder1\folder2\ So the question is simply how to make a "shortcut" to that command! |
#5
|
|||
|
|||
Why doesn't a folder work in HKLM SW MS W CV App Paths?
Tomos,
All the App Paths "keys" I make end with "exe" even though there is no exe named "file.exe" (and "file" was just a bogus name anyway, like "foobar", where foobar.exe wouldn't exist either). Ah. I assumed that you used it as intended. Instead, you seem to use it in a tricked way. You were correct that an app handler had to be registered, and the target file must exist, but those are minor details in the scheme of things (since this has been working for many years). Not quite a "minor details" for someone whom you are asking to solve a problem: If he doesn't directly recognise the problem he needs to be able to replicate your problem to be able to see what the result, and its problem, might be. 3. Create an App Paths key (which must end in exe!). HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\foo.exe foo.exe=c:\folder1\folder2\foo.txt Problem: The above is not the same as what you posted in your initial message. Did you place the "c:\folder1\folder2\foo.txt" data in the "(Default) dataitem, or did you create a dataitem with the name of the executable (would be a bit double-up, as its parent key also has that name, but you never know ..) 4. Test it out (it works every time!). Start Run fooreturn 5. That opens the file in the registered editor. But, it doesn't work for opening directories. I already tried it before I replied to your first post, and have now done the same again. I still get the same error: "Windows cannot find ..." Yadayadayada. And yes, the same file opens in notepad when I double-click it (its bound to a program). Question: what happens when you do *not* enter those registry-keys for those "file.ppt" or "foo.txt" files and try to "run" them ? Do they still get opened ? Than those files might be on a/the default searchpath. So the question is simply how to make a "shortcut" to that command! Unanswerable, as I can't even replicate the behaviour you're seeing. Regards, Rudy Wieser -- Origional message: Tomos Davies schreef in berichtnieuws ... In , R.Wieser suggested: Question: does "folder.exe" actually exists ? I bet you it doesn't. Does "file.exe" exist ? I bet you it does. Thank you and everyone for your advice. I think most were correct, but wrong in one area. All the App Paths "keys" I make end with "exe" even though there is no exe named "file.exe" (and "file" was just a bogus name anyway, like "foobar", where foobar.exe wouldn't exist either). You were correct that an app handler had to be registered, and the target file must exist, but those are minor details in the scheme of things (since this has been working for many years). Suggestion: try to change, in that second example, "file.exe" into "does not exist.exe" and try again. I think it will not work either. Let me clarify that this process works just fine: 1. Create the target text file (which can be empty). c:\ dir c:\folder1\folder2\foo.txt 2. Make a note that "foo.exe" does not exist! c:\foo.exe 'foo.exe' is not recognized as an internal or external command, operable program or batch file. 3. Create an App Paths key (which must end in exe!). HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\foo.exe foo.exe=c:\folder1\folder2\foo.txt 4. Test it out (it works every time!). Start Run fooreturn 5. That opens the file in the registered editor. But, it doesn't work for opening directories. I'm sure it "would" work for opening directories if we had a way to run the Windows File Explorer via a command from the start run dialog though. For example, this works just fine to open up the desired folder! Start Run c:\folder1\folder2\ So the question is simply how to make a "shortcut" to that command! |
#6
|
|||
|
|||
Why doesn't a folder work in HKLM SW MS W CV App Paths?
Tomos,
So the question is simply how to make a "shortcut" to that command! Two things: There *is* no command involved (just a method), and your current question is not the same as the one in your subject line. One of the hardest and also most irritating situations is where someone asks something, and than keeps changing his story (in your case, both the "this is what it is" as well as the "this is what I want" parts). :-( But I realize I spoke to soon in previous message: I just did something similar by creating a shortcut to a folder into the C:\WINDOWS folder (and trim the shortcuts name back to the folders name again). Works for files too. Better yet: as a shortcut allows you to change what it executes you can even write it for an un-bound document, just by, in the shortcut, prepending the executables drive, full path and name to the document (don't forget to double-quote it when it contains spaces though) Though if you want to use that "run" method extensivily I would suggest you to create a seperate folder to put all the shortcuts in, and include the folder in the default searchpath. Regards, Rudy Wieser -- Origional message: Tomos Davies schreef in berichtnieuws ... In , R.Wieser suggested: Question: does "folder.exe" actually exists ? I bet you it doesn't. Does "file.exe" exist ? I bet you it does. Thank you and everyone for your advice. I think most were correct, but wrong in one area. All the App Paths "keys" I make end with "exe" even though there is no exe named "file.exe" (and "file" was just a bogus name anyway, like "foobar", where foobar.exe wouldn't exist either). You were correct that an app handler had to be registered, and the target file must exist, but those are minor details in the scheme of things (since this has been working for many years). Suggestion: try to change, in that second example, "file.exe" into "does not exist.exe" and try again. I think it will not work either. Let me clarify that this process works just fine: 1. Create the target text file (which can be empty). c:\ dir c:\folder1\folder2\foo.txt 2. Make a note that "foo.exe" does not exist! c:\foo.exe 'foo.exe' is not recognized as an internal or external command, operable program or batch file. 3. Create an App Paths key (which must end in exe!). HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\foo.exe foo.exe=c:\folder1\folder2\foo.txt 4. Test it out (it works every time!). Start Run fooreturn 5. That opens the file in the registered editor. But, it doesn't work for opening directories. I'm sure it "would" work for opening directories if we had a way to run the Windows File Explorer via a command from the start run dialog though. For example, this works just fine to open up the desired folder! Start Run c:\folder1\folder2\ So the question is simply how to make a "shortcut" to that command! |
#7
|
|||
|
|||
Why doesn't a folder work in HKLM SW MS W CV App Paths?
In , R.Wieser suggested:
Two things: There *is* no command involved (just a method), and your current question is not the same as the one in your subject line. If the subject line isn't the same as the question then I made a mistake which I admit. I am sorry for the confusion. The only question really is how to open up a directory without having to type the entire directory path. For example, I do this all the time to open up Windows explorer: Start Run \return or Start Run D:return The problem is when the directory path is far longer, like this: Start Run C:\program files\whatever\whatever\whatever\ Typing that would open up the directory just fine. However, the goal would be to open up that directory by typing: Start Run somethingreturn I remember, years ago, I was able to do this; but I forgot how. The question is that. How can we open up a long-path directory by typing the short-path: Start Run whateverreturn |
#8
|
|||
|
|||
Why doesn't a folder work in HKLM SW MS W CV App Paths?
In , R.Wieser suggested:
3. Create an App Paths key (which must end in exe!). HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\foo.exe foo.exe=c:\folder1\folder2\foo.txt Problem: The above is not the same as what you posted in your initial message. I don't think there was ever an inconsistency but if there was, I apologize since I have been doing this ever since, oh, I think about Win95 days, so, it's pretty common stuff. You can open up any file you want just by doing this. For example, I edit the hosts file all the time this way. Did you place the "c:\folder1\folder2\foo.txt" data in the "(Default) dataitem, or did you create a dataitem with the name of the executable (would be a bit double-up, as its parent key also has that name, but you never know ..) I'm confused by your question as the "foo.exe" is only a technicality. There is no file named "foo.exe". The restriction that the App Paths key must end with exe is a Microsoft restriction. I only use that name because that's what works and that is what is documented to work since, oh, about Win95 days (maybe even earlier for all I know). It started working when they created the App Paths key, whenever that was. I already tried it before I replied to your first post, and have now done the same again. I still get the same error: "Windows cannot find ..." Yadayadayada. And yes, the same file opens in notepad when I double-click it (its bound to a program). I wrote better step by step instructions in another post. This is really old stuff, which came about when Windows shipped with a registry. So if it's not working for you, then I must have explained it wrong, because it has been working since Microsoft created the "app paths" key. Question: what happens when you do *not* enter those registry-keys for those "file.ppt" or "foo.txt" files and try to "run" them ? Do they still get opened ? Than those files might be on a/the default searchpath. In general, nothing happens if you don't create that key. There is a technicality, in that if the folder is open at the time you run the key, I seem to remember that it works in that case, but that's a special case. Also if you don't create the (could be empty) file in the first place, it doesn't work either. But since this method has been around for as long as Windows has had a registry, those are well known caveats I would think. So the question is simply how to make a "shortcut" to that command! Unanswerable, as I can't even replicate the behaviour you're seeing. I posted better suggestions. Here's another one, if you're interested. 1. Make a copy of your HOSTS file to "hosts.txt". 2. Create the registry key (for WinXP) of: App Paths key = myhosts.exe myhosts.exe = c:\windows]system32\drivers\etc\hosts.txt 3. Start Run myhostsreturn 4. That opens up the hosts file (in GVim for me) in your text editor. 5. For me, I can edit that hosts file & save it as "hosts". While I'm on WinXP, your hosts file path may be different if you're on a different Windows, and while I'm using GVIM as my registered text editor, your registered text editor may work differently. I've been using this for years to edit my hosts file easily. Here is what I do: A. I run: Start Run myhostsreturn B. I edit the hosts.txt file as I see fit & then type ":!whosts" C. That saves the edited hosts.text to HOSTS While this works, notice I have to have a copy of HOSTS named "hosts.txt", simply because I don't have HOSTS registered to open up in anything. I seem to remember, many years ago, I was able to type "Start Run hosts" and it edited the "HOSTS" file (sans extension); but I forgot in the interim how I managed that trick of bringing up any file that didn't have an extension in my default text editor (which as always been vim). |
#9
|
|||
|
|||
Why doesn't a folder work in HKLM SW MS W CV App Paths?
In , R.Wieser suggested:
Not quite a "minor details" for someone whom you are asking to solve a problem: If he doesn't directly recognise the problem he needs to be able to replicate your problem to be able to see what the result, and its problem, might be. I agree with you, and apologize for assuming that everyone already knew that the use of App Paths was commonly done this way. This is reproducible in a cut and paste to test. 1. Create the target text file (which can be empty). c:\ dir c:\foo.txt 2. Make a note that "foo.exe" does not exist! c:\foo.exe 'foo.exe' is not recognized as an internal or external command, operable program or batch file. 3. Create an App Paths key (which must end in exe!). HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\foo.exe foo.exe=c:\foo.txt 4. Test it out (it works every time!). Start Run fooreturn 5. That opens the file in the registered editor! 6. Note that this is useful to open files such as host files which are buried deeply inside Windows hierarchies. 7. But, it doesn't work for opening directories. 6. However, "this" works for opening directories: Start Run \return 7. I think there must be a way to use variables, perhaps. Start Run %data% (or something like that) |
#10
|
|||
|
|||
Why doesn't a folder work in HKLM SW MS W CV App Paths?
Tomos,
There is no file named "foo.exe". I understood that. I created that key, and placed the drive, path, name and extension of a textfile in the "(default)" dataitem. No workie. In general, nothing happens if you don't create that key. I take it you have not tried it ? :-( Also if you don't create the (could be empty) file in the first place, it doesn't work either. As I already said, when I doubleclick the file it opens in notepad. I think you can assume from that that my testfile (which was actually a text document I had handy) existed. I posted better suggestions. No, you didn't: myhosts.exe = c:\windows]system32\drivers\etc\hosts.txt This can mean several things (besides not being able to enter an "=" sign to create a "name" and "data" part), like needing to create a dataitem with the name "myhosts.exe" containing the data "c:\windows\system32\drivers\etc\hosts.txt" (if you don't think so, export a part of your registry and look into the saved file. I think you will see what I mean). Which is not what needed to be done ... Besides that, the description of where you create your file is missing. :-\ .... luckily I also read your next post before (fully) answering this one. So, I placed the "foo.txt" file in the root of C: And blimy! It worked ! But alas, it again no workie when I try to refer to a textfile file *not* on my C: drive (my C: drive holds my OS, I normally work on a different (but still local) drive) ... So, although your trick works in *some* circumstances, it certainly doesn't work in a general way. And I take it you've by now read my suggestion about using shortcuts ? I think that is an easier, more flexible (your target file does not need to be linked) and more maintainable solution. Regards, Rudy Wieser P.s. Why do you want to start items/go to folders using the "run" method to begin with ? I created a subfolder in my start menu, and placed shortcuts to all my personal quick-start and/or hard-to-reach stuff in there. -- Origional message: Tomos Davies schreef in berichtnieuws ... In , R.Wieser suggested: 3. Create an App Paths key (which must end in exe!). HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\foo.exe foo.exe=c:\folder1\folder2\foo.txt Problem: The above is not the same as what you posted in your initial message. I don't think there was ever an inconsistency but if there was, I apologize since I have been doing this ever since, oh, I think about Win95 days, so, it's pretty common stuff. You can open up any file you want just by doing this. For example, I edit the hosts file all the time this way. Did you place the "c:\folder1\folder2\foo.txt" data in the "(Default) dataitem, or did you create a dataitem with the name of the executable (would be a bit double-up, as its parent key also has that name, but you never know ..) I'm confused by your question as the "foo.exe" is only a technicality. There is no file named "foo.exe". The restriction that the App Paths key must end with exe is a Microsoft restriction. I only use that name because that's what works and that is what is documented to work since, oh, about Win95 days (maybe even earlier for all I know). It started working when they created the App Paths key, whenever that was. I already tried it before I replied to your first post, and have now done the same again. I still get the same error: "Windows cannot find ..." Yadayadayada. And yes, the same file opens in notepad when I double-click it (its bound to a program). I wrote better step by step instructions in another post. This is really old stuff, which came about when Windows shipped with a registry. So if it's not working for you, then I must have explained it wrong, because it has been working since Microsoft created the "app paths" key. Question: what happens when you do *not* enter those registry-keys for those "file.ppt" or "foo.txt" files and try to "run" them ? Do they still get opened ? Than those files might be on a/the default searchpath. In general, nothing happens if you don't create that key. There is a technicality, in that if the folder is open at the time you run the key, I seem to remember that it works in that case, but that's a special case. Also if you don't create the (could be empty) file in the first place, it doesn't work either. But since this method has been around for as long as Windows has had a registry, those are well known caveats I would think. So the question is simply how to make a "shortcut" to that command! Unanswerable, as I can't even replicate the behaviour you're seeing. I posted better suggestions. Here's another one, if you're interested. 1. Make a copy of your HOSTS file to "hosts.txt". 2. Create the registry key (for WinXP) of: App Paths key = myhosts.exe myhosts.exe = c:\windows]system32\drivers\etc\hosts.txt 3. Start Run myhostsreturn 4. That opens up the hosts file (in GVim for me) in your text editor. 5. For me, I can edit that hosts file & save it as "hosts". While I'm on WinXP, your hosts file path may be different if you're on a different Windows, and while I'm using GVIM as my registered text editor, your registered text editor may work differently. I've been using this for years to edit my hosts file easily. Here is what I do: A. I run: Start Run myhostsreturn B. I edit the hosts.txt file as I see fit & then type ":!whosts" C. That saves the edited hosts.text to HOSTS While this works, notice I have to have a copy of HOSTS named "hosts.txt", simply because I don't have HOSTS registered to open up in anything. I seem to remember, many years ago, I was able to type "Start Run hosts" and it edited the "HOSTS" file (sans extension); but I forgot in the interim how I managed that trick of bringing up any file that didn't have an extension in my default text editor (which as always been vim). |
#11
|
|||
|
|||
Why doesn't a folder work in HKLM SW MS W CV App Paths?
In , R.Wieser suggested:
So, although your trick works in *some* circumstances, it certainly doesn't work in a general way. The method I described has worked for me for so long I can't count the years. Maybe twenty years? (When did the App Paths key debut?) Anyway, there is one thing that you might be forgetting, which I never need because people *think* that Microsoft solved the long-file-name problem, but they didn't in all situations. So, *none* of my paths ever have more than 8 characters; which means, of course, that I *never* use anything with "My" in the name, nor anything with "Program Files" in the name, nor anything with spaces in the name, etc. But if I did, I'd just put doublequotes around the thing. Like they do he http://www.askvg.com/how-to-open-any...ox-in-windows/ Both the quotes and tilde are never needed by me; but if it's not working for you, maybe that's the problem you're seeing? I can't say what the problem is for your situation since this has been working for me for decades (note the plural there), so I doubt all of a sudden you "broke" something in Windows. Let me google a bit for you for instructions... https://www.google.com/search?q=app+...+open+any+file OK. This is the first hit, which explains the basics: http://www.techrepublic.com/article/...s-run-command/ Titled "Create application shortcuts". https://tr1.cbsistatic.com/hub/i/201...414shu02_A.gif But that hit didn't explain how to "open" any given file using the registered application (which is how I'm using it). Looking at the second hit, http://tweaks.com/windows/36684/crea...in-windows-xp/ Titled "Creating 'App Paths' in Windows XP" Where, they created "whatever.exe" to point to the Path. So, that hit used the App Path trick in a second way, but not the way I'm using it (to open a file). Looking at the rest of the hits..., most seem to be to open an "application", so, it would take me longer of a search to find the instructions for opening a file, but of course, you can open an application and call a file, which is essentially the same thing. |
#12
|
|||
|
|||
Why doesn't a folder work in HKLM SW MS W CV App Paths?
Tomos,
The method I described has worked for me for so long I can't count the years. Maybe twenty years? (When did the App Paths key debut?) I'm not sure what the above is referring to. A quote of what its aimed at would have been helpfull. And that the method has worked for you for near to 20 years ? It tells me that you probably never have tried to use it anywhere else than on your C: drive. In other words: you have not given yourself the chance to run into its limitations ... Anyway, there is one thing that you might be forgetting, which I never need because people *think* that Microsoft solved the long-file-name problem, but they didn't in all situations. Situations such as ...? (inquisitive minds want to know) So, *none* of my paths ever have more than 8 characters; which means, of course, that I *never* use anything with "My" in the name, nor anything with "Program Files" in the name, nor anything with spaces in the name, etc. Thats one way to make sure you do not need to encompass a path withing double-quotes I guess. :-) But if I did, I'd just put doublequotes around the thing. Yep, thats what I said. But that hit didn't explain how to "open" any given file using the registered application (which is how I'm using it). Again, I don't think you actually tried to do what I suggested. Why ? And your over-complicating things: Double-clicking on a document link works the same as double-clicking the document itself. No extra steps need to be taken, no extra settings need to be applied. So, just rightclick-and-hold the registered document, drag it to a new location, release the button and select "make shortcut". Thats al there is to it. And in your case I would suggest to select a folder thats on your searchpath, so you can also see if you can "run" the document by entering the shortcuts name (with, or without its extension). Both the quotes and tilde are never needed by me; but if it's not working for you, maybe that's the problem you're seeing? I'm not sure what you mean here. Which quotes and which tilde ? And as for tilde, *this* "~" is a tilde. *this* "@" is commonly refered to as the "at sign" (think email adresses), but its official name is "asperant". Also, in your (XPs) registry-editor you will most likely see "(Default)" instead of (the old) "@". As for the rest ? I already said that it works for me. But definitily not on my non-C: drive. Try it yourself. It it works for you we can try to figure out what than the difference between your and my system is. If you do (or can) not than there is nothing to discuss in that direction. Regards, Rudy Wieser -- Origional message: Tomos Davies schreef in berichtnieuws ... In , R.Wieser suggested: So, although your trick works in *some* circumstances, it certainly doesn't work in a general way. The method I described has worked for me for so long I can't count the years. Maybe twenty years? (When did the App Paths key debut?) Anyway, there is one thing that you might be forgetting, which I never need because people *think* that Microsoft solved the long-file-name problem, but they didn't in all situations. So, *none* of my paths ever have more than 8 characters; which means, of course, that I *never* use anything with "My" in the name, nor anything with "Program Files" in the name, nor anything with spaces in the name, etc. But if I did, I'd just put doublequotes around the thing. Like they do he http://www.askvg.com/how-to-open-any...e-in-run-dialo g-box-in-windows/ Both the quotes and tilde are never needed by me; but if it's not working for you, maybe that's the problem you're seeing? I can't say what the problem is for your situation since this has been working for me for decades (note the plural there), so I doubt all of a sudden you "broke" something in Windows. Let me google a bit for you for instructions... https://www.google.com/search?q=app+...+open+any+file OK. This is the first hit, which explains the basics: http://www.techrepublic.com/article/...on-shortcuts-f or-the-windows-run-command/ Titled "Create application shortcuts". https://tr1.cbsistatic.com/hub/i/201...-940f-14feb5cc 3d2a/t01220030414shu02_A.gif But that hit didn't explain how to "open" any given file using the registered application (which is how I'm using it). Looking at the second hit, http://tweaks.com/windows/36684/crea...in-windows-xp/ Titled "Creating 'App Paths' in Windows XP" Where, they created "whatever.exe" to point to the Path. So, that hit used the App Path trick in a second way, but not the way I'm using it (to open a file). Looking at the rest of the hits..., most seem to be to open an "application", so, it would take me longer of a search to find the instructions for opening a file, but of course, you can open an application and call a file, which is essentially the same thing. |
Thread Tools | |
Display Modes | |
|
|