Jump to content
Sign in to follow this  
coghlan

Can AutoIt send 1000 screens of data reliably?

Recommended Posts

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???

Share this post


Link to post
Share on other sites
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? :P

[/sarcasm]

It is a poor craftsman who first questions his tools.

Are YOU up to the task??? ;)

Oh, yeah... and Welcome to AutoIt! :)

Edited by PsaltyDS

Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites
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??? :P

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.

Share this post


Link to post
Share on other sites
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...

:P


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×