Were I attempting this, my starting point would be to install ProcessExplorer. This is a TaskManager replacement that has a built-in facility for monitoring what files are being accessed by running processes. By enabling "Show lower pane" and selecting "Lower pane->view handles" (both from the View menu), you can click on the running appication and see what files it is accessing. Realise that it might not put the programs into separate files. It might store them in a single file, or in the registry somewhere.
It won't be easy to reverse engineer, but if you can locate where the programs are stored and then: start with something simple, take a copy; add one thing, take another copy; and one more thing and take another copy. it should be reasonably easy to build up a picture of the way the programs are stored, and build up a library of routines for generating the required code for each type of action.
The problem with driving GUIs is that the windows and dialogs involved have a tendancy to move around the screen each time they are displayed. And that makes automating complex interactions, laborious and fragile. If you do have to go this route, then you might consider trying something like AutoIt which is designed for exactly this type of task.
In reply to Re^3: Controlling a non-perl GUI
by BrowserUk
in thread Controlling a non-perl GUI
by dbae
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |