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

Hmm...105 views, but no comments on behavior? I guess no AutoItX user ever had to worry about @error being reset for subsequent commands. Guess I'll have to try and experiment sometime and then post my findings here.

AutoIt script has an @error macro/flag that gets set when some functions are called that fail. And one can check that flag's value after function call to see if it failed or not. In AutoItX, the help file shows oAutoIt.error() or in some language's COM interface just oAutoIt.error w/o the parenthesis. I know that works. But I was just recently wondering, how do you reset that flag if it doesn't auto-reset once you check the flag and continue onwards to other commands in your program/application and/or ignore the failure. In the AutoIt script function reference, I see SetError() function: https://www.autoitscript.com/autoit3/docs/functions/SetError.htm just skimming over the AutoItX help file, I didn't notice an equivalent to SetError, unless I overlooked some section. So is there an equivalent to set/reset @error in AutoItX? Or is it simply something like oAutoIt.error(0) or oAutoIt.error = 0 Can someone clarify?

Well, the point of the project was to allow a user to have the following options when using AutoIt (whether integration with Selenium to handle something Selenium couldn't or for standalone automation): * not need to execute AutoIt through a process or shell execute in their programming language that calls Selenium. * not need to compile AutoIt script into a binary for deployment - although longtime AutoIt users may find compile & deploy easier * not need to deal with another language like AutoIt writing AutoIt au3 script to then compile to binary to then be called by Selenium test to do something * not need to use COM in their programming language that calls Selenium in order to call AutoIt if not using the compiled binary route * allow remote deployment of AutoIt when called in Selenium test w/o needing extra tools - Grid deployment, RemoteWebDriver. To illustrate: Selenium client code runs on host A it targets browser running on host B (via RemoteWebDriver). Now say for AutoIt integration to handle HTTP authentication popup, we need it to run on host B also but executed from host A that runs the Selenium code. The normal shell/process execute won't work as that's local to A. You'll need to add in SSH, telnet, PSExec.exe (or winexe from Linux/Unix) to have host A call the AutoIt compiled binary on host B. Or run the Selenium test directly on host B instead of host A so that it will be local. And in this approach if not executing AutoIt as compiled binary but rather COM, COM isn't network enabled, maybe DCOM? These cases is where AutoItDriverServer fits in. Deploy that on remote nodes B, etc. Start it up. In Selenium test, fire up another instance of a driver connecting tot AutoItDriverServer, issue AutoIt commands over WebDriver API. No need to compile binary, no COM, already remote enabled. The complexity is more on how the server is implemented. It might seems complex to get the server up and running in the beginning but when you get used to it, it's actually pretty easy (single Python file, that just has Bottle Python module dependency + AutoIt installed or AutoItX DLL registered). Again it depends on ones preference. But I think this solution works better at scale. If you needed to deploy Selenium AutoIt integrated tests in a distributed and/or grid environment. I did say it's not natively Grid enabled, but there's a way around that. I'll mention it on the project site later on how that works.

About my previous post, you can now actually do that reverse case - drive AutoIt using Selenium WebDriver API: https://github.com/daluu/AutoItDriverServer

It's been long overdue, but I finally took the initiative to do something. And here's the result: https://github.com/daluu/AutoItDriverServer It's not Selenium Grid compatible yet, but hey, it's a start. You'll want to look at the Selenium integration demo in sample code section, which does show example of HTTP authentication and file upload handling with AutoIt while the rest of browser handling was done by Selenium.

kcvinu, have a look at these: http://stackoverflow.com/questions/3301561/calling-autoit-functions-in-python http://stackoverflow.com/questions/1065844/what-can-you-do-with-com-activex-in-python

Yes, that seems to be the case for WinGetClientSize, but not so for WinWaitActive, which AutoIt returns a window handle or 0, but AutoItX return 1 or 0.

I don't think this has been discussed, as I tried to do a search in the forum: It didn't occur to me until today from a comment discussion on StackOverflow that there's separate AutoItX documentation from the main AutoIt documentation. But that's ok. What I do want to inquire about though are these: Why is there no or very little AutoItX documentation online? You have to refer to the CHM help file for AutoItX in the AutoItX folder of the installation. Checking the online docs main page (https://www.autoitscript.com/autoit3/docs/) I see no link to AutoItX. One could say perhaps it's not the primary usage suggested/proposed for AutoIt, yet knowing the various postings & articles online that it is a major feature and many folks do use it in various programming languages. To me, it would be nice if AutoItX, documentation-wise not be a 2nd class citizen. Future updates should include it online if AutoItX is not going to be obsolete in the future. But that's just me speaking as if I could make change here. I'm also curious to wonder why there are some implementation differences for functions between AutoIt and AutoItX. Like WinGetClientSize vs the COM version's WinGetClientSizeWidth and WinGetClientSizeHeight, and this discussion: '?do=embed' frameborder='0' data-embedContent>>. Perhaps technically constrained by platform design (AutoIt language idiom/syntax vs COM interface constraints), or just a design choice deviation for COM implementation? I was lucky that when I did use AutoItX in the past, I relied on the online function reference for AutoIt, and the functions I used did not deviate from main AutoIt so I didn't run into problems. Guess I should be more reliant on the CHM help files going forward.

Basically AutoItX only gives you option to the GUI automation/control capabilities of AutoIt. You don't get the GUI creation features nor the 3rd party libraries for the additional functional support (IE browser, file system, networking, etc.) But then again if one was using AutoItX, you're likely to use the native capabilities of your programming platform for those missing features anyhow.

This is a repost from http://www.d3scene.com/forum/development/82572-tutorial-use-autoit-vb-net.html that I came across today. I don't think it is cross posted here already doing a search for .NET related stuff here. Please move to appropriate forum if posted to wrong one (e.g. ActiveX/COM Help and Support (AutoItX) or General Help and Support). If already duplicated here, please delete. Thought it deserves a copy here w/o having users to register over at the source forum to see it. I've yet to personally try the example though, plan to soon. Perhaps a good idea to later on provide the C# version of code snippet for comparison purposes. Original post info modified for clarity: Imports AutoItX3Lib Public Class MainForm Dim AutoitCommand As New AutoItX3 Private Sub StartButton_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles StartButton.Click AutoitCommand.Run("notepad.exe") AutoitCommand.WinWait("Untitled - Notepad") AutoitCommand.Send("This text sent to notepad by autoit functions{ENTER}Have Fun") AutoitCommand.Sleep(1000) AutoitCommand.WinKill("Untitled - Notepad") End End Sub End Class AutoItX3_x86.rar AutoItX3_x64.rar