Marcus' Macro Scheduler Blog

If you work regularly on large macro files you should consider using a version control system. Remember that time when you made a few small changes to that 2000 line macro and it stopped working and you spent ages trying to figure out what you did and get it working again, losing a lot of hair in the process? Ok, so you had a backup right? But what if you needed to get back to a version from before the backup – and quick?

Macro Scheduler’s advanced editor gives you a “Backup on Save” option. This keeps the last three copies of each script each time you save. If you look in the script’s folder you will see a .001, .002 and .003 file as well as the main .scp file.

But you may want more control than this. You might want to look at the code as it was three months ago. And if you distribute compiled macros to clients you may need complete version control. With a version control system you can create branches from your main code. Let’s say you create a utility which you sell to your clients. When you release version 2.0 you might still want to support version 1.0. If a customer using version 1.0 finds a bug you need to fix that bug in the version 1.0 code without them having to upgrade to 2.0. Or you may create customisations for different clients. A client may need some changes but you don’t want those changes in the main code base. Or perhaps you have more than one person working on your script files and you need a way to keep your changes in sync.

With a Version Control System you “check” files in and out of the “repository”. So when you’ve done making changes to a script you can “check” it in. The VCS adds this change as a new version. Later you can check it out. Normally you’d work on the “HEAD” – the most up to date version. But if you need to go back to a previous version you can choose to check out a different version. You can see all the versions in the repository. When you check a file in you would normally write a short note as you do so, so you know what changes you made. So by using a version control system you have a complete track of all the changes you ever made, and you can get back to a previous version easily and safely.

This is when you need a version control system. We use TortoiseSVN here to manage the Macro Scheduler source code. You could use it for your Macro Scheduler script files too. In fact you can use version control for pretty much any kind of files you work on regularly.

You can find our more about TortoiseSVN here: http://tortoisesvn.net

TortoiseSVN integrates directly with Windows Explorer. It’s really easy to check files in and out just by using Windows Explorer. The help file that comes with TortoiseSVN is helpful with a good introduction if you’re a newbie, and provides some tips on how to set up your repository.

If you’re new to version control here’s a really nice visual guide:
http://betterexplained.com/articles/a-visual-guide-to-version-control/

For those of you who work regularly on large script files for multiple clients – and I know a number of you do – you should think seriously about using source control.

A customer just reported this issue:

http://www.mjtnet.com/usergroup/viewtopic.php?p=17969

Seems Kaspersky must be intercepting emulated keystrokes and is slowing their progress. I’ve emailed Kaspersky to ask for a resolution. Until then if you are running Kaspersky Internet Suite you need to close it down completely to prevent this issue.

Quite rightly you should be running a security solution. We run AVG Antivirus and Webroot Spy Sweeper on our machines here. Neither affect Macro Scheduler in any way.

Sometimes I wonder if Macro Scheduler has outgrown its name. “Macro” seems too small a word, and “Scheduler” is just one small feature. It’s so much more than these two words suggest now.

When version one was released there were less than 20 commands, purely for simulating user input and manipulating windows. No script editor, just a drop down list to select the few commands you needed. And a scheduler. Macro Scheduler was the perfect name. People used it to write macros and schedule them.

Fast forward ten years and Macro Scheduler’s script language, which we call MacroScript, is now vast, with all kinds of functions, looping constructs, conditional statements, subroutines, internet functions, etc. It has a dialog designer for creating user interfaces, embedded VBScript, see-screen image recognition, a debugger, DLL functions you can use to run functions in custom DLLs and Windows API functions, and a full featured editor. There really is nothing it cannot automate. I know people who have created routines over 5000 lines long. The emphasis now must surely be on the word “automation”. But at the same time it has got easier to use.

One feels the word Macro just doesn’t do these capabilities justice. I also wonder if first time visitors might initially make the mistake of comparing Macro Scheduler to other products which are more basic.

But what’s the solution? Change the name? I’m loathe to do that for a number of reasons. There’s ten years of history, loyalty, word of mouth and Google-juice in the name “Macro Scheduler”. No way should we drop the name altogether. Or maybe we should leave Macro Scheduler where it is but start a new branch of the product with a new name? I don’t know. I do know that the word macro is searched for on Google many many times more than the word automate. So perhaps we should leave things be? I also know that Macro Scheduler is a very capable product and we want people to realise that. I don’t want the name putting anyone off.

The other day I was talking to someone at one of the largest utility companies in the USA. She told me that her IT department uses HP’s WinRunner product for automation but they were unable to get it to automate one particular piece of software. WinRunner costs thousands of dollars. She found Macro Scheduler and was very quickly able to use it to automate this tricky application. Other customers report similar stories. Well I guess the name didn’t matter in this case. She found our product and it proved itself.

So does the name matter?

What is it with the packaging you get computer stuff in?

This is that horrible thick plastic stuff. You almost need a hacksaw to get into it. I just about managed with a pen knife. And you have to be careful – this stuff is sharp. There’s more plastic in the packaging than the product in this case. Not exactly environmentally friendly. A cardboard box would be perfectly adequate.

If you haven’t already heard about the Excel bug, open up Excel 2007 and try multiplying 77.1 with 850:

=77.1*850

Clearly that should give you 65,535. But Excel 2007 returns 100,000. Oops.

It turns out it’s just a presentational bug. The displayed result is wrong, but the underlying value is correct. If you were to create a graph or access the value from VBA, you’d get the right result. Read Joel’s post for a clear explanation of why this is.

Speaking of Office 2007, I had a near disaster with Outlook today when it refused to work. It crashed on startup, and kept trying to restart itself, only to crash again. Got it sorted in the end. But I’ve been meaning to implement a decent backup solution for Outlook since I switched to it a few months ago. So today I installed BackupOutlook from our friends at Wisco. Does the job nicely. If you’re looking for a decent Outlook Backup tool you should check it out.