PLEASE USING EXISTING EXPLORER!!! FOR gods SAKE

What IS wrong with just calling a "<DOWNLOAD FOLDER HERE>" to open the existing "EXPLORER.EXE" ?????

WHY must uTorrent launch ENDLESS copies of Windows Explorer EVERY SINGLE TIME I right click and "open folder".

It's NOT going to close them when I come out of uTorrent.

I know it's been discussed, but come on guys for gods sake sort it out.

You should NOT be launching individual / additional explorer shells. It does not work out properly with the Aero theme. I end up with a black bar on every copy of explorer launched from uTorrent (where the address bar is SUPPOSED to be transparent). It is transparent in every OTHER application that I can open folders from.

Apparently everyone else KNOWS how to open an additional folder in the existing explorer without opening a new copy of it.

<RUN COMMAND HERE> <FOLDER NAME HERE>

We do not have control over this. It is Windows itself spawning a new Explorer process. Even when doing open containing folder from Firefox, it'll spawn a new explorer.

That's incorrect Firon. As an example run a command prompt and type:

start "" "Any folder on your hard drive here"

ALTERNATIVELY

Dowwnload AutoIt3 and use the following script:

; Opens the folder My Downloads on my F drive

ShellExecute("F:\My Downloads")

You will notice that BOTH of those, DO NOT run any additional explorer processes.

If I can do it with AutoIt version 3, I can't see any reason why it's not possible with w/e your using.

Figure out how to perform file selection by ShellExecute without executing explorer.exe directly (/select parameter), and you might have a point.

Edit: To be fair, I don't think µTorrent actually itself calls explorer.exe directly -- it (AFAIK) makes some other system call that does the equivalent.

Why is that necessary? The option in uTorrent is "Open folder location" ?

When uTorrent currently opens the folder location, no items within the folder are selected anyway? So what it does already is a total fail. It just manages to launch another copy of explorer. At least this way people don't get multiple copies of explorer.exe running. (Although it DOES manage to open and select single file downloads... That not very useful. I'd much rather have to select files manually and have more memory thanks!).

My point still stands. (Not that any point needs to be made - I'm merely asking).

You should NOT be calling "explorer.exe" at all. The explorer shell is already running.

All you need to do is launch a folder location directly.

IE.

"C:\My Downloads"

The existing explorer.exe shell will handle the call.

You don't find it useful, but many other users find it useful. You care about extra explorer.exe instances opening up (which automatically close eventually anyway) when even fewer users care about that than those who care about the auto-selection. So tell me, are we supposed to just get rid of a well-established feature because you tell us you don't need it?

No, you don't need to repeat yourself -- not when you haven't actually responded to the contents of my post (only sidestepped it).

And as far as I can tell, if you're having a problem with Aero, then something's wrong on your end. "Open Containing Folder" is indistinguishable from any other regular Explorer window here, and the only way I'd notice it is if I were to check the running process list.

I didn't sidestep anything. The point was your calling an additional program when you shouldn't be. There was no reason to delve into the explorer API to call a ShellExecute.

If the contents of a torrent you have downloaded, are created within its own folder, your additional call to explorer.exe is pointless. It doesn't close on it's own. There is nothing wrong with my Aero, it does that because uTorrent is calling explorer.exe "out of process". Which is why it doesn't close even if uTorrent closes.

I personally think that uTorrent should do what it says its going to do when you right click on a torrent.

Open folder location.

End of.

Do it or don't.

But that wont fix the fact that your wrong.

In answer to the question that I apprently sidestepped:

http://www.west-wind.com/presentations/shellapi/shellapi.asp#ShellExecute

There was no reason to delve into the explorer API to call a ShellExecute.

So you're telling me that ShellExecute meets the requirement -- that it's able to open Explorer with the /select parameter (or some equivalent). Gotcha.

I don't care if you "think" it shouldn't select the file -- that isn't relevant to the debate at hand. The requirement is that it does, and if you can't meet that requirement, then your workaround isn't a suitable replacement. Flailing your arms and refusing to acknowledge that you don't understand this simple fact doesn't give you the right to call everyone else "wrong". So yes, you still are sidestepping the problem, because ShellExecute in and of itself doesn't satisfy the requirements. Thanks for assuming that we'd never heard of it though.

There is nothing wrong with my Aero, it does that because uTorrent is calling explorer.exe "out of process".

"Open Containing Folder" is indistinguishable from any other regular Explorer window here, and the only way I'd notice it is if I were to check the running process list.

Yes, the evidence is compelling.

OK, well looking into it further, the way your doing it, it should all be based on the explorer option: Launch folder windows in a seperate process.

Mine is not enabled (off).

So that leaves you calling the ShellExecute without the current desktops window handle. In other words.

Private Declare Function ShellExecute Lib "shell32.dll" Alias _

"ShellExecuteA" (ByVal hwnd As Long, ByVal lpszOp As _

String, ByVal lpszFile As String, ByVal lpszParams As String, _

ByVal lpszDir As String, ByVal FsShowCmd As Long) As Long

Private Declare Function GetDesktopWindow Lib "user32" () As Long

Function StartDoc(DocName As String) As Long

Dim Scr_hDC As Long

Scr_hDC = GetDesktopWindow()

StartDoc = ShellExecute(Scr_hDC, "Open", DocName, _

"", "C:\", SW_SHOWNORMAL)

End Function

Or something along those lines. Surely that way, it will use the existing explorer shell?

If your passing Scr_hDC as Null then it's just going to call a seperate process?

Been a LONG time since I programmed anything (VB6) so I wouldn't care to guess.

Look, I still think it should just open the folder. That's what it says it's going to do. It doesn't say "Open the folder and select all the files in it". I think most people would just want it to "go to the download location". Many times, the content which is downloaded in a torrent is mixed content. It's just not useful to have them all selected. It's not like you can right click on them all and do some kind of shared action most of the time. What are you going to do, right click and cut and paste the files somewhere else? Mmm... usefull.

Anyway. Your program. Just been looking around your forum. Looks like this has been requested many times before.

Nice to see you appreciate your users opinions and requests.

The use case scenario for why things are done as they currently are is rather simple: If the folder has a ton of files unrelated, this makes it easy to actually spot the file in question.

Nice to see you appreciate your users opinions and requests.

You don't find it useful, but many other users find it useful. You care about extra explorer.exe instances opening up (which automatically close eventually anyway) when even fewer users care about that than those who care about the auto-selection.

Yes, because I refuse to ignore one set of users over another set, I'm not respecting opinions. We've gotten more complaints from users when we broke the selection feature than when users find that multiple instances of explorer.exe are run. The fact of the matter is, the additional process being run shouldn't even matter. Windows already takes care of the process by automatically closing it after a timeout period anyway.

That isn't to say that the multi-instance issue is being ignored altogether. Just that it's currently, as far as we know, a necessary evil -- at least not without a suitable workaround.

Probably worth noting is the fact that I actually edited my post above sometime after to clarify that µTorrent isn't, AFAIK, actually executing explorer.exe directly, but that it's using some Windows API that does the equivalent. ShellExecute really isn't a part of the equation at all here. Once again, ShellExecute cannot handle selection. The "Open" verb doesn't do it, and none of the other ShellExecute verbs do/can either.

Alright, after looking through shell32.dll for useful function exports, I found SHOpenFolderAndSelectItems(). Decided to Google around, and found some sample usage code that I ported to AutoIt:

;======================================================================
Func _CoInitializeEx()
    Local $avResult = DllCall("ole32.dll", _
        "int", "CoInitializeEx" _
            , "ptr"   , 0 _
            , "dword" , 0 _
    )
    If @error Then _
        Return SetError(@error, @extended, 0)

    Return $avResult[0]
EndFunc

;======================================================================
Func _ILCreateFromPath($sPath)
    Local $avResult = DllCall("shell32.dll", _
        "ptr", "ILCreateFromPathW" _
            , "wstr" , $sPath _
    )
    If @error Then _
        Return SetError(@error, @extended, 0)

    Return $avResult[0]
EndFunc

;======================================================================
Func _ILFree($pItemList)
    DllCall("shell32.dll", _
        "void", "ILFree" _
            , "ptr" , $pItemList _
    )
EndFunc

;======================================================================
Func _SHOpenFolderAndSelectItems($pDir, $apSel = Default)
    Local $pSel = 0, $iSelCount = UBound($apSel)
    If $iSelCount > 0 Then
        Local $tSel = DllStructCreate("ptr[" & $iSelCount & "]")
        For $i = 0 To $iSelCount - 1
            DllStructSetData($tSel, 1, $apSel[$i], $i+1)
        Next
        $pSel = DllStructGetPtr($tSel)
    EndIf

    Local $avResult = DllCall("shell32.dll", _
        "int", "SHOpenFolderAndSelectItems" _
            , "ptr"   , $pDir _
            , "uint"  , $iSelCount _
            , "ptr"   , $pSel _
            , "dword" , 0 _
    )
    If @error Then _
        Return SetError(@error, @extended, 0)

    Return $avResult[0]
EndFunc

;======================================================================
Func _ExploreDirectory($sDir, $asSel = Default)
    Local $pDir = _ILCreateFromPath($sDir)

    Local $apSel = Default
    Local $iSelCount = UBound($asSel)
    If $iSelCount > 0 Then
        Local $apSel[$iSelCount]
        For $i = 0 To $iSelCount - 1
            $apSel[$i] = _ILCreateFromPath($asSel[$i])
        Next
    EndIf

    _CoInitializeEx()
    _SHOpenFolderAndSelectItems($pDir, $apSel)

    For $pItem In $apSel
        _ILFree($pItem)
    Next
    _ILFree($pDir)
EndFunc

;======================================================================
Func _Main()
    Local $sDir = "C:\"
    Local $asSel[1] = ["C:\Windows\"]

    _ExploreDirectory($sDir, $asSel)
EndFunc
_Main()

This actually seems to work well without running an extra instance of explorer.exe. Its only drawback is that it requires Windows XP and newer, but I guess Windows 2000 support could always be special-cased.

Edit: In the interest of organizing related threads, I'll also post a reminder for the devs that the things discussed in this thread are closely related with this request (and the thread I also linked in that thread).

I think what your talking about doing would require you hooking into the explorer API. (Spy++).

I'd probably use the "search" box on windows explorer as a start, search folder a file which I know exists in the folder I'm searching, then right click on the file and select "open file location".

Then I'd watch which processes were being called?

Anyway... I've failed.

But what uTorrent does ATM isn't right. (AND Firefox, if it does the same thing).

Nah, the sample code demonstrates that it's actually simple to implement (doesn't require windows hooks, etc.).

Sry Ultima didn't see your last post. I got busy inbetween writing my last comment and pressing the submit button, lol. It's outstanding that your looking into it though. Appreciated.

I'm going to end my part in the discussions on this with a kind thankyou, please accept my appologies for my earlier ignorance.

I really do hope it's possible. I use uTorrent a lot and for w/e reason, the black bar issue in explorer is very annoying.

Just to give you an idea what Explorer's Aero looks like for me when uTorrent launches an additional out of process copy of explorer.

Cheers guys and best of luck.

PS. This is Windows 7 64 bit. I get the proper Aero explorer if I launch explorer from explorer or from a command prompt or script or anywhere else (besides uTorrent and Firefox). If anyone knows why this happens, please let me know! lol. I have run sfc /scannow. It works fine and finds no issues. I don't employ any desktop hooking gizmos or software of any kind.

I think the topic got away from the real point: the existing explorer.exe process should be used. It should. There is no debate about that, am I right?

It's not a question of "should". But if you really want to make it so, then I submit that it shouldn't matter to the user how µTorrent opens the directory -- just that it does so without negatively impacting anything else. What µTorrent should (and already does) do is perform the requested operation and get out of the way. I have no explanation for the visual glitch MoRbIdBoY sees in Explorer, but I don't experience the problem myself here on Windows 7 x64, so I have no reason to believe his problem comes purely as a direct result of opening a new instance of Explorer.

Users worrying about an extra process running -- which Windows automatically terminates after a timeout period -- are being anal about something that they (quite frankly) need not concern themselves with. Next, they're going to be telling Windows how it should be managing its memory, or telling µTorrent developers what libraries they should use to develop the application.

Sure, there may be different ways of doing whatever it is that needs doing (as I already pointed out above), but that isn't really relevant to the question of "should".

The real problem is that Windows is 'tarded, but we should probably use the suggested method anyway. Still, it's -very- low priority, so I don't know if it'll happen.

Alright, after looking through shell32.dll for useful function exports, I found SHOpenFolderAndSelectItems(). Decided to Google around, and found some ...

My two cents also...

Ok the Open containing folder feature has never worked for me as expected on Win XP SP2 64bit, meaning if folder is not open, (1) open it, (2) then select the item else if already open go to action (2) directly and select the item.

For me: if the folder is already open it just brings forward the explorer window with the folder. It does not open another instance of explorer nor does it highlight the desired file.

Fortunately Google Chrome works as expected and i have searched all night to get the code

http://codesearch.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/chrome/browser/platform_util_win.cc&q=shellexecute&exact_package=chromium

So that's how it should be done using SHOpenFolderAndSelectItems() as stated above by Ultima.

Yep, the fact that Chrome behaved well was actually what prompted me to look more carefully for a solution in the first place. I was thinking of digging through the Chromium code too, but didn't feel like spending hours on it (as you did), so I just poked around where I expected shell code to live and got lucky