TurionAltec

I can see why you're overwhelmed, that's a lot of tasks! I'm fairly experienced with AutoIT and it would take me a while to develop a script that can do all those tasks, specially sometime robust enough to work on many machines. And there may be more suitable tools, such as creating a master image and restoring with Sysprep that might be more applicable. Start by breaking each task down. Create a test script to tackle only one problem. Don't worry about the user interface, don't worry about the other tasks. Just use hard coded values in the script. When in development I like using "ConsoleWrite" to spit out some debug information while I go. When When looking at some of these system level changes, see if there's any programmatic API, registry, WMI, commandline tool that can do it. Trying to rely on pure GUI automation (mousemove, click, keystrokes, even controlclick) can be fragile. Your script is doing a lot of admin level stuff so it will need #RequireAdmin at the top. Admin username / password: Look at Commandline interface via Net: (net User, Net localgroup). These could be invoked via a Runwait() command. No need to use @COMSPEC because net.exe is separate from the command interpreter cmd.exe. Password hint may be more difficult Computer Name: Looks possible via wmic. Looks like you need to know existing name, doable via @ComputerName in AutoIt Sample wmic code, looking like it's written for batch, is: wmic computersystem where name="%COMPUTERNAME%" call rename name="NEW-NAME" Getting name from excel may be a little more involved, especially if Excel isn't installed on the PC. Look at IniRead, and FileRead/FileREadLine/FileReadToArray for potential options to read from a text file. To download something via http, check InetGet() Run programs using "Run" if you'll then need to interact with it, or "RunWait" if you want to wait for execution to finish. Pinning in Windows 7 at least it's just copying or deleting a shortcut into a certain file. Either per user, or one for global. Check our FileCopy() and FileDelete() Once you can get the individual features working, then look at starting to assemble them in one script.

When you're writing your post, there should be a bar above with Bold, underline, etc. There should be a "<>" icon for code. Paste your code in the window that pops up.

The latest version that isn't a Beta, and be sure to get the "AutoIt Script Editor" package to go with it.

I only see this line: ConsoleWrite ("""C:\Windows\System32\cmd.exe""" & " /c """ & $SysInternal_Loc & """ \\" & $System_Loc & " """ & $vtp_loc & """ /GetCertChain """ & $FileLocation & """ > """ & @TempDir & "\GetCert" & "\" & $ProcessName & "-Cert.txt""") This won't excecute it, only write it to the window in the bottom of Scite. Maybe something like: $sPSExecString="""C:\Windows\System32\cmd.exe""" & " /c """ & $SysInternal_Loc & """ \\" & $System_Loc & " """ & $vtp_loc & """ /GetCertChain """ & $FileLocation & """ > """ & @TempDir & "\GetCert" & "\" & $ProcessName & "-Cert.txt""" ConsoleWrite ("Debug output:"&$sPSExecString&@CRLF) Runwait($sPSExecString,"",@SW_HIDE) You could also use run, combined with StdoutRead to read the input directly into AutoIT if you were going to further process the output in AutoIT, rather than relying on a text file.

This error looks like the interpreter (Normally Autoit3.exe) it trying to call a non-existent script file. To trackdown where it is coming from, with the error open: use Microsoft's Process Explorer. You may need to start process explorer as administrator / use "Show details for all processes" in the file menu. When the popup shows up, drag the target icon from process explorer to the window. In the process explorer list this will highlight the executable that's generating this error. Right click the executable and "Properties". It will show "Parent" of who called it, and "Autostart location" may show if it was task scheduler that called it. It will also show the path if you want to delete the autoit executable. If it was task scheduler you can then go in and delete the task.

Since you're using VBA, if you're trying to automate MS Office applications, checkout some of the built in UDFs (User Defined Functions) such as for Excel (in the help look at contents-User Defined Functions Reference-Excel Management) If you want to add AutoIt functionality to your VBA code, look up the "AutoItX" help under COM Interface for a list of Methods and Properties supported.

When reading configurations from a file, you may want to look at using .ini files. Built in functions like IniRead make it a breeze to handle

This is exactly what I was looking for. Both the /MO and A3X. Like @BigDaddyO SEP started going around deleted my compiled scripts. I completely glossed over the A3X option in the compile screen.

To expand on @jchd's post, TimerInit returns QueryPerformanceCounter. TimerDiff returns the difference of QueryPerformanceCounter (relative to QueryPerformanceCounter value captured by TimerInit), divided by QueryPerformanceFrequency, which will depend on CPU speed. If you call TimerDiff with no reference, it will give time since boot. See this previous post of mine Looking at this contrived example, the builtin TimerDiff and TimerInit functions are very performant, although you could calculate the QueryPerformanceCounter you want to see in the future ahead of time, to know if a certain amount of time has passed, and be more performant. Though these are incredibly contrived, as the loops don't do any useful work. #include <Timers.au3> $dLoopLength=10000000 $hTimer=TimerInit() For $i=1 to $dLoopLength $fDummytime=0 Next $fDummytime=TimerDiff($hTimer) ConsoleWrite("Empty For loop: "& $fDummytime&@CRLF) $hTimer=TimerInit() For $i=1 to $dLoopLength $fDummytime=TimerDiff($hTimer) Next ConsoleWrite("Builtin TimerDiff: "& $fDummytime&@CRLF) $hTimer=TimerInit() $fFreq= __Timer_QueryPerformanceFrequency()/1000 For $i=1 to $dLoopLength $fDummytime=(TimerInit()-$hTimer)/$fFreq Next ConsoleWrite("Hybrid TimerDiff: "& $fDummytime&@CRLF) $dLoopLength=$dLoopLength/100 $hTimer=_Timer_Init() For $i=1 to $dLoopLength $fDummytime=_Timer_Diff($hTimer) Next ConsoleWrite("UDF TimerDiff: "& $fDummytime*100&@CRLF) $i=1 $hTimer=TimerInit() Do $i+=1 Until TimerDiff($hTimer) > 2000 ConsoleWrite("Builtin Timerdiff:"&$i&" loops"&@CRLF) $i=1 $hTimer=TimerInit() $fFreq= __Timer_QueryPerformanceFrequency() $hTagetend=Int(TimerInit())+(2*$fFreq) Do $i+=1 Until TimerInit() > $hTagetend ConsoleWrite("Hybrid Timerdiff:"&$i&" loops"&@CRLF) Empty For loop: 1327.85372380903 Builtin TimerDiff: 3809.99572739426 Hybrid TimerDiff: 4339.62816893478 UDF TimerDiff: 151207.223724135 Builtin Timerdiff:3647645 loops Hybrid Timerdiff:5246004 loops

Lots of good stuff here. Run + StdoutRead / SterrRead is useful to read in the output from a CLI program. If you're expecting the program to keep outputting data, you can start it and periodically run StdoutRead without having to use Processwaitclose. Shellexecute can't do anything with StdoutRead / SterrRead, which is why it shouldn't be used. If you do want to compile your script as a console application, ConsoleWrite will let you send output (and it will show in the console in the bottom of Scite when not compiled. I use it a lot for debugging vs. Msgbox.). However if you compile your script as a console Application, ConsoleRead won't work as expected to capture typed input. $CmdLine is great if you want to pass your program commandline parameters. It is easy to read the output of CLI programs, but significantly more involved if you want to send interactive input to one (other than commandline parameters). Also, and I have no idea why @comspec keeps being included everywhere, but @comspec does nothing but take unnecessary resources if you are not trying to call commands internal to the cmd.exe interpreter (dir, copy, type, etc). Any other CLI application you can, and should, call without "@comspec /c". This includes a lot of built in Windows commands like sc.exe, net.exe, ipconfig.exe.

You likely don't need to bother. Stick with sensibly named variables.

Only in the tightest of algorithms that run iteratively for a long time should use short variable names, or possibly the variable in a for-next loop. I recommend following the Best coding practices for variable names, which will make maintaining your code significantly easier. Particularly if you go back and modify a program your wrote 6 months or a year previous. Using good variable names will make the code "self-documenting", reducing what you actually need to add as comments. When writing code, readability should be above performance, except for super high performance cases. But at the same time, given equal readability, higher performance should should be chosen (so for example, don't call @ComSpec unless you need an internal cmd.exe command) . If you have code run in a tight loop such that the name makes such a performance difference, you should look at doing it in a compiled language where you can use sensible variable names during development, that will compile down to the same thing whether you use a long name or a short name. $hTimer = TimerInit() For $i = 0 To 10000000 $x = "" Next ConsoleWrite("Short var name:" & TimerDiff($hTimer) & @CRLF) $hTimer = TimerInit() For $i = 0 To 10000000 $Sensiblelengthvar = "" Next ConsoleWrite("Sensible var name:" & TimerDiff($hTimer) & @CRLF) $hTimer = TimerInit() For $i = 0 To 10000000 $veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongvar = "" Next ConsoleWrite("Very Long var name:" & TimerDiff($hTimer) & @CRLF) Short var name:1698.24554406784 Sensible var name:1782.88926743569 Very Long var name:2066.1672312123 +>19:47:17 AutoIt3.exe ended.rc:0 +>19:47:17 AutoIt3Wrapper Finished.

AutoIt is interpreted, not compiled. I suspect the first option will be quicker because there's less code, and less nesting. Practically it matters only if this is called repetitively in a very tight loop. From a tidiness point of view I don't see any gains in the second version, and actually see it as a messier solution. $i = 0 $nul = "" $hTimer = TimerInit() For $i = 0 To 10000000 If 1 = 0 Then ConsoleWrite("Math has changed" & @CRLF) ElseIf 1 = 1 Then $nul = "" EndIf Next ConsoleWrite("Elseif: " & TimerDiff($hTimer) & "ms"&@CRLF) $hTimer = TimerInit() For $i = 0 To 10000000 If 1 = 0 Then ConsoleWrite("Math has changed" & @CRLF) Else If 1 = 1 Then $nul = "" EndIf EndIf Next ConsoleWrite("Else if: " & TimerDiff($hTimer) & "ms"&@CRLF) Elseif: 6375.40588783317ms Else if: 7675.14516364101ms +>18:31:47 AutoIt3.exe ended.rc:0 +>18:31:47 AutoIt3Wrapper Finished. As expected. Likewise I expect that the sooner in an If -Elseif-Else statement it evaluates true, the quicker the execution, with it practically only mattering in a tightly called loop. So the most frequent, but logically correct, option should be higher up.

Is there some reason you can't just run your executable directly, instead of very clunkily automating cmd.exe? #RequireAdmin #include <MsgBoxConstants.au3> Global Const $sMessage = "Select a folder" ; Display an open dialog to select a file. Global $sFileSelectFolder = FileSelectFolder($sMessage, "") If @error Then MsgBox($MB_SYSTEMMODAL, "", "Nem választottál ki mappát!") Exit EndIf Global $Tiff_path = $sFileSelectFolder & "\TiffChecker_2_32" FileCopy( "C:\TiffChecker_2_32.exe" , $sFileSelectFolder) $CMD = $Tiff_path & " " & $sFileSelectFolder & " /s/d" RunWait($CMD);Run Executable directly MsgBox(0,"Press OK", "Press OK to continue") FileCopy("C:\Tiffchecker.txt", $sFileSelectFolder)

net.exe is it's own executable, and not a cmd.exe command, so calling @compspec does nothing but waste resources. This should do it: $handlerstop = RunWait ('net stop GoldenEye.Handler')