Leaderboard

do your args have spaces in them? If so, you should wrap them: ...i'm not sure if you can escape?? Assumed the escape is (because of your file path escaping the )...so where you see ", it's actually including a " in the start() var proc = Process.Start("C:sample.exe "" + arg1 + "" "" + arg2 + """); Wish I knew more about C coding of any type, sorry edit: answer 3: http://stackoverflow.com/questions/5168612/launch-program-with-parameters edit2: this is an autoit forum

Sometimes all it takes is to see it in action to understand how it all works together.

Yes you can, that is its only purpose. Here's a very simple script to demonstrate it. #include <Constants.au3> If $Cmdline[0] > 0 Then For $I = 1 to $Cmdline[0] MsgBox($mb_systemmodal, "$Cmdline[" & $I & "] = ", $Cmdline[$I]) Next EndIf Compile it, and send it some command line parameters.

The $cmdline is constant durring the script run...it's values are determined by what you pass in...such as your exampl: sample.exe "123" "addinganother" "andanother" If your compiled script is ONLY what i have pasted above, then you will be able to read the param "123" (as well as the other ones)...change it to a messagebox to see it: ; this is the ONLY code in sample.exe: For $i = 1 To UBound($CmdLine) - 1 msgbox(1,1,$CmdLine[$i]) Next

I'm guessing you're confusing how a batch file process a command line parameter and how AutoIt does it.

You can copy the variable. Local $aCmdLine = $CmdLine ; This is an internal AutoIt constant.

The cmdline array is for reading, not setting...show us how you are calling the script. For $i = 1 To UBound($CmdLine) - 1 ConsoleWrite($CmdLine[$i] & @CRLF) Next

Longer story: you need to open the output file as UTF-8 by using $handle = FileOpen(...) with the encoding option set to UTF-8 (with or without BOM depending on context), then use FileWrite($handle, ...) to write to the file and FileClose($handle). FileWrite("myfile.txt", $string) will convert $string to ANSI and writes it. Conversion from many languages to system-ANSI is not always possible. Is that clear?

Except that the resources come after the code sections I believe. Oh by the way, here's a copy of the latest specification via Microsoft. http://msdn.microsoft.com/en-us/windows/hardware/gg463119.aspx Would probably be a good place to start.

search for GetSystemFirmwareTable

It would break the includes if they didn't reside in the folder desktop. It's just trial and error and re-arranging your includes properly.

Do you also want to theme your GUI?

Try doing it with UDF from Melba

No nightmare then

Have you not told your boss that maybe subversion control is the way forward? Edit: It's how water and I (plus the other Devs/MVPs) update the AutoIt source code and UDFs. Otherwise doing it all via PM/e-mail would be a logistical nightmare.

Two persons playing around with the source code on different machines? What a nightmare!

Guinness just told you to try. He didn't say it works

If you distribute compiled scripts you do not need to install AutoIt on every PC, users can't modify the script etc. A lot of advantages.

Olo, That's not criticising, if you had posted the code in your first post then we wouldn't be 5/6 posts down. But you're right about one thing I don't have to help you, though I will...you can't use variables like that as they're created when the script is compiled and running. Did you try? #include <%USERPROFILE%\Desktop\Library\Error_log.au3> If I had to criticise though, it would be learn to post more detailed support questions in future.

#include is a directive which is processed before any variables are set. So: No you can't do it this way Wouldn't it be easier to distribute the compiled script?

You might include that, then. Something like: "Is (xyz) possible? I tried it by doing (abc), but couldn't get it to work." Then at least we can see what you've tried, rather than guessing

Glad the problem could be solved. Lessons learned: It is good practice to do all variable definitions at the top of the script or the functions.

I see. Set Local $file = "BCU101C_DSI002.XML" to Global $file = "BCU101C_DSI002.XML" and set Local $file = FileFindNextFile($search) to $file = FileFindNextFile($search)

I see nothing wrong with your code. You could inserte some debugging statements like ConsoleWrite("x: " & $file & @CRLF) in your script to verify that the content of $file is as expected. Replace "x: " with the location in your script (e.g. function name or whatever).

Where do you call LoadfileWB and which parameters do you pass?

Can you post the code where you enumerate the XML files and do the processing?

For Firefox look also: http://support.mozilla.org/en-US/questions/942316?page=4 tenbucks posted 5/15/13 3:13 AM "Finally. It's here with FF 21. You need to add the browser.shell.shortcutFavicons entry in about:config. It doesn't come with it. Make it boolean and set it to false. Restart FF." Paul

I just wanted to keep it as simple as possible. I've often seen users asking this kind of questions having problems with arrays as well. But as I mentioned above: There are many ways to ....

water, Nothign worng with them at all - but in my opinion is is better for newer coders to use existing functions that wrap more complex concepts. There is much less chance of the script failing for reasons unconnected with the actual reason the script is being written - and it is much easier for us to debug when needed. Besides FileFindFirst/NextFile are themselves actually wrappers of the API calls - should we suggest the OP thinks about coding at the DllCall level? When coding in any level language I feel that you should take advantage of the libraries that are available until you feel confident enough to look deeper. But as I said that is a personal opinion - no-one is forced to follow it. M23