These are my tips for getting started with writing an automation script. While I’m, writing this with our Windows Automation tool, Macro Scheduler, in mind, these tips will be appropriate whichever automation tool you are using.
The most important thing before attempting to write a routine to automate a software process is to be familiar with the process itself. Run through the full process several times and find the simplest path. If you’re using the mouse excessively try to find keyboard alternatives.
Write down every step you take. Make a note of the keys you press, note down the title of each new window and how long each step takes. Try to determine what indicates the completion of each step. Make a note of it. You’ll end up with a list of keystrokes and window titles. This is the basis of your script. You’re now most of the way there. This list will translate well into a Macro Scheduler script.
I find it is best to break the script down into manageable chunks. Don’t try to write the whole thing at once. Start by just scripting the first few steps. E.g. write the code that opens the app, waits for it to be active and sends the first keystroke. Run it and make sure the process ends up where you expected. Tweak it if necessary. Now add the next couple of steps. Run it again. And so on. Building the script up in this way will iron out issues as you go rather than leaving you desperately trying to hunt down the cause of an error amongst one long script. You can also use the debugger to step through the script line by line.
Use SetFocus! When sending keystrokes Macro Scheduler just simulates what you do when you press keys on the keyboard. When you do that the keystrokes land on the active window. So you need to make sure the window you want the keystrokes to land in is the active window. Use SetFocus to do this. Get into the habit of using SetFocus even after running a program with the Run Program command. When you start a program it nearly always becomes the active window, but other applications can steal the focus. So it’s a good habit to get into to use SetFocus before sending a set of keystrokes.
Try not to use absolute wait times to wait for events to complete. The process may take longer on another occasion and fail. Also remember that when you do something manually you will subconsciously wait for the outcome of each action. A script isn’t quite so clever and unless you tell it to wait for certain actions to complete it will blindly move on to the next step. Always use WaitWindowOpen after running a program or sending an event that causes a new window to appear. This will ensure the script waits for that window to appear before continuing. Use WaitWindowClosed after issuing a command that causes the window to close. There are ways to wait for all sorts of other events to take place too, some more advanced than others. You can wait for pixel colors to change, mouse cursors and windows to change, detect object captions and wait for files, and portions of the screen to change amongst other things. When starting an application with Run Program use RP_WAIT=2 to tell it to wait until the application is ready for input before continuing.
Sometimes you do need a small Wait between events. Sometimes you need to slow down the key send rate. Scripts run faster than a human can type and not all applications can cope with that many keystrokes in such a short space of time. So the odd Wait>0.5 here and there can help. You can also slow down the key send rate with SK_DELAY.
When issuing shortcut keys such as ALT-F for the File menu use lowercase for the underscored character. E.g.:
Press ALT
Send>f
Release ALT
I have seen some applications fail to recognise shortcuts when Macro Scheduler sends the character in upper case. This is probably because it treats an upper case character send as having the Shift key pressed at the same time. So I always recommend issuing characters used in shortcut keystrokes in lower case.
It is best to avoid mouse events as much as possible, but if you do find you need to use the mouse for a particular action – maybe there’s no keyboard alternative – try to work out the relative mouse coordinates. Use the cursor monitor, set it to relative, and find the position relative to the window. Then use MouseMoveRel. This ensures that the mouse will always click on a position relative to the window rather than on an absolute screen position so that if the window opens in a different position next time around the macro will still work.
Clearly this article is all about automating via user simulation – by sending keyboard events to applications. Often there are better ways to automate an application such as via VBScript/ActiveX or DDE, or by reading data from files and databases. Before sitting down to automate an application by simulating user input stop to consider whether there are alternatives. For example, I’ve seen people write scripts to automate getting data from Excel by sending keystrokes to Excel to copy and paste. There’s no need to go to this trouble when Excel provides a DDE interface and can also be scripted with VBScript. See the sample script that comes with Macro Scheduler for an example of retrieving data from Excel directly. I’ve even seen macros which get data from a text file by driving Notepad with keystrokes. This is unnecessary and cumbersome when all you need to do is read data directly from the text file with the ReadLn command. If you need to get data from a database, you don’t need to send keystrokes to the query tool – you can read data directly into the script using VBScript/ADO/ODBC. Equally you can automate Internet Explorer elegantly via VBScript/ActiveX or with WebRecorder. There are usually at least two ways to automate something. Before writing your script stop and question whether there’s a better way.
Before writing your first script read Scripting Windows for Beginners in the Macro Scheduler help file/manual.
And browse the examples at the Scripts & Tips forum.
And if you don’t already have Macro Scheduler, you can download a trial version here.
