You may already be familiar with the Macro Scheduler debugger and know how to set code breakpoints. But did you know you can set variable breakpoints too? With a variable breakpoint you can cause execution to pause when a specified variable becomes equal to a given value.
You will find the “Variable Breakpoints” option under the “Debug” menu in the code editor.
You can set one or more variables and values. Then at any point during execution when one of those conditions occurs the macro will pause and allow you to debug.
This can be very useful when you are not sure where an issue is occurring but you may know that a specific set of data causes a problem that you want to debug.
So it’s Black Friday. Sounds so gloomy. A day where many appear to go mad and gorge.
There’ll be no extra discounts from us today, but what we will do is donate 10% of today’s sales to The Woodland Trust and St Mungo’s charity for the homeless.
So if you buy or upgrade Macro Scheduler today, or renew your maintenance you’ll be planting some much needed trees and providing for people who really need stuff.
In this video I demonstrate how to use IE’s F12 key to invoke Developer Tools and use that to quickly find the elements we’re interested in and the attributes we need to use:
(You might want to click on the video toolbar to select a larger resolution size, view full screen or view on YouTube so that you can see the code).
Macro Scheduler‘s ReadFile and ReadLn functions understand ANSI, UTF8 and Unicode files – as long as they have a valid BOM header. But a client recently needed to read in a file with a missing BOM. So we wrote a little bit of VBScript which reads the binary stream in, and then outputs a UTF8 encoded file.
Here’s the code:
VBSTART Sub UTFConvert(filename) Set fso = CreateObject("Scripting.FileSystemObject") txt = fso.OpenTextFile(filename, 1, False, -1).ReadAll Set stream = CreateObject("ADODB.Stream") stream.Open stream.Type = 2 'text stream.Position = 0 stream.Charset = "utf-8" stream.WriteText txt stream.SaveToFile filename, 2 stream.Close End Sub VBEND //Convert it to UTF8 VBRun>UTFConvert,%SCRIPT_DIR%\data.txt //Now we can read it ReadFile>%SCRIPT_DIR%\data.txt,theFileData
Allow me to tell you about a fun new technology called Chirp created by some good friends of ours.
Chirp is an exciting new technology that shares information between devices using sound and you can try it out for yourself.
Chirp works by using little more than your device’s speaker and microphone. Data is encoded into a sound which is then “chirped” over the speaker. Another device or devices within earshot will “hear” that sound and decode it.
The beauty of this is that it removes all technical obstacles to sharing data (no need for infrared, or setting up bluetooth etc) and makes it possible for the most basic devices (think Arduino boards, toys, TVs, games etc) to chirp without any special hardware. And it means that one device can very easily share data with multiple listening devices.
You can share URLs, notes, images and video between devices – and now from your desktop web browser. College lecturers and presenters find it very useful for sharing links to websites, slides and presentations to their delegates, without having to collect email addresses or use any special infrastructure.
You can download the free Chirp app from the Apple Store or Google Play to see it in action. It’s great fun! There’s also a Chrome Plugin which makes it a breeze to share links from your web browser to your phone/tablet.
And if you want to make your own apps chirp there’s an SDK you can get your hands on too. I had some fun not long back making a Lego EV3 Robot chirp. Why not!? Anyone for a Macro Scheduler -> Chirp Interface?
And if you like what you see why not get in on the action – Team Chirp are currently crowd funding to raise money to take Chirp to the next level and are exploring commercial opportunities – so you can even make a little investment.
This feature makes it easier to work out which bit of code does what as you can see the screenshots inside the script:
Note the thumbnail images in the script. To view a full sized version – as in the example above – double click on a thumbnail.
This feature is on by default but can be switched off before you record a macro by toggling the “Take Window Snapshot Images” option on the macro recorder settings dialog.
“It can’t be done.”
We’re always meeting people who have been told by consultants and technical folk that moving data from one application to another can’t be done.
We prove them wrong every time.
One of the most popular uses for Macro Scheduler within corporations is automated data entry. Time and again we learn about projects where systems are replaced and renewed but gaps still exist which need to be bridged by manual “rekeying”.
In an ideal world there will be an API, database access, or an interface to export/import data files. But the reality is we still don’t live in an ideal world.
Surprisingly often, especially with older legacy systems, none of these things exist. More often than not they are technically possible, but for various reasons just don’t get implemented. It might cost too much, system vendors may not be willing to open up their technology, IT staff may be too busy on other projects.
And quite often it seems that IT departments are busy working on the “big picture” and consider these “rekeying” jobs too small to worry about.
Taken in isolation the fact that one person in one department might be rekeying patient records, or invoices once a month for three hours might seem a trivial problem. But it’s not just one person in one department. In our experience every team throughout an organisation has someone doing something like that. Added up the total time wasted by the organisation is huge. More often than not these people are being taken away from more productive work.
As an example consider a hospital we are currently helping.
Hospitals are huge organisations, with hundreds of departments and all kinds of systems where for all kinds of reasons people are keying data into one system that was extracted from another.
In a few days we’ve already helped four departments remove the need for monthly manual data entry jobs. In total this must be saving at least 2 man-days per month. In actual fact what it really means is that the clinicians who once had to do this work can now treat two or three more patients a month each.
And this is just the tip of the iceberg.
It may seem like small gains. But we have only just got started and I’m quite sure that every department has at least one person doing manual work that they don’t need to do. In this age of austerity and cost cutting it is fantastic to see the hospital making lots of small efficiency gains that together make a big improvement.
The trouble is that most people don’t realise that what they are doing can be automated.
Most of our customers are an exception, and the IT guy at the hospital thought outside the box and found a solution.
But most people are told “it isn’t possible” so carry on tapping away at the keyboard.
Most IT people, bless them, sometimes think too technically. It’s understandable. So you ask IT “can we automate this data entry procedure” or “can we connect these systems” and words and abbreviations like API, SOAP, XML, SQL will fill their heads, and they’ll come back and say “No sorry, can’t be done”. If you’re lucky someone will contact the system vendor who will naturally want payment for building a custom interface and then it will turn out that the vendor of the other system needs to be involved, or a new module needs purchasing, or someone needs to go on a training course, and all of a sudden it’s looking far too expensive and going to take far too long, to make it justified. So the conclusion is it isn’t possible.
But if you’re reading this blog you know there IS another way to do it.
We CAN automate data entry at the user interface level. And it CAN be made reliable and robust.
Is it the most ideal solution? Some would say not. But are we living in an ideal world? No.
We can demonstrate, our customers can demonstrate that it works. It allows the process to get automated quickly, without specialist technical resource, without reliance on the system vendors or even the IT department and without a large investment. For a relatively tiny outlay the invoice clerk’s life can be transformed, the human resources department can avoid rekeying appraisal data every month and clinicians can stop doing tedious tasks and get back to doing what they love, what they’re best at and serving the community.
I heard about a project in another public sector body near here the other day which has cost a fortune. New systems were brought in and inevitably there was some part of it that would have to remain manual. Consultants were brought in at great cost to look for a solution and after several months and lots of money their conclusion was that while they might be able to improve it a bit there will still be the need for some manual “rekeying”.
Macro Scheduler could have saved them – and the taxpayer – thousands. But it never occurred to them that there was another way.
So my challenge, our challenge, is to reach out to these people, reach out to ordinary people and tell them “it IS possible”. We can simplify your work, we can automate those repetitive tasks, don’t believe everything consultants might tell you – they can’t help thinking traditionally or too technically.
There IS a way.
If you use Macro Scheduler to simplify your own processes, reach out and tell people in other departments, tell your colleagues, tell your friends. There will be someone in other departments with similar problems who could also benefit.
Spread the word. We have a duty to save people time, make people more productive, make companies more profitable, and in the case of the public sector – save our tax money!