Sunday, February 6, 2011

Automating Windows

So today I'm scripting the conversion of about 140 XLS and PPT files scattered in a directory tree on FTP into TTX in the same FTP directory tree. There's no way to do this except by calling an external Windows function and doing your best to automate it through the GUI.

This is a brittle process, and therein lies the difficulty.

Several of the XLS files are locked in Excel. TagEditor can still convert them, but Excel pops up a little dialog asking for the password - and since the TagEditor window never appears, the script runs afoul of my assumptions.

The way to get around this would be some sort of wrapping layer that explicitly states my assumptions and ensures they're met before proceeding. If something unexpected happens, ideally this facility would note it and diagnose it in a wait-a-minute record, and put the action back on the queue for intervention.

Which brings me to the other assumption I'm making, which is that a script is a sequential process; before one file is done, I don't go to the next (except of course that the script is sometimes not waiting for some reason, thus opening hundreds of TagEditor windows without checking whether it's appropriate or not, sigh.) Instead, there should be a parallel queue (this is a workflow concept); if one of the actions runs aground, others should proceed.

Both of these are higher-level approaches to the scripting task.

(Update: additional assumptions I was making: that the window closed immediately after being told to close, that the converted file was being written immediately, and that a window just opened is the topmost window after opening. All of these should be checked and accounted for in a mature script driver for Windows.)

No comments:

Post a Comment