"My specific application at the moment is to produce a button which load cmd.exe with the current path set to the same path currently in the address window." If you would be satisfied with a 'Shortcut' instead of a 'Button', it can probably be done with a simple batch program. Try the Programming forum. Do yourself a favor BACKUP!

0

I will try the programming forum. Thanks for the suggestion. I'm not sure how I would get a shortcut "onto" or "into" Explorer, if you get my meaning. I could create a batch file in every folder I could conceivably be interested in opening a command window in. But if I were to go with that brute-force of an approach it would be just as easy to drop a copy of cmd.exe in every one of those folders, then launching each individual cmd.exe from it's own particular folder would open it with the desired path. If you have some other idea for clicking on a shortcut (presumably onthe desktop?) that would somehow know what the current folder listed in the address bar of the Windows Explorer is I'd be very interested in your ideas. Thanks again, and I'll try over in the programming forum.

0

I think the hard part is determining the current folder that the system is pointing at. But I suspect that it can be found somewhere. Then it would be a piece of cake for a batch file or script to change to that folder and run cmd. You could put a shortcut to the batch file or script anywhere you like. Do yourself a favor BACKUP!

0

I think there's a flaw in your logic, though. "Current folder that the system is currently pointing at," is, I don't think, a well defined entity in the implementation your envisioning. Let's say, for instance, that I have two explorer windows open. I double-click my shortcut, which happens to be on the desktop, and it launches a command prompt with the path set to the current path in Windows Explorer. But which one? I can't simply go looking through the task list to find the first copy of WE and query its address/current path property. I would, presumably, be wrong 50% of the time. And worse when I had more than 2 copies of WE running. If we make the logical assumption that the last WE which had focus is the one with the path of interest, that's fine, but it no longer has focus when I double-click the short-cut to the batch file, so I can't query the address/current path property of the appropriate WE unless there is an "app which most recently lost focus" property somewhere. I don't think there is. This is why I'm convinced the solution has to be intimately connected to WE itself. Interestingly, I did find two related solutions on CodeProject. http://www.codeproject.com/csharp/c... This is a fairly complicated add-on written in C# which actually attaches a cmd.exe window directly to the WE window. That's massive overkill for what I want to do (and doesn't leave me the flexibility of designing other buttons to do other things, as I'd like) but one might glean the information needed to do relatively simpler tasks like I'm interested in. http://www.codeproject.com/shell/co... This *ALMOST* does exactly what I'd like it to do, but not quite. It does have the added bonus that it is accomplished simply by adding a couple of keys to the registry. In a nutshell, one can navigate the file structure in a WE window. When one finds the directory they'd like to open a command prompt in they need simply right click on a *folder* and the "Command Prompt" option in the drop-down window will open cmd.exe in the *parent* folder. For instance, let's say that you are in c:\test and there is a sub-folder named \foo. Right-clicking on foo will bring drop down a menu and clicking on "Command Prompt" will load a command prompt window with the path set to c:\test. Why is this not a fully satisfying solution? If you didn't have any subfolders in c:\test then there would be nothing in the contents pane to right-click on. So, for instance, if you had a list of files in there (and those are the files you wanted to get at via the command prompt) you could not get the "Command Prompt" option to appear by right-clicking on them since they are not folders. So you, at best, would have to navigate up to c:\, right click on its subfolder \test, and open a command prompt with the path set to c:\. This is quite a bit better than having the command prompt open in c:\documents and setting\etc., but still doesn't solve the problem. I've tried to adapt the solution provided for folder/shell options to work for files as well, but so far unsuccessfully. Hope somebody found that useful. I reposted the original question over on the programming forum, but things move MUCH more slowly there!

0

A sort of solution. To add the ability to right click on a *folder* and have a command prompt open in that folder's *parent* directory the two following modifications to the registry must be made: Add a key to HKEY_CLASSES_ROOT\Folder\shell named CmdPrompt and set its value to "Command Prompt" (without the quotes) Add a second key to CmdPrompt named command and set its value to "c:\winnt\system32\cmd.exe" (with the quotes, substituting the appropriate windows directory as necessary). I assumed that adding the same two keys in the same way to HKEY_CLASSES_ROOT\File\shell would result in the same behavior. Unfortunately, there is a subletly of the registry I'm not quite grasping. I thought that "file" was the generic file key. If one looks at the registry in more detail one can see that there are also registry entries for all of the "known file types." So, for instance, there is a txtfile for text files. Interestingly, if I add the two keys as specified to the txtfile key, then this works PERFECTLY. By which I mean: If I am in WE, my current directory is c:\test and I have a file named myTestFile.txt in that directory, then right clicking on myTestFile.txt will drop down a menu that has a "Command Prompt" option and selecting this opens a command prompt with c:\test as the default directory. This is useful becuase I am now in the directory with the file I was interested in. In theory, one could add the two keys to every known file type that one is interested in having this functionality for. It's a little cumbersome, but it is exactly a solution to the problem I posed - though one would have to further edit the registry as one decided new files types would benefit from this functionality. The most frustrating thing is that it would seem this should work for all files by adding the key to File\shell. If anybody has any ideas, please send them my way. This, of course, doesn't not solve the slightly larger problem of being able to do more complicated tasks that could be enabled with buttoned solution, so please let me know if anybody has any ideas along those lines.

0

You're right, having multiple Explorer windows open, complicates things quite a bit. Good luck with your project. Do yourself a favor BACKUP!

0

Thanks. I figured out the last bit, but am still hoping someone can give me some useful information regarding buttons because not all requirements will lend themselves to this easy of a solution. This actually will get you the appropriate ability to open a command window by clicking on either a file or folder in a subdirectory in WE. In the registry entry HKEY_CLASSES_ROOT\* add a key named shell. To this key add a key named CmdPrompt and set its value to "Command Prompt" (without the quotes). To this key add a key named command and set its value to "c:\winnt\system32\cmd.exe" (with the quotes, substituting the appropriate path for winnt depending on where you have windows installed).

0