Leaderboard

My point was, if you're going to use the default delimiter character as the code delimiter character, you'd have to make sure whatever you're using to split the lines knows what's inside quotes and what's not inside quotes, and act accordingly. Start writing the preprocessor then, and stop talking about it. I threw it out there that the tilde is being used already, I didn't say don't use it, I said it's already used for something else in your code. Reusing the tilde has the same issues that reusing the pipe character would have. It's already used, so why not use something that ISN"T used for ANYTHING else in AutoIt because neither of those are safe at the moment. BTW, I'm with Bowmore on this. Why make your code unreadable and difficult to troubleshoot for the sake of a couple of bytes on your hard drive (which as I've said before you won't actually save any space on the drive unless you're lucky or shortening the code by several thousand characters. Just because you can write the code that way doesn't mean you should be writing your code that way.

... string between and position where found #include <Array.au3> #include <String.au3> Example() Func Example() $sMyString = "[18]zero[20]hello18[18]example[5]one[500]two[60]" $aResult = _StringBetweenAndPos($sMyString, "[", "]") _ArrayDisplay($aResult) EndFunc ;==>Example Func _StringBetweenAndPos($sMyString, $sDelim1, $sDelim2) Local $aArray = _StringBetween($sMyString, $sDelim1, $sDelim2) If @error Then Return SetError(1, 0, "") Local $aResult[UBound($aArray)][2], $iStart = 1 For $i = 0 To UBound($aArray) - 1 $aResult[$i][0] = $aArray[$i] $aResult[$i][1] = StringInStr($sMyString, $sDelim1 & $aResult[$i][0] & $sDelim2, 0, 1, $iStart) + 1 $iStart = $aResult[$i][1] Next Return $aResult EndFunc ;==>_StringBetweenAndPos edit new listing debugged

You have to make sure that your script never throws such errors. Best way to achieve this is by using good coding practices and error checking.

I believe >this is what you need. There may be others.

I can't believe this is even being discussed. It just adds overhead with no significant advantage. I suggest gil900 learns what AutoIt can actually do before comparing it to other languages. You can call as many functions as you want with just one command and there are various ways it can be done. Also, a script is really just one long line anyway: it just happens to contain vertical spaces. I think there are more important concerns to focus attention on.

The >inner loops can't be removed, so Malkey's suggestion is not valid. The first post is a simplification of the concept. I have thought a little deeper about this and have come to the following conclusion (wherein lies the advantage of using Do...Until): This is intended use (although perhaps not anticipated), Do... run the loop first ... Until (condition is met) - Do loops will always run once regardless of condition. Others (While and For loops) test the condition first - These loops may sometimes never run. So I conclude this to be within the realms of good practice. @JohnOne - I doubt there would be any noticable speed gain (certainly not significant).

Oh, I haven't been reading anybody's code. I'm just commenting on the 1st post. Glad I could help though.

For an alternative similar to Autoit for Android... Try RFO Basic. http://rfobasic.com/ http://laughton.com/basic/ http://rfobasic.com/ http://laughton.com/basic/ Uses Basic syntax, Scite wit code highlight etc Code and build in windows or Android, test on Android platform. Doesn't have a lot of advanced feataures up fron, but easy to use =)

MacScript, Mobius' suggestion of disabling your AV while you compile a test binary is exactly what I did a few weeks ago when I alerted a company to a false positive. I sent then a simple script (a "Hello world" MsgBox), the compiled exe and a link to the AutoIt download page - they fixed the problem in a few hours. M23