Can AutoIt send 1000 screens of data reliably?

[coghlan]

I'm thinking of dumping a large flat file (rows of xxx yyy zzz ...) and wrapping function calls around the info to create a script to simulate the entry of all this data into a 3rd-party app. via ControlClick, ControlSend etc.

Can I reasonably expect the communication with the various controls to be reliable, with no lost messages (e.g. if I overrun the app. with too much info)?

What are the tricks for keeping the communication reliable (waiting for windows to become active etc.)?

The reason I ask is that, after experimenting with AutoIt for a couple of days with a script to open/enter/save <n> items, e.g.:

AddMyItem( "Group I" ) ; Function which interacts with one or more application screens to create "Group I"

AddMyItem( "Group II" )

I experienced such things as some of the data being seen by the app. in the wrong case (g vs G) as well as the app. thinking the same data was being entered in an edit control (on the 2nd object "Group II", the app. asked if I wanted to replace "Group I").

I want to do a one-time large-scale data migration (thousands of data items) from one app. to another, and naturally can't tolerate more than 1 or 2 hiccups.

Is AutoIt up to the task???

[PsaltyDS]

I'm thinking of dumping a large flat file (rows of xxx yyy zzz ...) and wrapping function calls around the info to create a script to simulate the entry of all this data into a 3rd-party app. via ControlClick, ControlSend etc.

Doable, easy, exactly what AutoIt is for.

Can I reasonably expect the communication with the various controls to be reliable, with no lost messages (e.g. if I overrun the app. with too much info)?

What are the tricks for keeping the communication reliable (waiting for windows to become active etc.)?

A loaded question. It will be as reliable as you code it to be. If your script should "overrun the app", then you script was poorly coded for that app. AutoIt is not a blind MouseMove/Click/Type/Click language. At every step you can test for success before going on.

Now, there are exceptions. There are a few special types of windows (ColdFusion Flash dialogs are my bane at work) that are completely opaque to AutoIt because they don't use Windows APIs to draw their controls.

The reason I ask is that, after experimenting with AutoIt for a couple of days with a script to open/enter/save <n> items, e.g.:

AddMyItem( "Group I" ) ; Function which interacts with one or more application screens to create "Group I"

AddMyItem( "Group II" )

I experienced such things as some of the data being seen by the app. in the wrong case (g vs G) as well as the app. thinking the same data was being entered in an edit control (on the 2nd object "Group II", the app. asked if I wanted to replace "Group I").

AutoIt does not, in my experience change case on anything. Since you didn't post any code, there's no telling what you did wrong. As for the responses of the app -- they are entirely up to the app. You should be able to get the exact same response with AutoIt, however, as you get manually with mouse and keyboard.

One common noob mistake (which I made myself several times), is to not read the help file and miss things like how Send("+g") reacts (that is actually '<shift>g', and so winds up 'G').

I want to do a one-time large-scale data migration (thousands of data items) from one app. to another, and naturally can't tolerate more than 1 or 2 hiccups.

Is AutoIt up to the task???

[sarcasm]

And I have OpenOffice.org Writer on my computer, with which I need to write like C.S. Lewis. Do you think OO.o is up to the task?

[/sarcasm]

It is a poor craftsman who first questions his tools.

Are YOU up to the task???

Oh, yeah... and Welcome to AutoIt!

Edited November 20, 2007 by PsaltyDS

[coghlan]

Doable, easy, exactly what AutoIt is for.

A loaded question. It will be as reliable as you code it to be. If your script should "overrun the app", then you script was poorly coded for that app. AutoIt is not a blind MouseMove/Click/Type/Click language. At every step you can test for success before going on.

Now, there are exceptions. There are a few special types of windows (ColdFusion Flash dialogs are my bane at work) that are completely opaque to AutoIt because they don't use Windows APIs to draw their controls.

AutoIt does not, in my experience change case on anything. Since you didn't post any code, there's no telling what you did wrong. As for the responses of the app -- they are entirely up to the app. You should be able to get the exact same response with AutoIt, however, as you get manually with mouse and keyboard.

One common noob mistake (which I made myself several times), is to not read the help file and miss things like how Send("+g") reacts (that is actually '<shift>g', and so winds up 'G').

It is a poor craftsman who first questions his tools.

Are YOU up to the task???

Oh, yeah... and Welcome to AutoIt!

Thanks.

Overall, I'm impressed with the simplicity and power of this tool. I have to convince some co-workers that this is a viable alternative to writing lots of SQL scripts to poke directly into what are probably some very complex tables, so I'm just doing my homework to explore the commercial quality of AutoIt.

I'll try some more experiments today to ensure I'm not sending to non-active windows etc.

[PsaltyDS]

Thanks.

Overall, I'm impressed with the simplicity and power of this tool. I have to convince some co-workers that this is a viable alternative to writing lots of SQL scripts to poke directly into what are probably some very complex tables, so I'm just doing my homework to explore the commercial quality of AutoIt.

I'll try some more experiments today to ensure I'm not sending to non-active windows etc.

Since it can use COM objects or run OSQL command lines, AutoIt can poke directly into SQL tables too...

[Confuzzled]

Have you considered reformatting your data so you can import it directly to the application, using the tools the original developers probably spent a lot of time testing and making bulletproof?

Don't forget to check data integrity - the mess a poorly formatted input can do to a fully automated program can take longer to fix than doing the transfer manually. Better write a lot of tests into your code and have it run longer than try and fail.

Make sure you have a verified backup of your data before you start and can revert to it easily if something does goes wrong.

You haven't shared the name of the application with us, or what it is written in if it is in-house.

...Thinks back to the Y2K conversion era when these issues were commonplace...