Jump to content

Recommended Posts

Posted (edited)

I am trying to pass multi-file selections from Windows Explorer into the $CmdLine argument parameters array. For example, and these are not the literal program/project names, I can pass three full path file names via both Window's Run dialog and Terminal into the $CmdLine array, i.e, "c:\Dir\Program.exe" "D:\Test\file1.txt" "D:\Test\file2.txt" "D:\Test\file3.txt". When checked in the running program, $CmdLine index [1] has the correct value of 3, index [1] is correct with "D:\Test\file1.txt", index [2] with "D:\Test\file2.txt" and index [3] with "D:\Test\file3.txt". I get the same correct results in $CmdLine array when I start Program.exe with the same three file parameters using the Windows Terminal.

Also, I have added a HKEY_CLASSES_ROOT\*\shell\command key to the Window's registry. The registry entry is with a "C:\Program.exe" "%1" "$2" "%3" string value to allow for renaming file(s) from Windows Explorer via the right-click menu. With just one parameter placeholder, "%1" in the string value, a selected file will appear in $CmdLine. $CmdLine[0] is 1 and $Cmdline[1] contains the selected full path file name. Unfortunately, when I change the registry string value to include two more passing arguments, "%2" "%3", $CmdLine[0] =3 (as it should since three file path names are passed to Program.exe), $CmdLine[1] contains "D:\Test\file1.txt", but $CmdLine[2] and [3] are just empty strings.

It appears to me that Windows is not passing the second and third ("%2" and "%3") selected file's to Autoit, but just the first parameter "%1".

Is there some way that I can select more than one file in Window's Explorer and pass the full file paths into the $CmdLine array?

I know that AutoIt has the _WinAPI_GetOpenFileName function, but I would like to select files directly from Windows Explorer to bring into $CmdLine.

File Renaming Application 1.4.0.3.au3 Reg Key.reg

Edited by prizm1
Posted

Hey,

Until someone comes up with a real solution, as a workaround what if you just pass one parameter %1 which holds all files with a placeholder char in between file names? Something you wouldn't expect (not allowed) in a filename and would be ok to pass. Then stringsplit and use as you wish.

 

Posted
1 hour ago, GokAy said:

Until someone comes up with a real solution, as a workaround what if you just pass one parameter %1 which holds all files with a placeholder char in between file names? 

He’s not doing the passing - he wants to multi-select a bunch of files in windows explorer and have it run his program with the selected files as arguments, but apparently he’s only seeing the first one.

Code hard, but don’t hard code...

Posted

Just place your app or shortcut to your app into %AppData%\Microsoft\Windows\SendTo

Right click file(s) and SendTo app

Example compile the following to SendTo path as CmdLines.exe

Right click file(s) » Send to » CmdLines.exe, it should display a list of all the files.

#include <Array.au3>
_ArrayDisplay($CmdLine)

 

Posted
1 hour ago, Subz said:

Just place your app or shortcut to your app into %AppData%\Microsoft\Windows\SendTo

Right click file(s) and SendTo app

Example compile the following to SendTo path as CmdLines.exe

Right click file(s) » Send to » CmdLines.exe, it should display a list of all the files.

#include <Array.au3>
_ArrayDisplay($CmdLine)

 

Interesting as a work-around, Subz. Thanks. All three files in my test run seems to make it to $CmdLine via the SendTo approach. I don't know why the Window's registry approach passes only the first placeholder file path argument although $CmdLine[3] contains the correct number of placeholder arguments passed. I can run the identical string arguments via Window's Terminal and the Run command app with success. There must be some additional registry syntax required in addition to simply listing the placeholders after the compiled executable, ex., "C:\Dir\Program.exe" "%1" "%2" "%3". I would prefer the registry approach, though, if I could find a solution. It is a cleaner looking end-user approach to using the program.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...