2016-04-09 Sat

The Microsoft Nanny-State

Back in 1997 Microsoft released its Office products with a common language – Visual Basic for Applications (VBA) – in which programmers could write programs to Do Things with data and with documents and with spreadsheets and the like.

Initial candidates for programs were very short recorded “macros” which paralleled the shortcut keystrokes written for Word perfect 5.1 for DOS, although some smart users realized that Microsoft Word provided something called “AutoCorrect” so that there was no need to write these macros. Still and all they were a good transitioning exercise.

Office ’97 was followed by Office 2000, Office 2002, Office 20003, Office 2007, Office 2010 and I believe that today we are up to Office 2016. Me, I’m still running Office 2003.

Microsoft provided facilities in VBA for the professional programmer (me!) to do some pretty wonderful things. I have written program code that times the duration of the down-stroke of a key on the keyboard, the resting time, and the upstroke, and have thereby implemented biometric passwords for procedures. Not bad for a souped-up typewriter, eh?

I have written code that interprets the position of mouse-clicks on a chart in Excel and responds with a change in the visual effect identified by that code (for videos demonstrating this, please see Video catalogue link here)

Here’s the problem:-

Although Microsoft allows the professional program to pretty well run every aspect of the end-user’s (your!) experience when using, say, Microsoft Word, Microsoft lacked the courage to yield full control to the programmer.

I’m not talking about giving in to the virus-writers here (the last serious Word virus was the Melissa back in 1997, and Surprise Surprise! Since Word97 with VBA came out we haven’t had a serious Microsoft Word virus!

I am talking about the sad situation when professional programmer (me!) offers to write a program to process 10,000 of your documents, automatically, overnight.

I write the program which looks roughly like this:-

For each document

Open it

Process it

Close it

Some of your documents are faulty.

Below are some examples of the kinds of errors that occur when Microsoft Word was asked to open faulty documents:-

Christopher Greaves Home_Logic001.png

Christopher Greaves Home_Logic002.png

Christopher Greaves Home_Logic003.png

Christopher Greaves Home_Logic006.png

Christopher Greaves Home_Logic006b.png

Christopher Greaves Home_Logic007.png

Christopher Greaves Home_Logic008.png

Those of you who have programmed in VBA will recognize that the errors shown above can NOT be trapped by the “On Error” facility in VBA.

They are essentially Untrappable Errors.

Those of you who know me well will know that NOTHING stops me.

If Microsoft says that these errors can’t be trapped, then I’ll find a way to trap them.

And I have!

Email me for details, but essentially you need a second program that notices when the running program is baulked, and cunningly restarts it just past the file that caused the problem.

And yes, I am left with a list of problem-files that I will have to process manually, but at least 9,990 of the batch of files is processed and waiting for you first thing in the morning.

One problem remains:-

Christopher Greaves Home_Logic009.png

Christopher Greaves Home_Logic010.png

Microsoft, in its infinite wisdom, insists on operator intervention at all times, and cannot conceive that a programmer might need to be in control.

The examples above show that Microsoft Word is tenacious in the extreme, and will persist in nagging anyone who will listen that once upon a time, a long, long tome ago (by 2GHz standards) a problem occurred, and By Golly-Gosh, there’d better be a junior clerk reading a book and munching an apple at Basic Wage, employed especially to make an executive decision that a professional programmer is not deemed trustworthy to pre-program.