Windows 11 File Explorer get the current selected filepath script not working Topic is solved

[Gary-Atlan82]

I found this script that is meant to get the current directory open in File explorer and also get the currently selected files full path.

The script was shared by MancioDellaVega in the thread Get current explorer window path. The version he shared throws a catastrophic error, svArtist whom was having the same issue posted a modified version of it, which he confirmed was working for him:

Code: Select all

GetExplorerPath(hwnd=0){
	if(hwnd==0){
		explorerHwnd := WinActive("ahk_class CabinetWClass")
		if(explorerHwnd==0)
			explorerHwnd := WinExist("ahk_class CabinetWClass")
	}
	else
		explorerHwnd := WinExist("ahk_class CabinetWClass ahk_id " . hwnd)
	
	if (explorerHwnd){
		for window in ComObjCreate("Shell.Application").Windows{
			try{
				if (window && window.hwnd && window.hwnd==explorerHwnd)
					return window.Document.Folder.Self.Path
			}
		}
	}
	return false
}

I tried it but I only ever get the path that is open in the file explorer window and not the selected files path:

Code: Select all

space::
MsgBox,% GetExplorerPath(WinExist("a")

I am on windows 11, so the new file explorer could be the issue. Does anyone know of a working script for getting the selected files path in windows 11? And what could be wrong with this script?

Any help would be greatly appreciated!

[mikeyww]

Addressed here: viewtopic.php?p=509080#p509080

[Gary-Atlan82]

@mikeyww

Hey thanks for the promop reply, the post you linked to seems to be V2 code. I am on V1 sadly. I followed the link you shared that attributed the code to teadrinker, so I tried his code in his post but I came across the same "catastrophic" error

I dont know any V2 and my V1 skillset is not up to par, so embarking on porting is out of the question unfortunetly.

[mikeyww]

Code: Select all

#Requires AutoHotkey v1.1.33

#If WinActive("ahk_class CabinetWClass ahk_exe explorer.exe")
F3::MsgBox % getSelected()
#If

getSelected() {
 ; Adapted from teadrinker
 ; https://www.autohotkey.com/boards/viewtopic.php?style=17&t=60403#p255256
 hwnd := WinExist("A"), selection := ""
 WinGetClass, class
 If (class ~= "(Cabinet|Explore)WClass")
  For window in ComObjCreate("Shell.Application").Windows {
   Try window.hwnd
   Catch
    Return
   If (window.hwnd = hwnd)
    For item in window.document.SelectedItems
     selection .= item.Path "`n"
  }
 Return Trim(selection, "`n")
}

[Gary-Atlan82]

@mikeyww
Thanks for that, really appreciate it. Having tried it, I just get an empty message box now.

Hmm.. I dont think this approach works with Windows 11 explorer.

You have already helped me so much, I think I will adjourn this affair here and ask around for an alternative in a few days. Cheers!

[mikeyww]

The script that I posted does work here. Good luck in any case.

[JoeWinograd]

Hi Gary,
Jumping in here quickly to let you know that the code mikey posted works here, too (in both W10 and W11). Did you change the code in any way? If so, post it. If not, maybe F3 is getting intercepted by some other program. Try a different/unusual hotkey, maybe !^F3. Also, make sure that File Explorer is the active window (with files selected) when you hit the hotkey. Regards, Joe

[mikeyww]

Good points, and thank you for testing, Joe.

[JoeWinograd]

You're welcome, mikey. I always have great confidence in code from you and teadrinker.

[JoeWinograd]

This thread reminded me of a similar function from sinkfaze that I put in my bag-of-tricks a few years ago:

Code: Select all

GetSelectedFile(hwnd="") {
; this function by sinkfaze: https://www.autohotkey.com/boards/viewtopic.php?f=6&t=77#p395
  WinGet, process, processName, % "ahk_id" hwnd := hwnd? hwnd:WinExist("A")
  WinGetClass class, ahk_id %hwnd%
  if  (process = "explorer.exe")
    if  (class ~= "Progman|WorkerW") {
      ControlGet, files, List, Selected Col1, SysListView321, ahk_class %class%
      Loop, Parse, files, `n, `r
        ToReturn .= A_Desktop "\" A_LoopField "`n"
    }
    else  if (class ~= "(Cabinet|Explore)WClass") {
      for window in ComObjCreate("Shell.Application").Windows
        if  (window.hwnd==hwnd)
          sel :=  window.Document.SelectedItems
      for item in sel
        ToReturn .= item.path "`n"
    }
    return  Trim(ToReturn,"`n")
}

Tested on W10 and W11...works fine. Regards, Joe

[Gary-Atlan82]

@mikeyww
@JoeWinograd

Thanks for confirming that these functions do indeed work with windows 11. Its good to know its just on my end.

Thanks for the alternative solution Joe! I tried it and it looks like I am getting the same issue, the selected file is never found.

The console reports that toReturn never has a value in it:


I am on windows 11 22H2 (OS build 22621.2134). Damn it Microsoft!

[mikeyww]

Explorer.exe alone can have multiple matches. You would typically want to refer to the window class in referring to File Explorer.

Are you running either program as admin or with elevated privileges?

Did you test the exact script that I posted, with no changes?

[JoeWinograd]

I tried it and it looks like I am getting the same issue, the selected file is never found.

If you used the exact code that mikey and/or I posted, my guess is that your call to the function is bad. Screenshots are great, but it would be really helpful if you post the whole script that you're using.

Damn it Microsoft!

I doubt that this is a Microsoft issue. It's certainly possible, but far more likely, imo, that your code (not Windows and not the mikey/teadrinker or sinkfaze code) is the culprit.

After writing the above, I saw mikey's excellent comment...he is spot-on! Your WinExist("ahk_exe explorer.exe") call is catching some other process, not the File Explorer one. For example, explorer.exe shows up as the executable with the Class as Shell_TrayWnd.

This will prove the issue: Change your winID:=WinExist("ahk_exe explorer.exe") statement to WinGet,winID,ID,A. Regards, Joe

[Gary-Atlan82]

@mikeyww
Yes I tested your script with no changes to it, by running it directly (double click in File explorer) I had to anyways, since the active window was hard coded to be explorer. None of the involved processes were elevated either.

>Explorer.exe alone can have multiple matches. You would typically want to refer to the window class in referring to File Explorer.

Ahhhh! that was it...I can confirm that indeed I was targeting the wrong explorer process. When a chose a more specific window title to get the window ID it worked:




But I am plagued by this "catastrophic failure" issue anyways. As you can see in the above console output there are a lot of errors output before the file paths are returned. Running the script within VsCode, makes it possible to at least get selected file paths.

Running the script directly by printing the file path on a message box, I get a lot of errors that I have to "ok" before I finally get the path:


@JoeWinograd

>If you used the exact code that mikey and/or I posted, my guess is that your call to the function is bad

Yes I used both functions exactly as provided with no changes to them, I merely changed how they were being called by opting to print the output to the VsCode console rather than a message box, but I recorded the above gif to also demonstrate the issue with a message box.

>I doubt that this is a Microsoft issue. It's certainly possible, but far more likely, imo, that your code (not Windows and not the mikey/teadrinker or sinkfaze code) is the culprit.

I am woefully out of my depth here, its of some comfort to me to add to the false accusations laid bare at Microsoft but I figured it out eventually thanks to you and mikey. Much appreciated.

[mikeyww]

Glad you figured it out. My advice for future posts is to post non-working scripts if you want forum readers to examine & test them. The screenshots are helpful but not a replacement for a script. If you just want to show an error message, use an image rather than a video (just my suggestion). Video is good if you want to show a sequence of events.

[JoeWinograd]

But I am plagued by this "catastrophic failure" issue anyways.

Running the script directly by printing the file path on a message box, I get a lot of errors that I have to "ok" before I finally get the path...

Then there's something amiss on your system, because msgbox,% GetSelectedFile() works perfectly here every time I've run it...never gets a "Catastrophic failure"...or any error! I'm confident that the problem is somewhere in your code or environment...not in W11/22H2, AutoHotkey v1, the sinkfaze function, or the teadrinker/mikeyww function. Regards, Joe

[mikeyww]

Good points, Joe.

At least for the script that that I posted, Gary-Atlan82, you can imagine what the following lines will do.

Code: Select all

Try window.hwnd
Catch
 Return

Why are they there? Under what condition would the function execute the Return command? How could you determine whether the Catch statement is met?

I do not have every answer, but this post provides an approach to understanding more about what your script does.

More: Exception()

I think of Try as has having the following three possible purposes.

1. Ignore an error.
2. Do something different when an error occurs.
3. Help the user of the script to learn more about an error.

[Gary-Atlan82]

Well understood. I will get to the bottom of it then. Thank you guys!
Edit: Mikey I will keep your advice on screenshot vs code in mind as well, cheers!

[JoeWinograd]

Edit: Mikey I will keep your advice on screenshot vs code in mind as well, cheers!

Yes, very important, as I noted in a much earlier comment that you must have missed:

"Screenshots are great, but it would be really helpful if you post the whole script that you're using."

Regards, Joe