November 6, 2008

Language Packs

Filed under: Announcements — Marcus Tettmar @ 3:20 pm

Good news: The system used for localizing Macro Scheduler has been updated to work with version 11. I had thought we would need to ditch the current system and replace it with another which would have meant the existing translations would have had to be recreated. But now that we can continue to use the same system the existing language packs will continue to work with v11 and the translators will only need to translate a handful of new strings. I have updated the beta release notes.

November 5, 2008

V11 Beta Update 019

Filed under: Announcements — Marcus Tettmar @ 5:02 pm

Build 019 is now available:
http://www.mjtnet.com/usergroup/viewtopic.php?t=5018

November 4, 2008

Windows 7

Filed under: General — Marcus Tettmar @ 9:19 am

Microsoft have just made the Windows 7 Developer Guide available. It’s more of an overview of the new features with a few screen-shots thrown in. But most importantly Microsoft states that Windows 7 is designed to be compatible with applications and drivers built for Windows Vista. So the good news is Macro Scheduler, which has the Works with Vista logo, should continue to run on Windows 7 without modification. Of course as soon as the Windows 7 beta is made available to MSDN subscribers we’ll be testing it out for sure.

November 3, 2008

Macro Scheduler 11 Beta Build 018 Available

Filed under: Announcements — Marcus Tettmar @ 12:06 pm

Build 018 is now available for download from the registered user area. See:
http://www.mjtnet.com/usergroup/viewtopic.php?t=5018

October 31, 2008

Macro Scheduler Beta 11 Build 017 Available

Filed under: Announcements — Marcus Tettmar @ 5:29 pm

Build 017 has just been made available with the following fixes since the previous build:

– Fixed: News Feed only retrieving from cache until Macro Scheduler restarted
– Fixed: Issue with -NOSYSTRAY

Download from Registered Downloads page.

Asynchronous Processes

Filed under: Automation,Scripting — Marcus Tettmar @ 12:05 pm

The other day a customer had a problem. He wanted to use this VBScript code to trigger macros in Microsoft Excel workbooks. The trouble is that his company’s Excel security settings are set so that macros in non-signed Excel workbooks pop up a warning dialog.

http://www.mjtnet.com/images/xlwarn.jpg

The customer has to click a button to enable macros (or press the ‘E’ key). This dialog holds up the VBScript code until the button is clicked.

He didn’t want to have to digitally sign every single workbook and he wasn’t allowed to change the security settings.

Now, with regular Macro Scheduler code you could start Excel and send keystrokes to it to run the macro and therefore you could have the script send keystrokes to the warning dialog. But if you are using Excel’s ActiveX interface to run the macro via VBScript, the VBScript gets held up by that dialog.

The solution is to use an “asynchronous process” which does nothing but waits for the dialog to appear and then hits the button (sends the ‘E’ key). This process is launched just before the VBScript code that runs the macro is called. Then, although the main script is held up, the other script can cancel the warning, allowing the main script to continue.

We can do this by creating another macro and compiling it to an executable:

WaitWindowOpen>Security Warning
Wait>0.5
Press ALT
Send>e
Release ALT

We compile that code to an executable and then have our main script launch it – without waiting for it to complete – before calling the VBScript code:

VBSTART
Sub RunXLMacro(xlfile,macro)
  Dim xlApp
  Dim xlBook

  Set xlApp = CreateObject("Excel.Application")
  Set xlBook = xlApp.Workbooks.Open(xlfile)

  xlApp.visible = True
  xlApp.Run macro

  xlApp.Quit
  Set xlBook = Nothing
Set xlApp = Nothing
End Sub
VBEND

//Launch the dialog cancel process
Run>%SCRIPT_DIR%\ClearWarning.exe -HIDE -NOSYSTRAY

VBRun>RunXLMacro,C:\Documents\MyWorkBook.xls,SampleMacro

Another way to do this would be to use Macro Scheduler’s Triggers. Instead of writing and launching a second macro, just create another macro and under Macro Properties specify a Window Open trigger. This macro would then detect the warning dialog and clear it. But some benefits of the second “asynchronous” macro process are that you only run it when you need it (you might WANT to have to manually clear the warning dialog when using Excel manually) and it is also portable – you can use this technique with compiled macros that you distribute, and Macro Scheduler does not need to be installed.

Now, as stated earlier, we could have coded the whole thing – open Excel and launch the macro – using regular Macro Scheduler code and sending keystrokes, instead of using VBScript, therefore avoiding the problem. But VBScript is a nice way to run Excel macros, and I’m sure there are other scenarios where the “asynchronous process” technique may be useful.

October 29, 2008

End of Support for Windows 98

Filed under: Announcements,General — Marcus Tettmar @ 11:36 am

With Macro Scheduler 11 we will no longer support Windows 98. Macro Scheduler 11 will not install or run on Windows 95, Me or 98. There are a number of reasons for this, one of which is full Unicode support. Already some of the script commands cannot be used on Windows 98 because they make use of operating system features that did not exist back then. Furthermore, Microsoft stopped supporting Windows 98 in July 2006.

If you need to run macros on Windows 98 you can continue to use version 10.

Macro Scheduler 11 has been tested on Windows 2000, Windows XP (x86 and x64), Windows 2003 Server (x86 and x64), Windows 2008 Server (x86 and x64) and Windows Vista (x86 and x64).

October 28, 2008

Beginner’s Guide Video

Filed under: Announcements,General — Marcus Tettmar @ 4:24 pm

I’ve made a short video version of the beginner’s guide to scripting from the Macro Scheduler help file. It’s basically me running through the tutorial, or a close version of it. So for those who prefer to watch videos than read help files, check it out here. It’s just me. A little rough and ready, but I hope it’s clear enough.

Macro Scheduler Beta 11 Build 016 Available

Filed under: Announcements — Marcus Tettmar @ 3:17 pm

Build 016 has just been made available with the following fixes since the previous build:

– Prevent pressing Del key in search box causing macro delete warning
– Added “News Feed” option to help menus, brings up Macro Scheduler blog RSS feed
– RSS News Feed displayed on startup by default (can be switched off)
– Added link “Beginner’s Guide to Scripting Windows” in the Help menus
– SK_DELAY will now affect Press KEY * N actions
– Fixed: Search was unable to locate text in scripts that were imported but not yet modified
– ReadFile command now correctly reads Unicode files

Download from Registered Downloads page.

As you can see we’ve added a small RSS feed reader to this build. By default it will show when you first open Macro Scheduler. But you can switch this off easily. It is also available from the Help menus. The aim of this is to try and make more people aware of the many articles and resources that are available here as not everyone reads blogs, or subscribes to RSS feeds. Not only that but it will also allow us to keep people more up to date with maintenance releases etc.

October 27, 2008

Top Tips for Reliable Macros

Filed under: Automation,Scripting — Marcus Tettmar @ 11:05 am

Over the years I’ve helped many people improve their automation scripts. The most common two causes of scripts failing to work correctly and consistently are timing and focus issues. Here I’ve tried to summarise the main things you should do to make your scripts more reliable.

Try to avoid mouse clicks.

Mouse clicks require screen positions and while there are ways to specify window relative positions, or find the position of objects, if you can use the keyboard instead, it’s a lot less hassle. And most of the time you CAN use the keyboard instead of the mouse. You can TAB from object to object, field to field. You can press ALT to see the shortcut keys and select menu items and click buttons. You can toggle radio boxes with the SPACE bar. You can CTRL-TAB through tab pages. You can position the cursor, highlight text and copy to the clipboard, all with the keyboard. You can often select an item in a list box or combo box simply by typing the item you want to select.

For more info on keyboard shortcuts see:
http://www.mjtnet.com/blog/2006/01/16/keyboard-shortcuts/

Don’t automate mouse clicks or keystrokes just to start an application!

I’ve seen people write code to locate a desktop icon, then double click it, and even double click on a Windows Explorer icon, click through a series of folders and finally double click on an EXE. While this may work just fine, it’s rather long winded and seems a bit pointless when you can run an app with just one line of code. A desktop shortcut is just a shortcut to another file, usually an executable, sometimes with command line parameters. Right click on the shortcut and select Properties to see the target. Copy that and paste it into a Run command. E.g.:

Run>"C:\Program Files\Mozilla Firefox\firefox.exe"

One line of code is much easier to read, easier to maintain later and easier to debug. It’s also faster.

The other day I saw a Citrix app which the user would normally start by double clicking on the desktop icon which would present an Explorer style window appear. The user would then select one of the apps from the list in the Explorer Window. Rather than use image recognition to find the icons and send a bunch of mouse clicks we found that if you right click on one of the apps you could create a desktop shortcut. We did that and examined the shortcut to see what the actual command line was to run that app. We probably could have read the docs instead but we used the desktop shortcut to tell us and simply copied the target into Macro Scheduler, before deleting the desktop shortcut. We now had one line in Macro Scheduler to run the app directly.

How to automate a Save As or File Open dialog.

Need to manipulate a Save As or File Open dialog box? It seems many people think you HAVE to use the mouse to click through a series of folders to find the location of the file. WRONG! Ignore the folder browse area of the file dialog. All you have to do is type a full path into the file name box and hit Enter. Doesn’t matter what the current folder is that the dialog is showing you. Just type the path of the file you want:

WaitWindowOpen>Save As
Send>g:\some folder\some sub folder\some file.txt
Press Enter

That’s it! No mouse clicks necessary!

Make the script wait for events to complete.

Remember – scripts run faster than humans can type! Unless you build delays into the script it’ll just issue each step milliseconds after the last one. But apps are designed for humans who type more slowly and subliminally wait for events to complete – we don’t start typing into a window until we can see the window on the screen. We know that when we select File/Save As we need to wait for the Save As box to appear before we can enter the filename. So we need to make scripts do the same thing.

The most important command you should use in EVERY script is WaitWindowOpen. Whenever we issue a command which will make a new window open, use WaitWindowOpen to make the script wait for that window to appear before it continues:

//select File/Print
Press ALT
Send>fp
Release ALT

//wait for the print dialog
WaitWindowOpen>Print

//Press enter key
Press Enter

Without that WaitWindowOpen command the Press Enter will most likely be sent long before (in computer time) the print dialog has appeared. So the document won’t print.

Equally, use WaitWindowClosed when you do something that causes the window to disappear.

Sometimes it’s not a window you need to wait for, you might want to use WaitScreenImage to wait for any visual cue, or WaitScreenText, or WaitCursorChanged. Or you might need to wait for a file to appear, so you might create a little loop with IfFileExists in it …. it could be anything. Determine what events the script needs to be aware of and make it wait for them.

Be Specific.

The window functions can take an asterisk to look for a substring match for situations where the window title is not static, or not completely known. E.g.:

WaitWindowOpen>Internet Explorer*

But try to be as specific as you can. There are many hidden windows on your system so if your text matches one of those first it’ll stop at that one, not the one you want. Make the text more specific if possible, and/or use WF_TYPE to make Macro Scheduler look for only visible windows.

As an example, the following could return too quickly:

WaitWindowOpen>Microsoft Excel*

Why? Because “Microsoft Excel” is the window of the container application. But just after Excel starts you’ll see a window title something like “Microsoft Excel – Book1”. When the app starts, for a split second, faster perhaps than you can detect with the human eye, the window title might first be “Microsoft Excel” and THEN “Microsoft Excel – Book1”. So the above WaitWindowOpen line might return too quickly. You might not know what the first workbook will be, but you could do:

WaitWindowOpen>Microsoft Excel -*

Be as specific as you can for the final window title that you expect to see before you start automating it.

Slow scripts down! You can always speed them up later.

So you’ve followed the above advice and you’ve made the script wait for events to complete. You may still need some small delays. Let’s say you’re sending a bunch of keystrokes to a form, you’re tabbing through a window sending data to each field:

Press Tab
Send>Firstname
Press Tab
Send>Surname
Press Tab
Send>address
...

It’s not working? It works sometimes but not others? Here’s what is happening. The app is being overwhelmed by those keystrokes. It might do some “OnChange” style processing – as text is entered into a field it could be doing some processing internally. As mentioned before the script runs way faster than a human can type. The text is being sent to the app too fast. In real life there’d be a short delay between fields. So slow the script down and give the app a bit of a chance to catch up:

Press Tab
Wait>0.5
Send>Firstname
Press Tab
Wait>0.5
Send>Surname
Press Tab
Wait>0.5
Send>address
...

Half a second is probably all you need. It may not even need to be that much. But I always recommend that while you are developing a script and testing it you should err on the side of caution. Use plenty of waits. Get the script working. You can always reduce the waits later once you know it’s working. And if your script is going to be run unattended, say at night, then does it matter if it takes 5 seconds longer? Who’s watching it?

You can also use SK_DELAY to slow down the key send rate where you are sending characters together. SK_DELAY takes milliseconds:

Let>SK_DELAY=20
Send>Hello World

Sometimes you need to press tab a number of times to get to a field so you might do:

Press Tab * 6

But this sends the tabs in quick succession, and as I’ve said, the app may be requiring a bit of time between fields. So you might need to do the following instead:

Let>k=1
Repeat>k
  Press Tab
  Wait>0.2
  Let>k=k+1
Until>k=6

Make sure the correct window is focused!

When you press a key on the keyboard that keystroke will land in whatever the active window is. That’s the way your computer works. If Notepad is active and you type “Hello”, you’ll see “Hello” inside Notepad. If some other app is active … I don’t know what “Hello” would do in ficticious app number 2! Macro Scheduler controls your computer, so the same thing happens. That’s the way your computer works. So when you make Macro Scheduler send some text you’re going to want to make sure the correct window is focused first:

SetFocus>Notepad*
Send>Hello World

Build scripts in chunks.

When I develop a new macro I do it a few lines at a time. The first thing I might want the macro to do is open an application and wait for it to be ready. So I’ll do that bit manually and work out what paths, window titles and keystrokes I need to make that happen. I’ll write those lines of code. Then I’ll run the script and see if it gets me to where I want to go. Once those lines are doing the right thing I can work on the next phase. I’ll do a few more steps, add those to the script, then close the app down and run the script again.

Don’t try to build everything in one go, break the routine down into chunks and work build it up slowly.

Use the debugger!

The debugger is your friend. The debugger lets you step through the script line by line and watch the script working. You can see the value of variables as they are created and modified. So you can see just what each line is doing and find problems instantly. For a tutorial on using the debugger see:
http://www.mjtnet.com/blog/2006/05/17/use-the-debugger/

There’s also the variable explorer (Tools/Variable Explorer). Quite handy for finding variable related problems without having to run the script.

___
More resources:
http://www.mjtnet.com/blog/2006/01/17/how-to-start-writing-an-automation-script/
http://www.mjtnet.com/blog/2008/03/21/round-up-of-learning-resources/

« Newer PostsOlder Posts »