Visual DialogScript has several features which enable you to control other Windows applications.  One method is to use Dynamic Data Exchange (DDE); however, this requires that the application to be automated is a DDE server, which few are.  The most commonly used method is therefore to simulate key presses and mouse clicks.  There are no hard and fast rules for achieving this and with some applications it can be quite difficult to do.  This section explains the basic principles.

The key to most application automation operations is identifying the window that is the target of your key presses and mouse clicks.  In Visual DialogScript you can use the text in the title bar of the main window, or you can use the window class name.  However, neither of these will identify a specific instance of a window if two or more copies are running, since in many cases the title and class name will be the same for each instance.

If you launch the program you wish to automate from within your script then you can get the window identifier that is allocated by Windows to the instance of the application's window that has just been created.  You can usually do this using the @WINACTIVE function, along the lines of:

%H = @winactive(I)

run myapp.exe

repeat

  wait 1

  %I = @winactive(I)

until @not(@equal(%H,%I))

Once you have got a way to identify your target window, automating it is simply a matter of using WINDOW SEND and WINDOW CLICK commands in your script.

You use WINDOW SEND to send keystrokes to the application.  The command activates the named window, and then sends the keystrokes, which will be directed to the control that has input focus at that time.  The main difficulty is in timing the arrival of the keystrokes, since your program can send them much faster than a user seated at the keyboard would.  You can use OPTION SKDELAY to add a fixed delay between each keystroke, which can make this more reliable.

Mouse clicks can be sent using WINDOW CLICK (or WINDOW RCLICK to send a right-button click.)  As with WINDOW SEND, the command activates the named window to make sure it is fully visible before the mouse click is sent.  To double-click you just use two WINDOW CLICK commands.  To make things easy the X and Y co-ordinates of the pointer are expressed relative to the top left corner of the named window.

The biggest problem with automating applications is the inability of your program to get the visual feedback that a real user would get that an operation has finished and it is alright to continue.  The usual solution is simply to use WAIT commands to allow a long enough period for any lengthy operation to finish.

Any operation that causes another window or dialog box to appear should ensure that it has appeared by testing for it, for example using the @WINEXISTS function.  This function returns the identifier of the window, which will normally be needed if you want to direct any keystrokes to it.

Sometimes you can get information from a field displayed on the window, for example, the status line.  You could do this using the instruction:

%T = @wintext(@winatpoint(%X,%Y))

The @WINTEXT function returns the contents of the text property of the window whose identifier is passed as its argument.  This can be a button caption, the contents of an edit field or label text.  (To understand this it is necessary to realise that in Windows terms almost all the items you see on a screen are in fact windows.)  The @WINATPOINT function returns the handle of the window (or control) at the point specified by variables %X and %Y.  Note that the co-ordinates X and Y in this case are relative to the top left corner of the screen: since the position of a window control will usually be defined relative to the top left co-ordinate of its main window you will need to use the @WINPOS function to find this and then do some arithmetic.

You cannot extract any item of text that you see using @WINTEXT.  It is entirely application dependent.  Be aware, too, that features like user-selectable toolbars or a display mode that uses large fonts can alter the position of the controls you want which can make calculating the X and Y co-ordinates of each control quite involved.  But then nobody said this was supposed to be easy!

The WINDOW SETTEXT command can sometimes be used to set the contents of edit fields, instead of WINDOW SEND.  If you use this, the window identifier must be that of the exact control that is to receive the text, as obtained from @WINATPOINT. 

This method bypasses the normal method of data entry and so may cause problems, depending on how the target application has been written.  It is a case of try it and see.  You can also use this command to change button captions and other normally inaccessible text, though it is difficult to think of a useful application for this.