NANY 2021: MoveFileHere

[Nod5]

Application Name	MoveFileHere
Version	2022-01-09
Short Description	AutoHotkey tool to quickly move newest file from Downloads to the active File Explorer folder in Windows 10.
Supported OSes	Windows 10
Web Page	https://github.com/nod5/MoveFileHere
Download Link	Standalone EXE file  https://github.com/n...oveFileHere/releases AHK source file   https://github.com/n...ain/MoveFileHere.ahk

Description
A very small hotkey tool that I use all the time, now released for NANY in case other people also often move files soon after downloading them and find the sequence Right click, Click "Show in folder", Ctrl+X, Alt+Tab Tab Tab, Ctrl+V way too long . With MoveFileHere you press F7 to move the latest downloaded file to the active Explorer folder. The hotkey and folder can be changed in settings. Copy and rename MoveFileHere.exe to e.g. MoveFileHere2.exe to set up multiple hotkeys and folders.
See GitHub README for more details.

Note: antivirus tools may incorrectly flag the AutoHotkey compiled .exe file. You can always install AutoHotkey and then compile MoveFileHere yourself from the .ahk source file or simply run the .ahk source directly.

MoveFileHere helps a workflow where we make the browser always download to a fixed Downloads folder and then quickly move the file elsewhere afterwards. Compare that to the workflow of quickly picking a custom download/save folder for each download using Listary or the small SaveAsPathHelper script I quickly made to mimic some Listary features.

After pressing F7 the user accepts the move with Enter, Space or Left Click. To instead cancel the move press Esc, F7 again or wait 2 seconds.

[tomos]

Looking forward to trying this one



EDIT// okay, needs Windows 10 -- will have to wait till later in the week

[anandcoral]

MoveFileHere helps a workflow where we make the browser always download to a fixed Downloads folder and then quickly move the file elsewhere afterwards. Compare that to the workflow of quickly picking a custom download/save folder for each download using Listary or the small SaveAsPathHelper script I quickly made to mimic some Listary features.

-Nod5 (December 30, 2020, 10:09 AM)

Looks interesting 

Regards,

Anand

[tomos]

Trying the exe file in Windows 10.

Two things:

1) (minor) it doesnt recognise that the Download folder has been moved from it's default location (the new location is recognised correctly by File Explorer and Vivaldi). I edited the ini file to point to correct folder, so no real problem here

2) When I press F7, the name of the file to be moved shows as a tool tip type message (near the mouse pointer) but nothing is moved. If I click on the message I get this error:

---------------------------
MoveFileHere.exe
---------------------------
Error:  0x8000FFFF - Catastrophic failure

Specifically: hwnd

   Line#
--->   161: if (window.hwnd = vHwnd) 

Continue running the script?
---------------------------
Yes   No   
---------------------------

[Nod5]

Hi tomos, thanks for testing.

1) (minor) it doesnt recognise that the Download folder has been moved from it's default location (the new location is recognised correctly by File Explorer and Vivaldi). I edited the ini file to point to correct folder, so no real problem here

-tomos (January 16, 2021, 05:14 PM)

Yes, that's a design choice, to keep the code simple.

2) When I press F7, the name of the file to be moved shows as a tool tip type message (near the mouse pointer) but nothing is moved. If I click on the message I get this error:

-tomos (January 16, 2021, 05:14 PM)

After pressing F7 the user accepts the move with Enter, Space or Left Click. (To cancel Esc, F7 again or wait and it times out.) I documented that on GitHub, will add that to the first post here too.

The error you describe is a bug but I haven't found a way to reproduce it yet. It could be an issue with file permissions or Windows 10 security (partially) blocking the exe, hard to say.

If you have time to test more:

• Change the source folder location in the .ini again, to something other than the browser's download folder. Does moving files from that folder work?
• Try running the .ahk source file directly instead of the .exe (assuming you have AutoHotkey installed). Does that work?

[tomos]

^ Nod5 thanks for that info

The error you describe is a bug but I haven't found a way to reproduce it yet. It could be an issue with file permissions or Windows 10 security (partially) blocking the exe, hard to say.

-Nod5 (January 17, 2021, 10:31 AM)

it's a user account (there is no problem with elevating permissions though when necessary). Not sure what the security settings are. Will get back to it again in a couple of days time, and try a few variations and report back then.

[tomos]

I did get another chance -- I seem to get error messages no matter what I do:

1) With exe, pressing enter after F7 gets same error as above

2) with AHK file, pressing enter/spacebar/left-click after F7 gets:
---------------------------
MoveFileHere.ahk
---------------------------
Error:  0x8000FFFF - Catastrophic failure

Specifically: hwnd

   Line#
   216: Hotkey,Lbutton,hotkey_lbutton,vState
   217: Hotkey,Esc,hotkey_esc,vState
   218: }
   224: {
   225: vHwnd := WinActive("ahk_class CabinetWClass")
   226: if (vHwnd) 
   227: For window, in ComObjCreate("Shell.Application").Windows
--->   228: if (window.hwnd = vHwnd) 
   229: {
   230: path := window.Document.Folder.Self.Path
   232: Return,SubStr(path, 1, 2) = "::" ? "" : path
   233: }
   234: }
   244: {
   246: vHwnd := vHwnd ? vHwnd : WinExist("A")

Continue running the script?
---------------------------
Yes   No   
---------------------------

3) I get the same error using a different folder -- note it does find the folder and displays the correct file


Do you think is it to do with it being a user account? (UAC at "Default", which appears to be high). I can try it in the admin account, but not tonight ;-)

[Nod5]

I seem to get error messages no matter what I do

-tomos (January 17, 2021, 06:16 PM)

Ok, sorry that it isn't working. That error message points to the a step in the code that uses COM to loop over all open File Explorer windows. It seems to find a File Explorer window but crash when that window's handle is accessed. I don't know what is causing that error though, I'm not able to reproduce it on any PC I have tried. It is also a pretty commonly used method in AutoHotkey scripts and I haven't found similar errors reported in the AHK forums. Guessing: maybe related to Win 10 security permissions settings or a conflict with some other app or script that is running on your computer but not on mine. If you have another Win 10 computer at hand you could try it there, to help narrow down the issue.

[meoow]

I can confirm that I too had the exactly same issue, when accessing hwnd, the program would crash.

[Nod5]

I can confirm that I too had the exactly same issue, when accessing hwnd, the program would crash.

-meoow (July 18, 2021, 02:49 AM)

I seem to get error messages no matter what I do

-tomos (January 17, 2021, 06:16 PM)

I have still not been able to reproduce the crash so cannot yet explain what the root cause is. Here is a test .ahk version (requires AutoHotkey installed) with an attempted workaround. Can you test it and tell me if the error still happens?

https://github.com/n...721/MoveFileHere.ahk

[tomos]

I seem to get error messages no matter what I do

-tomos (January 17, 2021, 06:16 PM)

I have still not been able to reproduce the crash so cannot yet explain what the root cause is. Here is a test .ahk version (requires AutoHotkey installed) with an attempted workaround. Can you test it and tell me if the error still happens?

https://github.com/n...721/MoveFileHere.ahk

-Nod5 (July 21, 2021, 02:55 AM)

I'm (very) embarrassed about the lateness of this response, but this works a treat -- thank you very much   

[Nod5]

I'm (very) embarrassed about the lateness of this response, but this works a treat -- thank you very much   

-tomos (January 08, 2022, 04:12 AM)

No worries, thanks for testing the fix. I updated the main GitHub release with it now.