The easy way out is to just answer the question: What is the current Explorer window looking at?


A customer had the following question:

We have an application which copies and pastes files. Our problem is that we want to paste the files into the folder which corresponds to the currently active Windows Explorer window. Right now, we’re using SendKeys.SendWait("^(v)"), but we find this method unsatisfactory because we want to replace Explorer’s default file copy engine with our own custom one. Can you provide assistance?

(And commenter wtroost had no clue why somebody would copy a file by sending window messages to Explorer. Well here you have it.)

The easy way out is to answer the question: You can enumerate the active Explorer windows and ask each one what folder it is viewing. There’s even a script interface for it.

The hard way out is to understand the customer’s problem and see if there’s a better solution. The question as phrased suggests that the customer hasn’t thought through the entire problem. What if the current window is not an Explorer window, or if it’s a window on a virtual folder instead of a file system folder (for example, an FTP site)? Simulating keyboard input (in this case, fake-pressing Ctrl+V) is rarely a good solution to a problem; after all, what if the hotkey for Paste changes based on the user’s preferred language? Or what if the Explorer window happens to be in a state where Ctrl+V doesn’t paste files into the current folder? (For example, focus might be on the Address Bar.) And the fact that they put contents onto the clipboard means that they are overwriting the previous contents of the clipboard.

I asked for a little more information about what their application is trying to do.

This is a file transfer application for computers which are not directly connected to each other, but which are both connected to a common third computer. From the first computer, you run the file transfer application, select some files from the transfer application’s interface, and hit Copy. This transfers the files to the common third computer. Then from the second computer, you run the file transfer application and hit Paste, and the program retrieves the files from the common third computer and places them in the folder that you are currently viewing in Windows Explorer.

Oh, the whole “get the path to the folder that Windows Explorer is viewing” is just a strange way of telling the program where to copy the files. In other words, they were using Windows Explorer as a very expensive cross-process replacement for the SHBrowseForFolder function.

The recommendation therefore came in two parts:

  1. Instead of hijacking Explorer as a directory-picker, just call SHBrowseForFolder. You can pass the BIF_RETURNONLYFSDIRS flag, and SHBrowseForFolder will automatically filter out anything that is not a file system folder, thereby saving you the trouble of filtering them out yourself.
  2. If you really want to hijack Explorer as a directory-picker, then add a context menu command to Directory or Directory\Background called Paste from Transfer Shelf (or whatever your application calls that intermediate computer).
Comments (17)
  1. configurator says:

    SHBrowseForFolder is a horrible interface though; Explorer is convenient. The context menu suggestion is much better.

  2. Kythyria says:

    Merely seeing the title was enough to make me think "Here comes another story of a program that does something in an unnecessarily strange and overcomplicated way".

    I can easily imagine that the logic for using Explorer as a directory picker is that the user only has to navigate to the directory once in total, rather than once in the application's directory picker and again in Explorer to do something with the files. From that perspective, it makes a weird kind of sense, but not as much as, yes, adding a context menu entry.

    And I have to say, configurator is right: SHBrowseForFolder is kinda annoying. If it has the same scrolling glitch in Win7 that Explorer's folder list does, that would make it even more annoying.

  3. Ivo says:

    [configurator – SHBrowseForFolder is a horrible interface though]

    Fully agree. If you are targeting Vista+, please please please use IFileOpenDialog with FOS_PICKFOLDERS.

    On older OSes there are ways to use GetOpenFileName to pick a folder (I've seen 3DS MAX do it more than 10 years ago). It is not very easy, but definitely possible.

  4. gui sux says:

    Any sane program doesn't use SHBrowseForFolder because the dialog is evil. Choosing folders with GetOpenFileName is better, then the user have access to the left pane with desktop/computer/documents/…

  5. Me says:

    I know this is impossible but each time I read one of your customer stories I think you should just tell them to get lost.

    Seriously, simulating keypresses in another process is far worse than most of the stuff on TDWTF. These people should just stop developing software.

  6. Nick says:

    I admit, the SendKeys call was surprising (and not in a good way).  If there is some common computer with a staging directory for file transfers, why not just use CopyFile/MoveFile or something fancier but along the same lines.

    I realize the main question was getting the current Explorer view, but once you have it, why not use the path in a more sane way?

  7. Marquess says:

    *googling*

    Hmm, this DirectoryBackground is pretty cool. Hadn't heard about that one before.

  8. Josh Smeaton says:

    @Me after only a short time working in this wonderful industry of ours, I've learnt to accept that there are MANY horrible developers. I include myself in that category every now and then. There are three major reasons horrible programs are written (that I can fathom on a whim):

    1. "Get Dave from accounting some training in Visual Basic so he can make his own accounting application. We aren't paying $200/h to outsource something so easy!"
    2. "Ahh! I can't find documentation on how to achieve the outcome I'm after. Let me browse the source and find a way to do it".

    3. "Meh whatever, lunch is in 10 let's go!"

    I used to hate Dave. Now I hate companies that force Dave into doing something he doesn't have the skills to do, to save a few thousand dollars in CapEx to sacrifice a much larger amount in maintenance in the long term.

    I'm guilty of 2, though sites like stackoverflow are significantly reducing my need to jump into source unless I'm interested in the code.

    All 3's should be identified and shot on site.

    Raymond, I really appreciate how you provide answers to Customer's questions AND answers to the actual problem they are having. I don't know many people like that unfortunately. The Easy Way leads to the dark-side!

  9. Josh Smeaton says:

    Clarification:

    1. Was supposed to be a reference to using undocumented APIs and internal data structures. I realise that reading the source can be a very good way to program in some cases.
  10. Brian K says:

    Raymond, after reading these stories from time to time, I just want to know – How do you ask Microsoft a question like this?

  11. Gabe says:

    Is it me, or does this just scream "drag and drop"? That's what I would have told them to do. Then a user could simply drag something from their custom app to wherever they want it to go (most likely the currently open Explorer window).

    I do sympathize with them not wanting to use the ridiculously bad folder browsing dialog. One of my pet peeves is that you cannot drag something from an already-open Explorer window into a common file dialog.

  12. Worf says:

    Heck, why drag and drop? Shell extensions!

    This guy's app isn't, and it can simulate a virtual folder of the third PC's dropbox. User does everything in Explorer. To move files, you just drag/drop, copy/paste, etc. the file to the virtual folder, which copies the file to the third PC. The destination browses the virtual folder, and copy/pastes.

    Of course, no one tell this company that Microsoft did it as "File Sharing"…

  13. Steve says:

    You can ask questions like these all day long simply by calling Microsoft Developer Support. I have seen much crazier things come through there than this, which is why it's always important to ask "What are you trying to accomplish?" rather than simply answering the question as presented.

  14. Steve says:

    Oh, and here is how you reach them: msdn.microsoft.com/…/aa570318.aspx

  15. Alex Cohn says:

    My collegues have recently delivered an application that does exactly this: it can copy a remote file to a folder that is opened in Explorer. Or to a context related to an open window of another application. The catch is that the remote file resides on a cameraphone, therefore the user only points to the desired destination with her camera. And yes, under the hood we use drag'n'drop, not Ctrl-V.

  16. Miral says:

    A very simple rule for developers to internalise: if you're using SendKeys (or its moral equivalents), then you're doing it wrong.  (With *maybe* a possible exception for user-initiated keyboard macro programs.)

  17. Leo Davidson says:

    I guess those who think anyone using SendKeys should retire from programming are not fans of Mark Russinovich and Process Monitor, or have never noticed what Process Monitor does when you ask it to jump to a registry key? :)

    Not that it excuses using SendKeys when there is a better alternative, like in Raymond's example, but it seems sometimes it's the only way to get certain things done when trying to get another program to do what you want.

Comments are closed.