daluu

Please refer to https://autumnator.wordpress.com/2011/12/22/autoit-sikuli-and-other-tools-with-selenium-grid/, as it should explain your exact issue, with suggestions on how to workaround it. A bit more work and tricky with Selenium Grid and more straightforward if you're just having issue executing from jenkins on a remote server, except for the latter, you'll have to put in logic to handle how to execute from jenkins case vs executing locally when developer testing.

Please refer to https://autumnator.wordpress.com/2011/12/22/autoit-sikuli-and-other-tools-with-selenium-grid/

Pardon me rlen, but your English is a bit hard to interpret for clarity. In the beginning you mention building a bot, now you say Windows executable. And you mention making Facebook status update with AutoIt (automating manual user action on a website via AutoIt), that makes sense. Then something about collect info from user database. What info? What database? You want to automate actions on Facebook page, capture the result of what Facebook displays on the page as a result of that action, and then save/log the result to your own local/private database? Is that it? If not it would help if you can clarify that better in English or whatever, or maybe in your native language and maybe that can be run through Google translate.

I meant that compiling (or building) from Scite did not produce an exe that writes to stdout. And compiling from the explorer right-click context menu compile options did not produce the right exe either even though it has the directive line of code in the au3 script. Using Aut2Exe.exe with the console switch did the trick. By the way, I have the lite Scite version bundled with the AutoIt installer package. I don't really care for Scite, I just wanted to compile the exe, just mentioned Scite here in terms of my observations on what happens. So from the discussions here, I take it only the full Scite can compile CUIs and not the lite Scite version? I don't know if it makes sense, but it may be helpful to add a compile to CUI option in the Explorer right-click context menu option for AutoIt. Less hassle than to have to do: "C:\Program Files (x86)\AutoIt3\Aut2Exe\Aut2exe.exe" /in test.au3 /console

Thanks, didn't know that. I was using the standard compile option in Scite (no compile dialog, just hit menu option), as well as the right-click option of the Explorer shell integration to compile for x86 or x64. I assume those methods will compile to GUI rather than CUI? I wish this was all documented more clearly. The info info should have been cross-linked/reference on the ConsoleWrite docs so I don't have to specifically search for this help info elsewhere in the AutoIt docs. Before this I never knew there was a difference between CUI vs GUI for AutoIt compilations.

Even just using the simple example in the referenced post #AutoIt3Wrapper_Change2CUI=Y ConsoleWrite("Hello World" & @CRLF) doesn't work for me (except just within Scite). Seems like something is up with my environment?

Environment: Windows 7 64-bit, AutoIt installed to use x86 version by default. Tried compiling and executing for both x64 and x86, no difference. Came across this post in debugging: '?do=embed' frameborder='0' data-embedContent>> Following the advice from that post, here is my code snippet, say I name it "test.au3" for example #Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_UseUpx=n #AutoIt3Wrapper_Change2CUI=y #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** ; CUI stub ConsoleWrite("start" & @CRLF) While WinExists("Adobe Illustrator CS5") <> 1 If WinExists("Script Alert") Then ConsoleWrite(WinGetText("Script Alert") & @CRLF) Exit EndIf WEnd ConsoleWrite("AI script done!" & @CRLF) When run as compiled exe from command line, e.g. "C:SomeFolder>test.exe", I see no output. For both x86 and x64 compiled versions (run from x64 and x86 command prompts). But I do see output from Scite editor using F5. The Scite output appears to show the command executed as well, something like: "C:Program Files (x86)AutoIt3SciTE..autoit3.exe" /ErrorStdOut "C:SomeFoldertest.au3" Executing same command parameters in command prompt doesn't print the same output to the command prompt. Nothing gets printed. I don't want to view output just in Scite but in command prompt. What's the issue here? I'm stumped. Also, no difference if I just had #AutoIt3Wrapper_Change2CUI=y directive only w/o the other one.

Well, the question of this thread was about checking the AutoIt error flag, that is set by AutoIt, and then resetting later (but sounds like AutoIt will auto-reset so that be ok, something I overlooked before). I don't know if but doubt SetLastError will modify AutoIt's error flag. Or has someone actually tried that out? By the way, those are C/C++ functions of win32 API, I don't know how that translates to COM. This thread was in reference to COM.

I know that function is in AutoIt, didn't see mention of it in AutoItX. Gave it a try with oAutoIt.SetError(0) and oAutoIt.SetError 0, gave similar errors. Guess that's not available under AutoItX. But I saw the remark under SetError function: https://www.autoitscript.com/autoit3/docs/functions/SetError.htm Hopefully that means that although the flag is set when there is error when next function is called, it gets reset to zero automatically, so that when you check the flag again, it is with respect to the last function called. Wish the AutoIt team at least updated the AutoItX help doc to mention that behavior for the error property as all that is noted is: "Status of the error flag (equivalent to the @error macro in AutoIt v3)" that's too basic. Do I have to consult the main AutoIt documentation to correlate everything else about the macro flag, sigh.

Well, it looks like neither oAutoIt.error = 0 nor oAutoIt.error(0) work. Logically, off the top of my head, I don't know of any other syntax one would normally use to reset the flag in AutoItX. I hope that's not a limitation the developers left out of AutoItX compared to AutoIt. If you can't reset the flag, then what's the point of the flag, in the cases where the user wants to do exception/error handling of "I don't care if there's a (benign) error, continue with next AutoIt command I'm about to run". Which one can typically do in programming languages & in Selenium by catching Selenium exceptions and ignoring them. But here, the flag stays set unlike Selenium exceptions once caught. I need to reset that flag. FYI, I tested in both Python and VBScript for resetting the flag. Since VBScript is usually default for dealing with COM, even the AutoItX examples are in VBScript, I'll post my test snippet: Set oAutoIt = WScript.CreateObject("AutoItX3.Control") WScript.Echo oAutoIt.error 'should be 0 oAutoIt.ControlGetText "[active]","","[ID:33]" WScript.Echo oAutoIt.error 'should be 1 If oAutoIt.error = 1 Then WScript.Echo "trying to reset error flag" oAutoIt.error = 0 oAutoIt.error(0) End If WScript.Echo oAutoIt.error 'should be 0 WScript.Quit You get output like this: 0 1 trying to reset error flag c:\Temp\auerr.vbs(7, 2) Microsoft VBScript runtime error: Wrong number of arguments or invalid property assignment: 'oAutoIt.error' c:\Temp\auerr.vbs(8, 2) Microsoft VBScript runtime error: Object doesn't support this property or method: 'oAutoIt.error' It appears the damn flag is read only. How to write to it?

This is kind of already posted here: '?do=embed' frameborder='0' data-embedContent>> but wanted to note this in this forum of example scripts in case some people only look in this forum for examples and not the other forums with respect to AutoIt integration or relation to Selenium WebDriver. So, the example in summary is: you can use Selenium WebDriver API to do AutoIt GUI automation (the ControlXyz() and WinXyz() functons, along with mouse and "send keys" functions). Although I suppose that might be opposite or counter to what most examples here are about - using AutoIt to do or control other stuff rather than using other stuff to control/run AutoIt. But regardless, it is an example implementation of a different use case for AutoIt beyond the general AutoIt community, like those who also use Selenium WebDriver and/or need to integrate Selenium with AutoIt for remote deployment. https://github.com/daluu/AutoItDriverServer with specific demo examples here: https://github.com/daluu/AutoItDriverServer/blob/master/sample-code/CalculatorTest.java https://github.com/daluu/AutoItDriverServer/blob/master/sample-code/calculator.py https://github.com/daluu/AutoItDriverServer/blob/master/sample-code/SeleniumIntegrationTest.java https://github.com/daluu/AutoItDriverServer/blob/master/sample-code/SeleniumIntegrationWithAutoItDriver.py

Sorry, for issues with Selenium-VBA - you should contact that project, or post your question to the AutoItX/COM support subforum (or section) of this forum. And AutoItDriverServer is a separate project. AutoItDriverServer is not for use with AutoIt script. Instead it is the opposite. It allows Selenium users to use/control AutoIt GUI automation from Selenium WebDriver APIs in any language binding/client for WebDriver. So in theory, that means that if these 2 projects below were updated for Selenium 2 WebDriver support http://bhimarajumavuri.blogspot.com/2010/02/selenium-autoit.html http://sourceforge.net/projects/blueducksda/ then you can use them to connect to AutoItDriverServer to then use/control AutoIt. But that would actually be silly/idiotic for an AutoIt script user since you are looping over the Selenium WebDriver API in order to use AutoIt from within an AutoIt script language when you could directly use it via the native AutoIt functions without going through WebDriver API. Except in the case of remote deployment, meaning you execute/run code from machine A but the code actually runs on or targets remote machine B. Like how Selenium Grid works. Because there is no AutoIt grid or remote AutoIt code execution natively. You'd have to use options like PSExec.exe, or distributed/remote COM if not using AutoItDriverServer.

I kind of take back what I said, the stated limitation of AutoItX, could potentially be worked around or complemented by this solution to potentially expose the other AutoIt libraries/UDFs that are not exposed by AutoItX: '?do=embed' frameborder='0' data-embedContent>> http://sourceforge.net/projects/au3automation Although it sure would be nice if those UDFs, the ones packaged with AutoIt at least, were exposed by AutoItX.

So, I haven't tried this, but I assume this tool/feature would allow one to expose AutoIt 3rd party libraries/UDFs over COM, as long as you wrap or export what you want to be exposed for COM? That would a nice way to work around (or "complement") the limitation of AutoItX exposing only the Windows GUI automation functions of AutoIt (and not the rest of the UDFs available, etc.). If my assumption is correct, anyone try out this tool against much of the UDF library offerings that are packaged with AutoIt? I'm interested, through experiences of others, in knowing which UDF libraries work well with this COM server and which don't. By the way, the SourceForge project page - Support section, you could probably edit that to tell users to get support here in the official AutoIt forums, etc. as it's not likely they can get support from Sourceforge: or enable the mailing list, issue tracker features of SourceForge project there. I recall those are available as I have 1 or 2 projects myself there (not AutoIt related though).

I'd say with regards to debugging, this can be useful as a way to test Windows GUI control identifiers/locators for the ControlXyz() functions and WinXyz() functions, for automating the Windows GUI. Similar to what you can do testing element locators with Firebug/FirePath/Firefinding for Selenium, as well as using the browser developer/javascript console to do same for Selenium for those that know how to work with the HTML DOM. With no interpreter shell, you have to write/edit script, run script, to test, which to me is more of a hassle to do to test out what Windows GUI locator will or will not work. Since the AutoIt GUI spy tool and other similar tools only tell you what possible identifiers you can use but don't provide an auto generated locator that will work like (the XPath/CSS locator generator) with FirePath, Firefinder for Firebug/Firefox. And on another related note, this interpreter could be thought of as an enhancement to the "run a single line of code" feature of AutoIt documented here: https://www.autoitscript.com/autoit3/docs/intro/running.htm