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.In reply to Re^2: Controlling a non-perl GUI
by dbae
in thread Controlling a non-perl GUI
by dbae
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |