I need to explore MetaRobot more comprehensively. One can certainly save an AssemblyRobot program, and currently our MetaRobot lists about 20 such AssemblyRobot programs. Using XP search facilities, I have looked for files on the system whose names contain the names of AssemblyRobot programs listed by MetaRobot. Result: zilch. So I'm not sure where and how MetaRobot is hiding these programs. To find out what is in the programs, one descends a menu hierarchy,noting what's there at each stage. But even if all this information was neatly written out in a textfile, one would be infinitely far from having something that would drive the robot.
As far as I know, the only ways to make the robot do something are 1) select a pre-existing, saved AssemblyRobot program and tell MetaRobot to execute that or 2) to use clicks and keystrokes to construct an AssemblyRobot program from scratch or 3) copy an existing AssemblyRobot program and alter it using clicks and keystrokes.
It doesn't seem possible to find out the format in which the programs are saved, or to obtain any examples. I suspect the manufacturers think they can force people to pay for something better, and, in the meantime, are keeping everything as secret as they can.
However, as I type this, I'm thinking that maybe I can create a new very short AssemblyRobot program, and then asking XP to find all files created in the past 10 minutes. My strong suspicion is that, if the new AssemblyRobot program has been saved in a separate file, then it will be in binary. I have no idea how I would reverse engineer a binary file. Is it possible? I think that would be harder than getting the perl module to do the job.
But I will bear in mind what you say and make another fruitless attempt to get cooperation from the manufacturer.
| [reply] |
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.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |