Leandro Conca

Why don't you use the FileRead and FileWrite AutoIt functions to edit the files instead of using an external editor? Those will surely fit what you need.

If you want to assign the parameter you've passed in cmd line you have to flip your expression: $CmdLine[2] = $Var oÝ÷ Ù8^rëyË_¢¹¢±«­¢+Ø(ÀÌØíYÈôÀÌØí µ1¥¹lÉtoÝ÷ Ø l¢)íç(f§vX§{*.·*^vØ^rëyËb±+Z®×±y+Z®ÝvÜò¢ì×!jx¶©j¶¦z׫¶Òµªír§ëazÌ"µÈ¢jZ®+(«­¢+Ø) ÍÀÌØí µ1¥¹lÅtôÅÕ½Ðì½MÑÉÐÅÕ½Ðì(

There is a typing mistake in this version! This did not work! If FileExists(@SystemDir&"msxml"&$x&".dll") Then oÝ÷ Ø =Ú+&Ë" ÷"Û!¢é]m殶­s`¤bfÆTW7G277FVÔF"fײgV÷C²b3#¶×7ÖÂgV÷C²fײb33c·fײgV÷C²æFÆÂgV÷C²FVà Both in _XMLCreateFile and _XMLFileOpen (lines 126 and 203). By the way... Great UDF!

Ok, I was thinking in the opposite scenario, that the ini file you were trying to read was in the main script directory! But the ini files are in the called scripts dir, is that correct? In that case, you can use the 2nd parameter of Run function, that is the working directory of the process. You can do: Run("dir\script2.exe","dir") This will set the subdir called "dir" as the working directory of the "script2.exe" process. So, you can use IniRead() in the "script2" without specifying the full path to the ini file, and the script will look for it in the "dir" subdirectory. Hope I didn't confuse you more!

If the ini file is in the initial script directory, and the executed script must read an ini that is in the initial script directory, you can do: First (if the called scripts are one folder level up to the initial script dir): IniRead("..\inifile.ini",..... Or if the called scripts are in a more complex folder structure you can pass the initial dir as parameter to the script: Example: ; ----- script 1 -------- Run('script2\script2.exe "' & @scriptdir & '"') ; ----- script 2 -------- IniRead($cmdline[1] & "\inifile.ini",..... The script dir passed as parameter is enclosed in quotes to avoid errors if there are spaces in the dir names.

It's better to use the "extension" property as the filter: $colItems = $objWMIService.ExecQuery("SELECT * FROM CIM_DataFile WHERE extension='P12' OR extension='PFX'", "WQL", _ $wbemFlagReturnImmediately + $wbemFlagForwardOnly)

Are you using the FileClose correctly and the last version of AutoIt (3.2.2.0)? I did some testing here and works fine. Created 100 files in a loop: for $i=1 to 100 $file=FileOpen("c:\windows\temp\file" & $i,2) FileClose($file) next Commenting the line FileClose generates the error!

If you use WMI you can create remotelly CIM_DataFile objects and do not have to distribute scripts to all the machines in the network. You can create a query (WQL) to find the types of files you want to delete, something like: $wbemFlagReturnImmediately = 0x10 $wbemFlagForwardOnly = 0x20 $strComputer = <network computer name> $objWMIService = ObjGet("winmgmts:\\" & $strComputer & "\root\CIMV2") $colItems = $objWMIService.ExecQuery("SELECT * FROM CIM_DataFile WHERE Name LIKE '%.P12'", "WQL", _ $wbemFlagReturnImmediately + $wbemFlagForwardOnly) If IsObj($colItems) then For $objItem In $colItems ;do some validation to ensure that you want to delete this file ... ;delete the file $objItem.delete Next endif I don't know about performance, but I think it will be faster than using FindFirstFile and FindNextFile recursively. You can look at the TechNet scripts repository to get some ideas: http://www.microsoft.com/technet/scriptcen...t.mspx?mfr=true Also look in the AutoIt forums for ScriptOMatic. It's a great tool to get WMI object properties.

The working dir can not be a registry path! Supposing that InstallPath is a key in the registry that contains the installation folder: i.e.: InstallPath =C:\Program files\World of Warcraft You could read that value to a variable and then set the variable as the Working dir. $WoWFolder = RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Joymax\Silkroad", "InstallPath" ) Run("sro_client.exe", $WoWFolder) Hope that helps.