When considering how to automate something, it’s often worth thinking about whether or not you can change the process a little first.

An example that often comes up is the need to automate the retrieval and processing of a particular email message. Many people will already have a manual process that involves, not surprisingly, their email client, e.g. Outlook. They’ll have a filter set up that moves the email they want to look at into a specific folder. Then they’ll take each of the emails in that folder in turn and do whatever it is they need to do to them, such as pull out some information and put it in an Excel file or database or something.

The user’s first thought when he decides to automate something like this is to have Macro Scheduler manipulate Microsoft Outlook to find the email and parse it.

That’s all very well, and is certainly achievable but it does add a rather awkward obstacle into the mix that needs to be navigated around: Outlook.

Look at what we actually want to do. We have some form of email that gets sent, and we want to parse it and perform some action based on it. Outlook just happens to be what we are currently using to read that email. We’re using it because we’re human and Outlook was designed for humans. But it isn’t the only way to read email. The email exists quite happily without it. We could use a different email client. Or remove the need for an email client altogether.

Macro Scheduler can retrieve email directly from a POP3 server, download the email messages to files and then process them. So we can remove Outlook – or any other email client – from the process entirely.

“Wait”, I hear you say, “What about my other email? I don’t want Macro Scheduler messing up my Facebook notifications, birthday reminders, blog updates and work emails” (notice the order of priority there). Well, don’t worry about that, there are several options. Macro Scheduler’s POP3 commands can be set to leave emails on the server and we could set the script up to search the downloaded email and look for only the pertinent messages.

But Ideally we have control at the sending end. We could set up a dedicated email account which these emails get sent to. That simplifies selecting which email needs to be processed. If that is not possible what about creating a new email account (it could be a free webmail account if you don’t have control over your own mail server) and then set up your filtering rule in Outlook, or whatever client you normally use, to forward the desired emails to that email account? This means the only emails in that account are the ones Macro Scheduler should process, thus simplifying the script which now needs only to collect all email in the mail box and can delete it afterwards.

Of course you can take this concept of removing obstacles as far as you like and in the most ideal world whatever it is that sends emails and whatever it is you want the information extracted from those emails inserted into would have a more direct form of communication between each other. But the world is not always ideal and we don’t always have control over the entire sequence of events. At least consider removing unnecessary obstacles from the part of the process you do have control over.

Retrieving and parsing email is just one example. The concept of simplifying a process applies elsewhere too. E.g. moving and copying files using Windows Explorer: instead of automating Windows Explorer by sending keystrokes and mouse events, use the built in file handling commands; pulling data out of a database: don’t automate your database query tool’s front end, access the data directly using SQL; Getting data from an Excel file: no need to try and manipulate Excel via user simulation, you can query the data directly; and so on.

When you sit down and automate a manual process some of the steps in that process might be things you can replace or skip altogether.

This is a variation of a question we get regularly. Usually it turns out that the script is waiting on a WaitWindowOpen line because of a typo in the window title.

WaitWindowOpen, given a window title, will cause the script to wait until a window with that title exists.

If you misspell the window title WaitWindowOpen will wait forever, because a matching window will never appear.

Rather than rely on your typing, you can select the window title from a drop down list. With the window you want to wait for open on the screen edit your WaitWindowOpen line in the Code Builder by right clicking on it and selecting “Edit in Code Builder”. Now, select the window title from the drop down box.

Remember you can also do a sub-string match using the asterisk:

WaitWindowOpen>Notepad*

This works for all window functions and will match the first window found that contains the given text (regardless of case). So the above will match “Untitled – Notepad” as well as something like “My Notepad – MyFile.txt”. It will stop at the first one found, so don’t be too general and try to find something unique.

More advanced users might be interested to know that we’re adding the ability to use Regular Expressions in the window functions for version 12.