Sign in to follow this  
Followers 0

running autoit .exes with cmd/registry parameters

14 posts in this topic

#1 ·  Posted (edited)

How do you add extra commands like

Run test.exe -t 55

or from the registry

command, C:\test.exe %1 and how do you get the file path?

How do u get it all into the script? o.o

Is it like a function? lol, I'm soooo confused as how to do this. :)

I want it to be run from right-click context menus on ini files that opens up this program with the ini path....

I know the question sounds vague but it's even more confoggling in my head. x.X

I made it so all Ini files get a "Read" context menu, how do i click that then run this with their info, all I need is to input the path really. :\

Can AutoIt import that even? :s

#include <GuiConstants.au3>

$path =     ;How to get this via the command/registry? O.O
$GUI = GuiCreate("IniReader --- by Foy", 500, 400)
$body = FileRead($path)
GuiCtrlCreateEdit($body, 10, 30, 480, 300)

while 1
    $msg = GUIGetMsg()
        case $msg = $GUI_EVENT_CLOSE
Edited by Foy

Share this post

Link to post
Share on other sites

help. o.o

Share this post

Link to post
Share on other sites

It hasn't even been a half an hour already and your bumping?

Share this post

Link to post
Share on other sites

lol I just wanna quickly know if it's even possible.

Also can you freekin' post you microOS source? I wanna know how you did some stuff. =.=

Very rude of you not to, it's example scripts, if u got a good .exe post it on or something, this is fer learnin'!

Share this post

Link to post
Share on other sites

Besides... 30min vs 20min? is it so bad? -.-

Share this post

Link to post
Share on other sites

Search the AutoIt manual for $CmdLine.

As for the right-click, AutoIt can write to the registry, so just write in your command.

Registry commands are also fully documented in the AutoIt manual.

You have the manual, right?



nothing is foolproof to the sufficiently talented fool..

Share this post

Link to post
Share on other sites

Well I know that, didn't know $cmdLine, will search....

I know but i mean the program to run on right click, I'll have a stand-alone installer that makes the registry values, I'm just doing it manually for testing atm. xP

Share this post

Link to post
Share on other sites

in the registry i put

C:\ReadIni.exe %1

because the others had %1 on the end which i took to mean the current file's data, not just NORMAL notepad. xP

Share this post

Link to post
Share on other sites

what can i put to enter the path of the file? x.x

Share this post

Link to post
Share on other sites

This will help you, big-time.



nothing is foolproof to the sufficiently talented fool..

Share this post

Link to post
Share on other sites

He means to ask:

When you right click on a .au3 file, there is an option to "execute script", I assume he wants to create something the same as this, only register his .exe file as the program to start it with?

Share this post

Link to post
Share on other sites

Yup, we got that.



nothing is foolproof to the sufficiently talented fool..

Share this post

Link to post
Share on other sites

Aha, through much googling i *think* i got it working-ish lol....

in regedit...

"C:\ReadIni.exe" "%1" "%2" "%3" "%4" "%*"

under value "command"

under key ReadIni

under Inifile

Under HKCR

Yush... and

$path = $cmdLine[1]

I really don't know why.. but I don't care.

No where did I find something that said what the % paramaters meant so i started throwing them on then outputting results and tada. ;)

Now I just gotta spoof up what I do with the Ini file. ^^

Well thank you lol

especiall corz "Search the AutoIt manual for $CmdLine."



I know I was unclear but that's because I hardly knew what I was asking about. o.o

I still don't understand the answer, I just know it... lame lol. >.<

Share this post

Link to post
Share on other sites

#14 ·  Posted (edited)


The great value in learning how to ask the right questions, is in doing so, one very often comes up with the answers! Understanding those answers, is another story. What you are trying to achieve requires knowledge of not one, but two seemingly separate systems. First, the Windows command line..

When you launch an .exe in Windows, what you are actually doing, is running this command..

application.exe %*

which might look a tad cryptic, but simply means "Execute the application and send it %* (whatever text comes after the .exe). On Windows, the "%" character is a token used to expand variables of some kind, which is how you can access your system folder (in a registry command, or anywhere else) as "%SystemRoot%". If you enter %SystemRoot% into the address bar of one of your explorer windows, the system folder will appear. Try it.

If you look inside the default command (in the registry\HKEY_CLASSES_ROOT\) for, say, a text file, it might look something like this..

notepad.exe "%1"

Which means, "Launch Notepad.exe and send it "%1". %1 is automagically expanded to the full path of the item that was clicked; our text file). %1 then, is the item you click or right-click in explorer.

But the command for an .exe uses "%*", right? You may or may not know, but "*" is a "wildcard",one which simply means, "anything at all", so "*.ini" means "all ini files", "foo.*" means "all files named "foo.something", and so on.

%* expands to "all the text that comes after the application's name". There's no need to specify %1, %2, %3, etc., these are created automatically whenever you put a SPACE in the command line. For instance, if I launched an application like this..

MyApp.exe -foo -bar "C:\MyFolder\"

The application would immediately be fed these variables..

%0 = The path of the application itself (as always)
%1 = -foo
%2 = -bar
%3 = "C:\MyFolder\"

The reason we enclose paths with spaces in them inside quotes, it to prevent them being automagically presented as separate variables to the application that opens them, which is why most document's run commands enclose the variable in quotes, like this..

app.exe "%1"

Which ensures that the application receives a single variable "%1", e.g..

"C:\Program Files\Imaging Tools\basic colors.pal"

instead of multiple variables..

%1 = C:\Program
%2 = Files\Imaging
%3 = Tools\basic
%4 = colors.pal

Which clearly would present problems to an application that wasn't programmed to glue this lot back together. Almost everyone has seen a dialog along the lines of "Program blah blah cannot find file "C:\Program". This is why.

When you launch an AutoIt application, it internally discards the %0 (it's no longer needed), and replaces it with a useful variable; the total number of command line parameters. From there, it's by the book, with %1 = $CmdLine[1] being the first parameter, %2 = $CmdLine[2], the second parameter, and so on. By the way, you can always get the complete command line from $CmdLineRaw, which is basically the same as %* in the first example.

Here's a wee demo I threw together for someone else a while back (which I kept around because I plan to do an article about this stuff; I'm using this post to sketch notes; you lucky sod!) ..


    command-line parameters example, by (or ;o) ..

    use this following line to test things - setup your IDE to "Run with Selection" 
    which will save you a lot of time testing command-line parameters in any 
    application you may build..

        -foo -bar "c:\msdos.sys"

    The results will appear in your IDE's console output window.

    Alternatively, compile this wee app, and open a command prompt in its folder, 
    run it like this..

        app.exe blah blah "C:\path\to\file" > results

    A file called "results" will appear next to the application, with all the 
    console output inside. By the way, you can just drag things into a Windows 
    console window and their paths will be pasted automatically into place, which is 
    a lot faster than typing.


; init..
$param1 = ""
$param2 = ""
$file_name = ""

; command-line parameters..
if $CmdLine[0] then

    ; grab parameters (max two parameters in this example)
    if $CmdLine[0] >= 2 then 

        ; the first parameter..
        $param1 = $CmdLine[1]

        ; the LAST parameter..

        ; by placing this here, we ensure the applications receives at least one switch
        ; we also run an exists check to ensure they haven't sent *only* parameters..
        if FileExists($CmdLine[$CmdLine[0]]) then $file_name = $CmdLine[$CmdLine[0]]


    ; optional second parameter..
    if $CmdLine[0] >= 3 then $param2 = $CmdLine[2]


if $file_name <> "" then 
    ConsoleWrite("param1: " & "->" & $param1 & "<-" & @LF)  
    ConsoleWrite("param2: " & "->" & $param2 & "<-" & @LF)
    ConsoleWrite("file_name: " & "->" & $file_name & "<-" & @LF & @LF)
    ConsoleWrite("NO VALID FILE NAME SUPPLIED!!!" & @LF & @LF)

ConsoleWrite("Full command-line: " & $CmdLineRaw & @LF)
exitoÝ÷ Ù*-+¦bq«b¢w§vW®¦Ú-Â(f§vX§z«jg­z»-·ü¨º)Üç^¶W§jg©j»AºÚr«±ìç¶ÛazÇ©j¶¦z׫±g¢é]v­©îjYrÂ+a¶«ºw(f§vÜ­æ­y«!¢»ºÛh¶¦bq«b¢|"¶ayÊ+­ç-¥ªÚë^®Æ¥­æÊ)ìz»^uæ¬ÊÚ­æ­z)ÀºÚµ»­¶zËpk(¬¦ºi¹rÂ+ai×z{¢{^ÆÙç(f§u8^­æ«zZvÊÁ¬¬¶(ø º·²¢êݡ˦z{¢{^ÆÚâ'$iËb¢{ºÛa{&¥Ú²Ç§¶&¥+azƦzØb!jx²)©êÞ+-¯)ÊÀjÈ­è"²Úòz{kÉú+iÚºg§µÉZ²Éh¢K,¢g­)à)¶¬jëh×6; coool script

; this line will setup thje file extension, and points it to the "scpfile" file type section
"content type"="text/plain"

; and here's the "scpfile" section, first the name
@="cool script"

; (optional) default command for this file type - matches the sub-tree name, "edit_the_script"

; name (as it appears in your context menu)..
@="edit the script..."

; the actual command to perform (note quotes around the "%1")
@="c:\\windows\\notepad.exe \"%1\""

; a bogus extra command ("foo the script" will appear in the menu, as we didn't specify a name)
[hkey_classes_root\scpfile\shell\foo the script\command]
@="c:\\apps\foo.exe -fooit \"%1\""

; and finally, a cute icon for this file type..
@="c:\\toolbars\\icons\\landform.ico,0"oÝ÷ Øe¹ÉvØZµ©f¢ËZ¶¶§v®¨ê'(×±¶· ~)^°Z½æ¥l¡Ë¦z{mʬ±ën¦)ëz¬¶¼W¬©ÝË^)쵩exìJðéçjËrjeÆ­ì²×*.­ø¥y«,¡È¶*'±©Ýi×^u§ÞÂz-zÇè¯*."Ýý±ö¢®¬¶¶¢_¢¼­ÛazåÊØbajÝý±¦â¶ÚârL¢»azéðj¼¢±©e¶ªºt÷j®¢ÖÚrK%jÈ^³br«zȦ¦±Æ©yÈZ­§-z»&y©â
®¢ÛZëayÈZ­«z·b­ç-&µêí+(âÈLD@,¶*ºH*.ç¶n¶«¨µë(­¶ÉZ²¬)ì׿*.­Ê&©Ýʧyçm¡ëj­é»-Â+ai¶ÉZ²!Èb³rʬyæ¥Ø^væÚrK%jÈ^²)ÞÆ+µçkz¬¶¼W¬!÷è­ìZ^j·z-zÇ¥çjº^Á«-¡ªiyªâØ^)Þ­èv+p¢é]rì׫¶­¶Ú¶¢iܨºÇ:w¶nÞÉ®{h¶«z¬¶¼«mrX)à¢v§ÊÇ)~)^Â¥uºâ©¢êíÂ(f§vÌ"¶®¢×ÛazÇ+jºbº%vØ^uçÚº[¢iÔáz·­éh¶ÊÁ¬¬¶¶Øb²)ߢ¹¶*'{h¶«z¬¶¼°Ømå¢Ú0±ø¥zÜ©zÇbjZ o(¦¦íx­è"²Úò~)^¢¶òv*ÞrÚÞ+-¯)*n«b¢vòjv©¦Xjب­ jwhjYm·êÞßÛ!£hv­v*ÞrÙr"¢¶×¶¢¬{¦¦W¢iÖ®¶­sbb33c¶fÆUöWBÒgV÷C·67gV÷C°¢b33c¶fÆU÷GRÒgV÷C·67fÆRgV÷C°¢b33c¶÷FÒgV÷C¶3¢b3#·væF÷w2b3#¶æ÷FWBæWRgV÷C°¢b33c¶÷Vå÷7vF6W2ÒgV÷C²gV÷C° ¥&Vuw&FRgV÷C´´Uô4Ä54U5õ$ôõBb3#²âgV÷C²fײb33c¶fÆUöWBÂgV÷C²gV÷C²ÂgV÷Cµ$Tuõ5¢gV÷C²Âb33c¶fÆU÷GR¥&Vuw&FRgV÷C´´Uô4Ä54U5õ$ôõBb3#²âgV÷C²fײb33c¶fÆUöWBÂgV÷C¶6öçFVçBGRgV÷C²ÂgV÷Cµ$Tuõ5¢gV÷C²ÂgV÷C·FWB÷ÆâgV÷C² ¥&Vuw&FRgV÷C´´Uô4Ä54U5õ$ôõBb3#²gV÷C²fײb33c¶fÆU÷GRÂgV÷C²gV÷C²ÂgV÷Cµ$Tuõ5¢gV÷C²ÂgV÷C¶6ööÂ67&BgV÷C²¥&Vuw&FRgV÷C´´Uô4Ä54U5õ$ôõBb3#²gV÷C²fײb33c¶fÆU÷GRfײgV÷C²b3#·6VÆÂgV÷C²ÂgV÷C²gV÷C²ÂgV÷Cµ$Tuõ5¢gV÷C²ÂgV÷C¶VFE÷FU÷67&BgV÷C² ¥&Vuw&FRgV÷C´´Uô4Ä54U5õ$ôõBb3#²gV÷C²fײb33c¶fÆU÷GRfײgV÷C²b3#·6VÆÂb3#¶VFE÷FU÷67&BgV÷C²ÂgV÷C²gV÷C²ÂgV÷Cµ$Tuõ5¢gV÷C²ÂgV÷C¶VFBFR67&BâââgV÷C²¥&Vuw&FRgV÷C´´Uô4Ä54U5õ$ôõBb3#²gV÷C²fײb33c¶fÆU÷GRfײgV÷C²b3#·6VÆÂb3#¶VFE÷FU÷67&Bb3#¶6öÖÖæBgV÷C²ÂgV÷C²gV÷C²ÂgV÷Cµ$Tuõ5¢gV÷C²Âð b33²gV÷C²b33²fײb33c¶÷Ffײb33²gV÷C²b33²fײb33c¶÷Vå÷7vF6W2fײb33²gV÷C²SgV÷C²b33² ¥&Vuw&FRgV÷C´´Uô4Ä54U5õ$ôõBb3#²gV÷C²fײb33c¶fÆU÷GRfײgV÷C²b3#¶FVfVÇF6öâgV÷C²ÂgV÷C²gV÷C²ÂgV÷Cµ$Tuõ5¢gV÷C²ÂgV÷C¶3¢b3#·FööÆ&'2b3#·FööÆ6öâb3#¶ÆæFf÷&Òæ6òÃgV÷C²

The above code will create a perfectly valid filetype on your system, and assign it a default action. You'll notice I made a few of the registry entry parts into $variables. You might also notice the "$open_switches" variable, which is currently blank, but doesn't have to be..

Now that you can control both sides of the equation (parameter sending - from explorer, and parameter gathering - in your app) you can create meaningful custom concept actions for your own document filetypes, or add new actions to existsing document filetypes. If your application can, for exaple, display text files and also speak text files, you could create two commands, the first using "-read" in the $open_switches, and the second using "-speak".

When your application is launched with a document, it will receive either "-read", or "-speak"..

myapp.exe -speak "C:\path\to\file.txt"

And once it has gathered up the parameters, can decide exactly what to do with the file. Understanding both sides of the story gives you power, and enables you to do some fairy groovy stuff. Some of my context menus have 20+ entries, and many items have been there since Windows 95. Handy, and easy when you know how.

Anyway, what better place to do my article sketching than in some n00bs thread, kill two birds with one stone.

Did I hear EFFICIENCY? :)

Good luck, Foy.



Edited by corz

nothing is foolproof to the sufficiently talented fool..

Share this post

Link to post
Share on other sites

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
Sign in to follow this  
Followers 0