Best Windows macro recording software?

March 12, 2005 12:39 PM

I've taken on a little mini project and I think the best way to get the job done will be to use one of those little bits of software which can copy and then simulate mouse movements etc.

Some background details -

My boss wants me to find a solution to this problem: There's this ancient Facilities Management system that's used where I work. Essentially it records hourly water and air temperature readings from hundreds of individual sensors placed within the water system. I don't know what kind of database this data is stored in (it looks like an ancient proprietary database that's just been built upon over the years) before it gets retrieved via the Windows frontend app, but using this app only allows you to look at readings from up to 10 sensors at a time (I don't know whether this is due to enforced restrictions within the frontend or the database, or both). My boss wants me to find a way for him to be able to automatically see periodic readings from all the sensors at once, or at least all the sensors from a certain building, and not through the frontend.

The way I wanted to approach this was to access the database in which the values are stored, and circumvent using this restrictive frontend - I was hoping it would be an SQL db or something like that. But because I frankly don't understand the implemented technologies quite enough I concluded the only way to get at the data automatically and periodically is through one of those mouse recording and playback programs - this would then open up an excel spreadsheet, import the data into it 10 sensor readings at a time and finally I'd do something with VBA to make it more presentable, maybe run off regular reports etc

My only doubts about this approach come from the fact that the frontend (which the recorded mouse macro will be using) is unlikely to stay static - things may be added fairly regularly to the frontend screen which could mess up my mouse macro e.g. if I record the mouse moving to the sixth file in a view of directories (or at point x,y) and selecting it and then if a file gets added to the beginning of this view my previous file is now the seventh one, so any mouse recording software would need to be fairly "intelligent" or at least have pretty decent scripting abilities.

Wow, having just read that back to myself and realised it's nowhere near as clear and concise as it should be I hope you can get understand what I need to get done. If anyone has any comments on the approach I've decided to take and the best mouse macro software I should use they'd be much appreciated.

posted by uk_giffo to computers & internet (14 answers total)

I know this isn't a specific answer to your question, but could you provide more information on the database side of things? It's highly likely that, unless it's completely custom, you can write some data transformation stuff to get at the data directly, which would be much more friendly, less hackish, and likely to work into the future despite changes to the frontend.

If you know where the database file is stored, what is it called? What company makes the program? If they still exist, try calling them to find out more, they might be helpful.

I've used some mouse scripting software before, I can't remember the name of it, but it provided rudimentary scripts that allowed the definition of variables and simple looping. There was no way to "read" the contents of the screen with the script language, which it sounds like you'd need to do in order to figure out whether or not to click on the eighth or ninth item, for example. I would just personally start looking in the database direction first, as it's likely far far less trouble.
posted by odinsdream at 12:46 PM on March 12, 2005

This is pretty much a last resort I think as it's software for the X windowing system (which would mean you'd have to remote-desktop or vnc in from an X server and run it on that), but xautomation is a truly wonderful set of tools which has things like visgrep, which allows you to find the location of a user specified image on screen. Combine it with with xse (a frontend for XSendEvent) and you can do pretty much anything.

If I were you I'd spend some time reverse engineering the backend (or hiring someone else to do it) though, as the resulting system will probably be a lot more pleasant to work with.
posted by fvw at 12:52 PM on March 12, 2005

Windows as a platform does not have the chops for interapplication scripting. Only applications that have embedded controls can be scripted, and if your application is limiting you to 10 views, it's pretty unlikely you're working with an app you can script. As you've noted, "screen-scraping" with mouse controls is not going to work because the data keeps changing on you.

Consider reverse-engineering the protocol between the frontend and the database, then coding your own frontend to pull the data into a spreadsheet for reporting.
posted by AlexReynolds at 12:52 PM on March 12, 2005

is the database on the same machine as the frontend? for some reason i got the impression that it wasn't. if not, you may be able to snoop on the data passing between front end and database, which will at best show how the database works and, at worst, give you the raw data.

oh, on preview that's what alex said. but maybe repeating it will make it easier to understand.
posted by andrew cooke at 1:35 PM on March 12, 2005

Thanks for the comments so far, definitely appreciated. I did grab a copy of the database but (typically) I've mislaid the CD-ROM I'd burnt it onto. If I remember correctly the db was about 10MB or so, so obviously it's not huge. It is stored on the same Windows machine as the frontend, and it's isolated from the network so using a remote desktop session or vnc session, or snooping the data passing isn't really possible I think.

I poked around with the db a bit a few weeks ago and after also playing about with google a bit I decided it night be a "SQLBase for Windows" (I think that was what it was called) since it had a .dbs suffix.

I've just done a little more playing with google and found this post on a database forum. Ah, it looks like it's a pretty much defunct db, and looks pretty ancient.

Hmm, it's looking more and more like there's no easy solution to this.
posted by uk_giffo at 1:42 PM on March 12, 2005

Have you searched Gupta's website for their "SQLBase Driver Pack", which includes ODBC and JDBC drivers? Installing either driver will let you cook up your own frontend pretty quickly.
posted by AlexReynolds at 1:52 PM on March 12, 2005

i don't understand the forum post. sqlbase is still around. you can read a document on how to connect to their database by following a link here. it may be that they no longer support the version you have, though. if i were you. i'd ask in their support forum.
posted by andrew cooke at 1:52 PM on March 12, 2005

gives up and goes home! :o)
posted by andrew cooke at 1:53 PM on March 12, 2005

Sounds like directly accessing the database somehow would be your best bet, but if that doesn't work out, Power-Pro is a free utility that might help you do what you need as far as recording mouse movements and copying data to an Excel file. In my experience the learning curve is pretty steep, but there is an enthusiastic community of users who would probably be able to help you get it working.
posted by nixxon at 2:00 PM on March 12, 2005

Wait a sec. You posted "things may be added fairly regularly to the frontend screen which could mess up my mouse macro"

So the front-end is still under development? Why not just ask the developers to remove the ten readings at a time restriction, or add a log to which all current readings are dumped?

Is this a case where your boss got told that development is frozen and that adding new requirements would mean paying dearly for them, and he wants to do an end-run around that?
posted by orthogonality at 2:09 PM on March 12, 2005

orthogonality: no, the frontend is fully developed and has been in use for a good few years - there'll be no new features added to it. What I meant is if for example a new sensor were to get added to the system by the contractor (who's the sole operator of the system, a few days a month - probably should've mentioned this, it's one of the reasons my little bit of software needs to be automatically run) then it'll affect the layout on the screen i.e. a particular sensor won't be selectable at the same part of the screen as it was previously, and this is when it will get messy and inconsistent to use a recorded mouse macro. Getting the developers to change anything isn't really a possibilty - the system will be EOL'd in a year or so for a brand new up-to-date system apparently. You have given me an idea though - I wonder if there are some existing logs within the system could contain the data I need?

Otherwise I could go with the mouse macro route and just ask the contractor to tell me whenever he does anything that'll affect the layout of the frontend screen, whereby I could amend the macro to reflect this. It's not very elegant, and a bit of a hack, but could be the way forward.
By the way, I didn't anticipate such a knowledgeable and helpful response for a question like this - thanks everyone :-)
posted by uk_giffo at 2:28 PM on March 12, 2005

There are tools that exist to do what you desire, but the ones that I use at work are very expensive and have a high overhead to entry. They hook into the application and capture information about objects in the window directly and allow the user to write intelligent C-like code to perform operations on these objects. The objects can be identified by their internal (programmatic) name, window ID, x/y co-ordinates, caption (text) or index (the 4th button on a screen, for example).

The tool I use is called Silk Test, by Segue software. It's about $1000 a license, plus you need a license server (which may cost more). We pay $50k a year to Segue for support. Competing products are WinRunner, Quicktest, and a few others that I've forgotten. If you search for "Software automation tool" you should get some more, possibly cheaper options. Note that the cheaper they are , generally the less powerful/flexible the tool is.

All that being said, using automation to capture this information is a terrible hack. I would only pursue this option if you have definitely exhausted gathering the data from the DB directly. If someone is re-writing your front end then you need to get in touch with them, because I guarantee you that they know all about that data and how to get at it. They may be reticent about giving that info to you, but I'm sure that leaning on them is going to be more efficient and maintainable than automation would be.
posted by Four Flavors at 5:22 PM on March 12, 2005

I agree with fwv and others that the most elegant solution is to directly access the database. This is the most direct and logical path.

I am also aware that sometimes the best path may not be an option. Since you've also mentioned that this is a "miniproject" you may not have the time or resources (or database administrators) to figure out a way into the database.

A software that I have used in the past for similar tasks (read 'dirty hacks') is AutoIt, a free software that performs exactly the types of automation that you describe in your post. AutoIt also includes functions that allow you to interact with specific specific controls in an application (much more fool-proof than a mouse macro). If you've used a scripting language or done any programming in the past, it shouldn't be too difficult to pick up in an afternoon.
posted by mattybonez at 5:28 AM on March 13, 2005

QuicKeys is a nice macro program. I've been using it for years. It's not free though.
posted by hootch at 10:11 AM on March 13, 2005