Recorder V1.2 ------------- Released March, 27th 1996 Written and Copyright ©1991/1996 by Oliver Grimm. 1. COPYRIGHT ============ Both the program 'Recorder' and this documentation are copyrighted by me, but they are public domain software. That means you can use and spread them legally without paying any contributions (But I wouldn't reject them, too ..) as long as everything remains unmodified, and only the complete archive, program plus documention, is distributed. 2. DISCLAIMER ============= As usual, no warranty for anything ... 3. INTRODUCTION =============== Whenever you hit a key, move the mouse, insert or remove a disk, resize a window, or basically make any kind of input to your computer, the operating system creates something that is called an 'input event'. That's a structure that is sent to all programs that wish to be informed about those things, and it includes all the information about your action, ie. the number of the key that you have pressed, the new position of your mouse pointer if the mouse has been moved, and so on. Now imagine you have to repeat the same input several times, eg. you have to type certain commands or click certain gadgets in a specific order, and there is, for some reason, no way in which you could automate this, by writing a script, for instance. Here, this program could help you. You could start Recorder, do your input once, and this program would save all the input events that have been generated by you in a file. Then you could play back all these inputs, and to all applications it will look like you are doing all inputs again, but actually they are 'fed' into the operating system by Recorder. 4. USAGE ======== So far, Recorder has no GUI, so you have to start it from a command shell. The general parameter pattern of the program is the following, where parameters in [] are optional and (..|..|..) means you can choose one of the options: Recorder -(r|p[q]|a[q]) FILENAME There are three operating modes, record, play and append, which are chosen by the first parameter: -r Record incoming input events and store them in the file with the name FILENAME -p Play input events stored in the file FILENAME -a First play input events stored in the file FILENAME, then record more and append them to this file If you choose play or append, the input events are normally played back at the same speed as they were recorded. However, when you add 'q' to the first parameter, ie. -pq or -aq, there is a fixed delay of 1/50 second between all events. You have to keep in mind that the recorded events usually have some 'meaning', you might, for example, start a program by typing its name and then click some gadgets. If you play back these input events with the 'q' option, the start-up of the program might not be finished when Recorder is already feeding the mouse clicks into the input stream, and therefore the gadgets are not clicked properly because they are not there, yet. So be careful with this option ! It is not necessary to use the 'Run' command to start the program. It detaches itself automatically from the shell, so that you can continue to work in the same shell. Recording does not start immediately after the program has been started, but after you've pressed the key sequence Control-Left Amiga-'s'. With the same sequence you can also stop recording, which also ends the program. Playing works similar: It's started - and stopped if you don't want to play everything back - with Control-Left Amiga-'s'. In append mode, the input events are first played back normally, and then the program switches to record mode, and you have to start recording again with the mentioned key sequence. However, if you terminate play back early in append mode, you can't add new events and the program ends. Since Recorder always works in the background, there are not many ways to communicate with the user without disturbing other programs. Therefore, whenever Recorder wants to tell you something, it sends a 'Display Beep' to all screens. It does so under the following circumstances: 1) Whenever you press the control sequence to start or stop action to acknowlege your command. 2) When play back has finished. In append mode that means that the program is now waiting again for the control sequence to start recording again. 3) When the second internal buffer is full and the first one isn't written to the file yet. Then the program terminates, and the events in the internal buffers are saved. However, this should usually never happen, even if you are writing to a floppy disk (see section 7). 5. WHAT DOES RECORDER RECORD ? ============================== Not all possible input events are recorded - it wouldn't make any sense to record and play back a 'disk inserted' event, when there actually hasn't been a disk inserted ! In fact, all that is recorded are keyboard, mousemove and mousebutton events, so when you click a 'Load File' gadget in a program, you still have to insert the disk yourself ! So far, Recorder can't simulate that. Actually, sometimes Recorder does record an event which hasn't really happend. It is generated by Recorder whenever you start recording. You might have noticed that the mouse pointer sometimes 'jumps' when you start play back. This is so because a lot of events generated by moving the mouse only give relative positions, ie. the distance from the last mouse position. Therefore it is necessary that the mouse pointer is, at the beginning of playback, at the same position as it was at the beginning of recording. 6. COMPATIBILITY ================ The program should work on all Amiga's. If not, please drop me a note so I can fix that. 7. HOW DOES IT WORK =================== This program installs, by means of the input device, an input handler at high priority (80, in fact), so that all input events pass through this handler (If there is no input handler at higher priority which might filter some events). These events are passed through unmodified, but also stored first in a memory buffer and eventually in a file. The program actually uses two buffers, and if one fills up the other one is used while the first one is stored on disk, so that continuous recording is possible. Should it happen that the second buffer fills up before the first one has been written to the file, recording is terminated, and all the so far recorded events are saved. However, each buffer can hold about 1000 events, and an overflow shouldn't occur, even if one writes to disk and moves the mouse rapidly. In play back mode, the stored events are fed into the input stream by the same handler. ---------------------- If you have any suggestions or complains, would like to have a new function implemented, if you find any bugs or, of course, would like to send me any gifts (A postcard, maybe ?), here's my address: Oliver Grimm Steinbecker Str.69 21244 Buchholz Germany E-Mail: grimm@physnet.uni-hamburg.de