tehdon

I thought I was just crazy. I'm seeing the exact same thing when compiling the script using x64 vs x86. Running through Scite it works great, compiling as x86 it works great, compiling under x64 gives the empty drop down but you can still scroll through the entries. I'm using Win7 x64. Is there something I'm missing in creating these combo boxes, or is there documentation that explains this behavior away?

According to the SQLLite documentation here http://www.sqlite.org/lang_corefunc.html#round It would appear if you specify two arguments, a floating-point number is returned. If you only specify one argument, an integer is returned. Not sure how many operations you're doing, but it may be more efficient to call round() with one argument rather than CASTing every result.

I think the recordset returned from the query will contain just the column names even though you are joining two tables. So the record you are attempting to access would actually be name 'Description', not 'tblBuildings.Description'. Try referencing $rsFields("Description").value and see if that gets you past the error. If you have two identically named columns in the tables being joined, rename one or both using the AS statement in the SELECT statement.

I can't say I've tried this before, but looking at the help file, FileFindFirstFile() will return directory names if they match the wildcards supplied. I think you could use that along with FileGetAttrib() to determine if what is being returned is a directory and if so do what you need with them. I usually end up doing things the long way so there very well might be a simpler solution available. If so, someone will likely chime in with it. [Edit: Or post the more simple solution before I even post mine ]

You can start notepad hidden with ShellExecute("notepad.exe","","","",@SW_HIDE) The following would show it, assuming the Window title hasn't changed since when you opened it WinSetState("Untitled - Notepad","",@SW_SHOW)

The example you've given and what occurs seems to behave exactly as the example given in the help file for ContinueCase. I don't think it's a bug.

As stated previously, I am running Windows 7 x64 and ShellExecute() does work to launch msconfig.exe IF I am using the x64 version of AutoIt, otherwise I receive the same error. The previous link I posted was an excerpt from the Programming Guide for 64-bit Windows on File System Redirector. In it, the following is stated I believe this means that even if your script specifically references 'c:\windows\system32\', if Windows sees that your are an x86 application, it will redirect you to 'c:\windows\syswow64\'. The help file topic 'Running under Windows 64-bit Edition' discusses this topic as well. In it, it is suggested the following will disable the redirector DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "int", 1) It may be worth adding the above to your script and seeing if msconfig can suddenly be opened properly.

Sorry, sources are useful http://msdn.microsoft.com/en-us/library/aa384187.aspx

madasraka - can you try the following code ShellExecute("msconfig.exe") While 1 Sleep(100) Wend You'll still receive the error, but check in Task Manager and see if you have AutoIt3_X64.exe or AutoIt3.exe running alongside the AutoIt3Wrapper.exe. If you don't have AutoIt3_X64.exe the application is executing as a 32bit application. From what I'm reading, in 64bit Windows 7, a 32bit application will substitute c:\windows\syswow64\ for c:\windows\system32\ and msconfig.exe only exists in \system32\, not \syswow64\. I have 64bit Windows 7 and can duplicate what you're seeing by running the script from Start > All Programs > Run Script(x86). Scite launches my scripts in x64 mode by default (not sure if that was something I configured during installation or not, I don't recall). As a further test, if you go ahead and compile the above code and check the option to compile for x64, does msconfig launch correctly?

It still looks as if at least one more element is being referenced than what exists in the $aArray. Try GEOSoft's (slightly modified) code: $aArray = StringRegExp(FileRead("lines.txt"), "^(.+)(?:\v)(.+)(?:\v|$)", 1) For $i = 0 to Ubound($aArray) -2 Step 2 If($i+1 < UBound($aArray)) Then MsgBox(0,"Result","User: " & $aArray[$i] & @CRLF & "Password: " & $aArray[$i+1]) EndIf Next I think this will work, I'm pretty mushy brained at this point of the day, though.

I think maybe there's a simple typo in the code you have referencing the array, assuming there are at least four lines of text in the file being read. Your code $aArray = StringRegExp(FileRead("lines.txt"), "^(.+)(?:\v)(.+)(?:\v|$)", 1) If NOT @Error Then $1User = $aArray[0] ; line 1 $1Pass = $aArray[1] ; line 2 $2User = $aArray[3] ; line 4 $2Pass = $aArray[4] ; line 5 MsgBox(0, "Result", $1User & @CRLF & $1Pass) EndIf Try this code and see if it completes $aArray = StringRegExp(FileRead("lines.txt"), "^(.+)(?:\v)(.+)(?:\v|$)", 1) If NOT @Error Then $1User = $aArray[0] ; line 1 $1Pass = $aArray[1] ; line 2 $2User = $aArray[2] ; line 3 $2Pass = $aArray[3] ; line 4 MsgBox(0, "Result", $1User & @CRLF & $1Pass) EndIf However, you still the risk of the same error if you just assume StringRegExp will return an array with at least four elements. [Fixed typo in post, how ironic ]

Working around your question a bit, but it sounds like you're saying if the host cannot connect to your site, InetGet takes too long to return control to the script, correct? Could you try pinging the site and only attempt the update if the ping returned successful? $pingTime = ping("hostname") If($pingTime > 0) Then ;do InetGet stuff EndIf

Check out FileReadLine in the help file.

If you have physical access to the server mySQL is installed, you might look at automating the mysqldump utility. Documentation about mysqldump can be found here. This snippet is what I use to backup my mySQL databases $mysqlCommand = "mysqldump " & $databaseToBackup & " > " & $fullPathToPlaceBackup RunWait(@ComSpec & " /c " & $mysqlCommand, "", @SW_SHOW)

Not a big fan of bumping up a 2+ year old topic, but I ran into this same issue today and found a decent workaround. I found that calling the function in the following method allow the entire desktop to be captured. _ScreenCapture_Capture($capFullPath,0,0,@DesktopWidth+@DesktopWidth,@DesktopHeight,True) The above will work if the primary display is farthest left, there are exactly two displays, and both have identical height and width attributes. Or in other words, is set up identical to how my workstation is setup at the moment There's probably a good method of identifying all of those attributes and passing in the parameters accordingly.