Marcus' Macro Scheduler Blog

Here’s a quick video showing how easy it is to use Macro Scheduler‘s image recognition to control a Linux Desktop (Ubuntu in this case):

Every now and then someone will email us to let us know that they have overwritten one of their important scripts and now need to recover their old work. They write asking what we can do about it.

Well. Not much really. If the script wasn’t backed up and has been changed we can’t somehow get back the old version.

I’m always amazed at how few people seem to backup their work. Whether it’s a Macro Scheduler script or a Word document. Back it up.

Macro Scheduler stores scripts by default in a folder beneath the My Documents folder which is a default location for Windows Backup and other backup tools. So there’s not much excuse for not having a back up. Yet we meet people all the time who simply don’t back up.

For a while now Macro Scheduler has had a “Backup on Save” option which keeps the three most recent copies of scripts. But you have to switch it on.

And people still email us reporting lost data.

So with version 14 this Backup On Save option will be enabled by default. It will keep 5 copies by default and you can increase this number if you want. The main Macro Scheduler data files will also be backed up on startup.

I also recommend using source version control for important script projects.

Heaps of snow here this morning. Will be working from home today! My home office looks more like Santa’s Grotto:

Gotta love Amazon. Received the following in an email today 18th October. I have removed identifying info. Emphasis mine:

date: 18 October 2012 11:53
subject: Your Amazon.co.uk Enquiry

I’m sorry to hear that you haven’t received your order ############# yet.

I’ve checked and can see that it was sent via DPD_24_PRIME to the following address:

redacted
redacted
redacted

The estimated delivery date given for this order last 17 Oct 2012

Your order is still in transit and I’m confident that it’ll arrive by the estimated delivery date. You can confirm the estimated delivery date by visiting the “Your Orders” section of Your Account or by clicking on the following link:

https://www.amazon.co.uk/gp/css/history/orders/view.html

Awesome!

Despite our FAQs we get asked a version of the following question at least once a week:

“I just wrote my first macro with Macro Scheduler and it works great but if I lock Windows it stops working, is this a limitation of the trial version”.

My most recent answer to this was as follows:

No, it’s a limitation of how Windows works. I assume that your script needs to simulate a user (i.e. send keystrokes and/or mouse events and needs to “see” windows).

When Windows is locked or logged out *windows cease to exist* and *there is no input console*. Ergo you cannot simulate a user when Windows is locked or logged out. There is nothing anyone can do about this as that is simply the way Windows works.

A more detailed and technical explanation of this can be found here:

http://www.mjtnet.com/msfaq171.htm
http://www.mjtnet.com/msfaq17.htm

Think about it for a second – can YOU use Windows when it is locked or logged out? Of course not. But most people don’t realise that when you lock or log out of Windows the user’s “window station” literally no longer exists, and applications no longer have UIs. While a process may exist, it has no windows and UI objects simply aren’t there. So there’s nothing to interact with. Furthermore the only thing that has keyboard/mouse focus is the security console. So you cannot send mouse/keyboard events.

So in short you cannot automate user interfaces when Windows is locked or logged out.

Command line tasks, and tasks that do not need to access a user interface (interact with windows) may still be possible assuming they do not require logged on credentials.

The only solutions are:

1. Leave Windows logged in
2. If you are running Vista/Windows7/2008 Server you can use Macro Scheduler’s AutoLogon system. See under Macro Properties. This will log Windows back in on schedule, run the macro, and then log out again.

We have a growing list of freelance script developers which we draw from whenever we receive a request for local assistance. If you are a freelance script developer and would like to be considered for potential projects please drop me a line with your details and a summary of your experience so that we can add you to the list.

Every now and then someone asks whether Macro Scheduler works on 64 bit Windows and if there are any implications. Another question that comes up very occasionally is “Why no 64 bit build of Macro Scheduler?”

Well, first of all, yes, Macro Scheduler runs on 64 bit versions of Windows and it can control and automate 64 bit applications. There are very few implications to be aware of and the vast majority of people will never need to worry about them.

What are these implications?

1. File System Redirection for Processes living in the System Folder

As Macro Scheduler is a 32 bit application if you try to execute a process that resides in the System32 folder by specifying System32 in the path Windows will force Macro Scheduler to look in the 32 bit subsystem folder instead. This is Windows\SysWow64.

Sound confusing? Blame Microsoft. The System32 folder has remained System32 even on 64 bit versions, and the 32 bit versions of system processes/DLLs are in Windows\SysWow64. Since a 32 bit process cannot load a 64 bit DLL Microsoft uses something they call “File System Redirection” to redirect 32 bit apps to look in Windows\SysWow64 to prevent errors when loading system DLLs.

The only time this might affect you is if you specifically want to execute a .exe or load a file which lives in System32 and there is no 32 bit equivalent and/or you really do want to run the 64 bit version. This is rare for the large majority of users. But some of you system administrators may very occasionally want to do this.

The solution is simple. With Macro Scheduler 13 simply refer to the file using the SYS_NATIVE variable which returns an alias to the *native* system folder which will not get redirected (rather than the SYS_DIR variable which will return the system32 folder name which will be redirected to SysWow64). Specifying the literal C:\Windows\System32 path will also be redirected and is not sensible anyway, as these folder names aren’t necessarily fixed (and may not be on drive C) – use the variables. SYS_NATIVE is simplest and is also portable since it will work on 32 bit windows.

Another way to do it is to disable file system redirection which can be done with the Wow64DisableRedirection command. But, very important, remember to renable it with Wow64EnableRedirection. A safer way is to set the RP_WIN64PROCESS variable to 1 before your RunProgram call. This will disable redirection for only all subsequent RunProgram calls rather than the entire process.

Personally I’d go with SYS_NATIVE.

Remember, we’re only talking about the need to run files which live in System32. You need not do anything special for other 64 bit processes. It is simply that Windows will divert you away from System32.

File System Redirection is explained in more detail here.

2. The 64 Bit Registry Hive

In a similar way, calls by 32 bit processes to some parts of the registry may be redirected. This is explained here. If you specifically want to access the 64 bit version of a registry key you need to set REG_64 to 1 before a call to one of the Registry functions.

That really is it. Both situations are rare for the vast majority of users who are automating end-user applications. Only a small minority using the software for really low level system administration tasks may need to be aware of these things.

Wouldn’t a 64 bit version of Macro Scheduler solve this?

This is another way of asking “Why isn’t there a 64 bit version of Macro Scheduler?”. Well, while a 64 bit version would solve these two rare cases, it would also, by extension, turn the two cases the other way around and create another problem. While it would automatically see the 64 bit System folder, you’d have to set a flag or use another variable to make it go to the 32 bit subsystem if you needed to. Same again for the registry.

So you see there is no gain. No difference. It just turns things around. There are more inconveniences with a 64 bit version.

The vast majority of applications out there are still 32 bit. The vast majority of things our customers are automating are 32 bit. Macro Scheduler can control and interact with both 32 and 64 bit applications interchangeably. It is very rare that anyone would ONLY be interacting with 64 bit processes. More often than not if you are needing to control a 64 bit app it is probably when you also need to control a 32 bit one. So support for both, at the same time, is more important.

Our text capture libraries rely on system level hooks which hook various text out calls. Therefore they need to have separate hooks for 64 bit apps and 32 bit apps. Previous versions of Macro Scheduler only had a 32 bit hook. This meant we could only get text from 32 bit processes. With the new version we included a 32 bit hook and a 64 bit hook with a 64 bit proxy allowing the 32 bit hook to get text from 64 bit applications.

Now, if we made a 64 bit version of Macro Scheduler you could get text from 64 bit processes, but if you also wanted text from 32 bit processes you’d need things the other way around (again, no gain or difference). Or we could have offered two versions of Macro Scheduler which could ONLY get text from apps of the same bitness. Since most people need to control both or need to control 32 bit apps running on 64 bit windows and may need to get text from the system as well as the 32 bit app, that wouldn’t help them.

So rather than offer two versions which would be limited or would still need to do special things in certain circumstances, right now it seems safer and simpler to continue to offer the 32 bit version, with the 64 bit text capture proxy, which can automate and control both types of processes. It is much better for us to provide and support one build which works in all situations.

And whichever way we go there is no getting round the redirection issues one way or another. This is not unique to Macro Scheduler: whatever programming language you use you need to explicitly tell it if you want to avoid the redirection issues (whichever the direction).

So hopefully you can see that there’s no real benefit in offering two different versions.

The Future

We’re always monitoring the way things are going. One day the situation might be reversed and the majority of applications may become 64 bit.

We can already create 64 bit builds. If we perceive a NEED we’ll publish it.

In the mean time if you think you NEED a 64 bit only version, drop me a line and explain why and we can get you a custom build, if you do really, really need it.

Just had to share this great feedback received from Antonius Momac of TriplePoint Technologies who has given me permission to share:

Time to fess up; I haven’t upgraded since version 10, and that’s because 10 is THAT good, but I wanted to take advantage of Easy patterns, and the New Event functions.

WOW!!! I can’t believe there have been so many awesome improvements. I’m so happy right now; discovering so many clever functions and all the integrated tool/builder add-ons. The workflow is *KICKASS*; I mean, listen: I was happy and set in my ways, but it only took one spin of the new image recognition wizard to change my thinking.

Image Recognition is a key function, but time consuming to set up and hard for newbies to get right. With the wizard however, its so streamlined (3x faster for me) and painless that I’m going to use it much more often. GREAT JOB Marcus and team!

I can’t wait to explore all the new features. Macro Scheduler 13 is like getting a Porsche 911 for the price of a honda civic si…

Antonius Momac, TriplePoint Technologies