Python and AutoIt

[cpetz]

I just started reading up on AutoIt, and have pretty much committed to using it. I am well versed in programming, with Python being the primary counterpart I have chosen to work with AutoIt.

When I first looked at AutoItX, it exports some very convenient functions to get started with, but I feel like I am going to have to do a lot of AIT scripting to do anything more than intermediate. Is the documentation shipped with the AutoItV3 installer complete, or is there more undocumented functionality available?

Your *BASIC* scripting language is easy enough to use, but I really would like to spend most of my time in python (with COM enabling this), but it seems like there are some very big power functions missing. Without setting up a COM dispatcher in python (and then scripting on the AutoIt side), how can I run arbitrary scripts? Better yet, how about you accept text as a parameter, and then parse that as a script. What about polling stats, receiving events or callbacks, setting new hotkeys, accessing the very large subset of unavailable functions, or even some of the user-functions.

Is any of this possible without decent amounts of AutoIt scripting? If not, are there any Python addicts who have started efforts towards such goals? Where I can I find them?

A simple example. I want to poll certain keys (I would really like to receive keypress callbacks, but I have a feeling...), and according to recent key patterns, adjust my currently active hotkeys, or trigger events. As far as generating input, the current COM has everything you need, but there is little available on getting feedback through the same COM instance. Right now, all my solutions point to a very good amount of AutoIT scripting, and I was really hoping to avoid that for as long as possible

Do the DLL interfaces offer any more features, or is it nearly the same offering as the COM? (I have no problems with SWIG if that is the case)

Any help, or words of encouragement would be much appreciated.

[Richard Robertson]

There are no undocumented features that we are aware of in AutoItX. The Dll and COM interfaces are the same.

[cpetz]

The one function that I *feel* like you are missing, is something on the lines of an Execute(), that would take either a filename, or arbitrary text as an argument, and it would proceed to run it like a script. You might even have a non-blocking version of the same thing.

Maybe I am misunderstanding the philosophy of AutoIt and AutoItX. Or maybe, these are works in progress?

Whenever I start a COM instance, through python, of AutoItX, are we loading up a *full* AutoIt session in the background, and AutoItX just implements some proxy action. Or is AutoItX very much standalone. For example, if I go and delete all libraries other than the autoitx.dll, will the AutoItX still work perfectly fine?

[AdmiralAlkex]

AutoIt is for Windows apps and automation, AutoItX is for making the WinAPI easier for languages than can use dll/com. If you saw any other philosophy then you weren't just reading between the lines, you were reading... Behind them?

Or is AutoItX very much standalone. For example, if I go and delete all libraries other than the autoitx.dll, will the AutoItX still work perfectly fine?

AutoItX is the only library if you look in the actual folder, so yes it's very standalone.

All aside, if you want to run AutoIt-code, use AutoIt. AutoItX is for when you can't or wont learn how to code AU3_CDTray yourself.

[cpetz]

Ok, I have about a thousand questions now. I think I will stop with those, and present an scenario. Maybe it will shed light on my objective.

I like Linux. I am a command line junkie. Windows(7) makes me sad a lot.

When I am in Windows, I still like to keep my environment similar when possible, otherwise, I am constantly hitting the wrong hotkeys, and doing all kinds of things that would have worked in linux, but do other things in windows (sometimes I just forget)

My favorite X11 window manager, Openbox. You can control nearly every window/desktop related function through statically bound hotkeys, and even goes further to allow nested hotkey chaining. Very useful (although you must have a stomach for config files)

I also hate the mouse. There is a time and place for it. But when I am programming, or even just surfing web, it usually makes me mad when I constantly have to switch from keyboard to mouse, keyboard to mouse... just wastes time, and makes me spill my soda.

I have already begun some integrations to make my Windows, more like the linux environment I am accustomed to. Python runs well on both Cygwin and Windows, so getting scripts to coordinate is significantly easier. I find that I am lacking though, when it comes to getting away from the mouse.

I want to set up some hotkeys, that when activated, will poll the arrow keys constantly. I basically want to be able to drive the mouse via keyboard. But if you have ever tried this, the feel of it can be weird, so there are some behavioral considerations that can make it much more pleasant.

So, I have some general global hotkeys I need to set up (and change on demand), and I have some other keyboard integrations I would like to perform, and I am hoping AutoIt is the one to help me do it. My biggest hurdle is that I am already committed to Python. I was hoping to avoid massive AutoIt scripting, which it now looks like I may have to do. If I am screwing around with the behavior of my keyboard-driven-mouse, I would rather be dabbling with python, not a BASIC.

If I am going to have to script AutoIt itself, I will probably want to do so in the form of a massive proxy library, just so I can get my ass back over to python

Is AutoIt really the tool I am looking for? Is this a reasonable usage of AutoIt?

[daluu]

All aside, if you want to run AutoIt-code, use AutoIt. AutoItX is for when you can't or wont learn how to code AU3_CDTray yourself.

AutoItX is also for when you want to integrate AutoIt features/functionality with another language or platform outside of AutoIt. Or use certain features of AutoIt in another language, rather than having to use AutoIt's language. Unfortunately, not all features of AutoIt are exposed through AutoItX/dll, such as third party AutoIt code/libraries, as well as the AutoIt GUI building functions. But for me the GUI automation APIs are good enough, that's what I use AutoItX for.

Personally, I find that if all you need is the core AutoIt features exposed through AutoItX/dll then it's just a matter of preference whether you want to code in AutoIt or another language using AutoItX or the DLL. For me, in that case, I prefer AutoItX w/ VBScript (or JScript).

[Richard Robertson]

Yes, AutoItX only exposes a few core functions. It was never designed to be "AutoIt in [your-language-here]".

[cpetz]

Im not considering this thread closed just yet, just quick response to richard.

You should consider (if you are in such a position, or if you could pass this up) making it as such ...

"AutoIt in [your-language-here]"

It does not have to be a built in, maybe something similar to AutoItX. It seems like you guys have a decent amount of pride in your language, and it is good for what it does, but languages are a dime a dozen. Functionality is money.

I am a python programmer. I dont want to write a trillion hooks into Microsoft's magic box. You have already done the dirty work. If you guys made something similar to my last suggestion, I (me, this guy), would seriously be willing to pay $20+ for a single computer license, and I would want a few of them.

More of a suggestion than a complaint. Open up accessibility to your software, and I would probably have dreams (of a particular kind) about you guys.

[Mat]

AutoIt3.exe is also standalone I think, so how about writing a script and then using AutoIt to run it. As far as inter-script communication goes, theres plenty of ways to go about it, not sure about with python though (maybe a C extension)

[cpetz]

I have considered doing something similar. It seems to me, that I am going to want a long running script that just loops and listens. Then, I will be spawning several short lived processes, or use some form of inter-process comm that will instruct the initial long running.

I want some smart managing of hotkeys, and I have a feeling multiple independent processes are going to give me a lot of headaches. I was looking through the user-defined functions (are those stable by the way, or are they very much *user*), and I found several options I can work with. I can use STDIN/OUT for some easy stuff, named pipes I think are going to be my version of messaging/callbacks, and i can use sqlite for longer term data.

I also think I may be able to work out some communication with COM events, but I may wait a bit for that.

Also, Python is built on C, and has some very cool libraries meant just for C/C++ interfacing (SWIG). But, unless you know of any clear advantages that I would gain from such interfacing (as stated earlier, DLL and COM have same functionality), I will stick with the more standardized methods.

[Richard Robertson]

I occasionally pick up my AutoIt.Net project (which allows all functions to be accessed from any .Net language) but I never have much time to devote to it.

Officially, I am unrelated in any way to the development of AutoIt.

[DaleHohm]

It may or may not add directly to this discussion, but note that you can also access Python through the ActiveX Scripting interface (COM) as long as the Win32 extensions for Python are installed.

From AutoIt:

$oPython = ObjCreate("ScriptControl")

$oPython.language = "Python"

$return = $oPython.eval('python command')

Dale