Am I in the right universe?

[GlyphMaker]

All,

I have only done a cursory review of the FAQ and forums, and so, no surprise, it's still not clear to me whether AutoIt is actually even the right tool for my application, which is related to laboratory test equipment automation. It's not that I am too lazy to do an exhaustive search of the site (which is quite nice, I think)...It's just I'm a slow reader when I've pulled as many all-nighters as is currently the case, and the replies on the forum tempt me to anticipate help from well-wishing and better-informed participants. So, I'm coming to the forum with what is most likely a set of noob questions having "yes" or "no" answers. I'll appreciate your reply, if helpful at all.

Background: I am writing software to automate lab tests of optical storage media using several different devices (really esoteric to my industry) connected to a single computer. So, there are some common devices like o-scopes and frequency analyzers and some less common laser control and measurement devices as well. I communicate with them via serial, USB and GPIB. That's all working very nicely. Things are working within an environment I've created using the Microsoft freebie, "Visual Basic Express 2008" (the reader chuckles). So now I've got all of this VB infrastructure running my lab, but there are some things I just can't readily do without some help involving the automation of certain applications that I did not write and for which I have no source code. I figure something like AutoIt may be the solution.

The problem is this: I need to access certain functionalities of the connected test devices, for which I have no documentation, no dll access, etc. What I do have is only the manufacturer's custom (proprietary) software - no source code, of course, as already confessed. There are functions in the connected devices that I can access only using manufacturers' stand-alone apps. For some reason, the device manufacturers have stonewalled, when my colleagues and I have asked for ways to directly access the deeper functionalities controlled by these programs. For example, there's no way for me to change which signal is being sent from a given device port into my o-scope, unless I use the device manufacturers' silly program to do it. That's not very convenient. It means putting my VB process on hold and pulling up another program, and it necessarily introduces more human operator involvement (error) to make selections, close the programs, continue running the VB code and so on. Yuck.

So, all that said, you won't be surprised by the question: Can I use AutoIt (or something it creates) from within my VB code to interact with the GUIs of other applications?

Basically, what I'm looking for is a way to pass parameters from my VB code and its forms into AutoIt, then have AutoIt go off and do my bidding, which, in this case, is to:

1. Pull up the custom third-party app provided by the device manufacturer.

2. Make certain selections within the app, which usually involves little more than hitting a "radio button" or a "start" button or giving a name to a data file, initiating a measurement under that name.

3. Close the third-party app.

4. Relinquish control back to my VB code.

Not a very succinct question, huh? It is what it is. If you can help me, even if by no more than reference, it may be beneficial to my work. Thanks for any direction you can offer.

[Inverted]

Yes, AutoIt is the best laguage for this kind of operations, especially if the target applications use "standard" windows/interfaces.

You can run what you want, select the options you want, press buttons, send keys, read text from the application, wait for it to finish, keep statistics and show them at the end, keep a log file of interesting things, play sounds when something important happens, you can use even have it speak using SAPI.SpVoice etc etc

If you don't really need visual basic, you could convert everything to autoit to simplify things.

In conclusion, AutoIt can be used as a "wrapper" for other programs.

[omikron48]

Yes.

AutoIt is primarily for automating GUI interaction on Windows.

You use Run or RunWait to make programs run. You use MouseClick or ControlClick to select controls on a GUI. You can use WinClose or ProcessClose to close programs.

But for your purposes, I think what you want to do is create small scripts that do a single contained set of actions, instead of a super script that does everything. You compile your scripts into an exe and run it using VB. You can pass any additional parameters you need to give your AutoIt script via commandline parameters.

If all your VB program ends up doing is calling AutoIt scripts, you might as well dispense with VB and just do everything using AutoIt.

Edited October 2, 2009 by omikron48

[GlyphMaker]

Yes, AutoIt is the best laguage for this kind of operations, especially if the target applications use "standard" windows/interfaces.

You can run what you want, select the options you want, press buttons, send keys, read text from the application, wait for it to finish, keep statistics and show them at the end, keep a log file of interesting things, play sounds when something important happens, you can use even have it speak using SAPI.SpVoice etc etc

If you don't really need visual basic, you could convert everything to autoit to simplify things.

In conclusion, AutoIt can be used as a "wrapper" for other programs.

Thank you. So, it sounds like this may be a fruitful path, yet. I probably did not make clear that there is a hefty amount of additional analysis and active device control in my VB apps, so, certainly, they cannot be dispensed with. In fact, what I see happening is calling-up the third-party apps from within a loop of my own program. Again, thank you for your confirmation of the purpose of AutoIt.

[GlyphMaker]

Yes.

AutoIt is primarily for automating GUI interaction on Windows.

You use Run or RunWait to make programs run. You use MouseClick or ControlClick to select controls on a GUI. You can use WinClose or ProcessClose to close programs.

But for your purposes, I think what you want to do is create small scripts that do a single contained set of actions, instead of a super script that does everything. You compile your scripts into an exe and run it using VB. You can pass any additional parameters you need to give your AutoIt script via commandline parameters.

If all your VB program ends up doing is calling AutoIt scripts, you might as well dispense with VB and just do everything using AutoIt.

Thank you for some specific ideas in relation to my question. Very nice. Again, as I have commented to an earlier reply, it is not sufficient to simply call-up the "third party" programs I've mentioned and let them run the show. They are simplistic, to say the least. There is a lot of analysis taking place in my own code, which essentially conducts an experiment lasting anywhere from minutes to hours, conditionally doing this-and-that and providing a summary of the data. I can clearly see places within my code loops where I would just drop-in a "call AutoIt program and tell it to select output #1 in [such-and-so] program" command then go on with the balance of my measurements. I'd like to know where to go to learn how to do the things you've alluded-to. Again, thank you for your thoughtful reply.

[omikron48]

The help file included with the AutoIt installation includes code samples on how these functions may be used. It also has a language reference that's useful for learning syntax and data types used by AutoIt.

As for tutorials, you can try these:

AutoIt 1-2-3: http://www.autoitscript.com/forum/index.php?showtopic=21048

Learning To Script with AutoIt V3: http://www.autoitscript.com/forum/index.php?showtopic=84960

[GlyphMaker]

The help file included with the AutoIt installation includes code samples on how these functions may be used. It also has a language reference that's useful for learning syntax and data types used by AutoIt.

As for tutorials, you can try these:

AutoIt 1-2-3: http://www.autoitscript.com/forum/index.php?showtopic=21048

Learning To Script with AutoIt V3: http://www.autoitscript.com/forum/index.php?showtopic=84960

Fantastic, Omikron48. I will take a look at these resources immediately. Perhaps tonight I'll be able to finish this task, go home and get some sleep. You are, by the way, helping a man who, besides being a relentless researcher, has a set of quadruplet infants (no fertility drugs, here, no kidding!). Efficiency is not a luxury, when sleep has become such a rare commodity!

You've given me a lead, which I appreciate. I will pursue it.

If I have additional questions, do others recommend that I return to this thread, or is it customary to start another one?

[Inverted]

First do a search, most answers have been answered. Then start a new thread with a good title

P.S.: Quad babies, huh ?

Edited October 2, 2009 by Inverted

[omikron48]

Well, you search if someone has already posted a similar thread. If not, then make a new one if your question is not related to any of your current threads.

If your question is about code, it would be helpful to post some of your code related to your question to make it clearer. There have been times it was difficult figuring out what someone wants done because the explanation provided was either obscure and/or convoluted.

Also, it is highly encouraged for users to learn to code on their own and resort to the forums when they get stuck. Learning is the main goal here. Just asking for code up front is frowned upon.