mkent@dewey.soe.berkeley.edu (Marty Kent) (03/17/89)
In article <628@tekno.chalmers.se> d83_sven_a@tekno.chalmers.se (Sven (Sciz) Axelsson) writes: >1) I am trying to write a DRVR-routine to utilise the journalling mechanism. > I caget it to save the events all right, but I have problems getting > the playback to work, as Inside Macintosh is a little unclear in how to > do this. Should I stuff csParam+4 with the journal code read from the > file of saved events, or am I supposed to look at it and compare it to > what I have saved previously? also should I put a pointer to my event > data in csParam, or must I do a BlockMove to the address contained in > this location. If someone can mail me some source code in Pascal or C > that shows how do do journalling playback, I would greatly appreciate it. I'm just finishing a journal device which is written in LSC 3.0; I'll be glad to send you my source within the next week or so. I found the pathetic little bit of documentation about this stuff in IM not very helpful, and have kind of struggled through. My journal seems to work pretty well, but I'm wondering if I've missed something... Here's the issue: Say you've got a sequence of "events" (such as mouse ups/downs, key events etc) to replay. You have these events in the sequence they occurred, but there's no guarantee the operating system is going to call the low-level input traps in the same sequence again at playback time. So just because your next recorded thing says "GetMouse says the mouse is at X,Y" doesn't mean GetMouse is about to be called. Now it seems it would be most convenient if you could read the line from your recording and MAKE GetMouse be called, e.g. by generating some kind of interrupt. But my understanding of the journalling mechanism is that this is not the case. So what you have to do is be prepared to deal with whatever input trap gets called next. The way I do this is to time-stamp all my recorded events (I don't record all the calls to the input traps, only those calls where something changes state, like a non-null event or a GetMouse that's returning a different value than the previous GetMouse call). At playback time I set up a series of "registers" that maintain a kind of virtual state of the input devices. For instance I have a mouse-position register that always holds my current idea of where the mouse is. At playback, any time the GetMouse routine calls the journal, it just passes back the value currently in the register and looks to read another command from the recording file. If that command is a mouse position, it's loaded into the register, so the next time GetMouse is called it'll get the new value. This all seems kind of clumsy to me, but it was the only way I could come up with to be prepared to handle any trap call at any time during playback. Does anyone out there have anything to say about this, either suggesting a simpler way or else confirming that this is what's intended by the designers of the journalling mechanism? Note that this approach has a problem with time-critical events, such as scrolling a window. At record time you get the "exact" times of mouse-down and mouse-up. But when you play the stuff back, all you can do when you read the mouse-up command from the file is to set up so the next time the system asks if the mouse is still down, you can say no. But the system may not ask for a while... This problem is what suggests the possibility of somehow using interrupts at playback time. Comments, suggestions are very welcome. Marty Kent Sixth Sense Research and Development 415/642 0288 415/548 9129 MKent@dewey.soe.berkeley.edu {uwvax, decvax, inhp4}!ucbvax!mkent%dewey.soe.berkeley.edu Kent's heuristic: Look for it first where you'd most like to find it.