Related Info: Event Manager Menu Manager

Event Simulator

By Matthew J. Snyder, Fairfield, CA

Introduction

There are several products available today (including the newest system software) which let you play back arbitrary sequences of keyboard and mouse events at the touch of a button, and which can save you lots of time and effort if you need to execute the same pattern over and over. The playback involves a sort of simulation in which it is made to appear to the active application that the user is producing the events with his own fingers.

What I provide in this article is a poor man’s event simulator. It’s a code library, not a macro maker. There is nothing tricky about it, and it doesn’t violate any rules that I know of. The simulator makes it easy for the programmer to place simulated events onto the event queue, and the routines called by the event simulator are well-documented.

Background

The Operating System normally takes input from the user and stores events in the event queue, a standard Operating System queue. The Toolbox Event Manager in turn takes events from the event queue, as well as from other places, and passes them to the application in response to GetNextEvent’s. My routines simply imitate the Operating System by creating event records and placing them on the event queue by hand.

The Demo

I wrote the library at a time when I had a need for an FKEY that would generate a few mousedowns. Having an FKEY that produces mousedowns is a little like having one of the commercial keyboard macro products I mentioned in the first paragraph, and in this article I show an example of such an FKEY. However, the resulting keyboard macro is not very elegant, it’s limited, and it’s difficult to install and use.

In fact, I am not really recommending frequent use of such an FKEY. I present the FKEY example merely to illustrate a possible use for the simulator. I hope that readers can think of more creative and less dangerous ways to use the simulator.

Figure 1. THE journal of the elite

How the Simulator Works

I chose not to make use of the Toolbox Event Manager’s journaling mechanism. A look at the documentation in Inside Macintosh will reveal that on one hand it is a complicated matter, involving the use of device drivers to both record and play back an event journal, and on the other hand it is poorly documented. I have yet to see a good example of its use.

Below, I present the C declaration of the data structure used to maintain the toolbox event queue. For the Lightspeed C system, the declaration is found in <EventMgr.h>:

/* 1 */

typedef struct EvQEl
 {
 struct QElem  *qLink;
 int    qType;
 int    evtQWhat;
 long evtQMessage;
 long evtQWhen;
 Point  evtQWhere;
 int    evtQModifiers;
 } RealEvQEl, *RealEvQElPtr;

When I was implementing FKEY macros, I found it convenient to place a delay between some events. To do this, I install a routine into the VBL task queue that enqueues an event after a certain delay. To make it easier to install the routine, I wrote a little interface code and placed it in the simulator library. The routine is called MakeTimed, and the data structure needed for the VBL queue is declared this way in Lightspeed’s <VRetraceMgr.h>:

/* 2 */

typedef struct VBLTask
 {
 struct QElem *qLink;
 int    qType;
 ProcPtrvblAddr;
 int    vblCount;
 int    vblPhase;
 } VBLTask , *VBLQElPtr;

Warnings

I discovered a few other things while making the FKEY macros, and a little thought about these things will indicate why the use of the simulator in an FKEY is not the greatest idea. An FKEY’s code segment becomes locked in the heap while it is executing, but becomes unlocked after it completes. If the FKEY routine makes use of the MakeTimed function, and places the address of a routine in its code segment onto the VBL task queue, it should lock its own segment down. Doing this after the FKEY completes is not a simple matter.

The simulator allocates dynamic memory to hold the data structures whose addresses get enqueued to the toolbox event queue, so locking the code segment is not usually necessary. If you’re wondering what happens to the memory that gets enqueued to the event queue, I understand because I wondered too. I tracked one block, but didn’t learn anything interesting. The memory never becomes deallocated, either by the simulator or the Operating System. Because it’s allocated in the application heap, it returns to the pool when the application exits, but this may be little consolation to you if you want to generate a lot of events. A possible solution would be to add a VBL task that tracks the blocks and deallocates them when they’ve served their purpose. A tracker would add a lot of complexity to the simulator, and is left to the reader.

How the Demo Works

A few words about the demonstration FKEY and its algorithm: It’s designed for use with pre-Claris MacDraw (I have not tested it with the most current version). Its only function is the automatic generation of a picture. It does so using a technique for drawing lines by generating a mousedown in one location followed by a mouseup in another location.

I have found that MacDraw is the only software stupid enough (or smart enough, I’m not sure which) to be fooled by this technique. If you think about it, a line-drawing application should probably be tracking the mouse after a mousedown, drawing and redrawing the line until the mouse button is released. MacDraw has no problem with the mouse action occurring too quickly to track.

The Menu Manager is much too smart to be fooled by the technique, so it’s impossible to make an automatic menu selection unless the item has a command key equivalent.

A few words about the code itself: If you’re wondering how I determined the global coordinates of each point in the drawing, I used Rick Flott’s Mouse Position DA, published in MacTutor (I have The Complete MacTutor Vol. 2, so I don’t know from which issue the article came). I used the DA in combination with Apple’s MouseKeys.

More about the demo code: An FKEY runs in the context of another program, so it cannot have global data of its own. However, Lightspeed provides a facility for embedding data at the end of the code block, and accessing it as if it were global data. It’s almost completely transparent to the programmer. You simply declare the variables as global, autoinitialize them as you would real global variables, and reference them like any other variable. Lightspeed uses register A4 to point to the data space, and translates any use of the variable into a reference off A4.

The only explicit action the programmer must make is to place the address of the beginning of the data space into A4 before using the variables. As I mentioned above, the data is placed at the end of the code block. But Lightspeed uses the BEGINNING of the code block as a base in its references. For example, if your code turns out to take up 100 bytes, the first pseudo-global would be referenced as 100(A4).

So the address of the beginning of the data space is the same as the address of the beginning of the code block, which is the same as the dereferenced value of the handle that you would use to lock and unlock the block. This value is conveniently passed to the code resource when it is called, in register A0. I use the macro recommended in the Lightspeed manual for initializing and restoring register A4.

How to Make the Demo Work

To use the demonstration FKEY, build the project with type set to Code Resource. It’s 4-character TYPE should be FKEY, and its ID should be 8 (or any number you prefer, between 0 and 9). Use ResEdit or its equivalent to place the FKEY resource of the resulting document into a backup copy of MacDraw. Placing the FKEY in the application itself is preferred to placing it in the System file, since accidentally using the FKEY elsewhere would be undesirable.

Start up MacDraw, and hit command-shift-8. The rest is automatic.

Figure 2. The Projects

/***************
 ** MakeKey.c **
 ***************/

#include <OSUtil.h>
#include <EventMgr.h>

MakeKey(Code,Mods)
int Code, Mods;
{

/* locals */

EvQElPtr MyEventPtr;
QHdrPtr TheHdr;

/* begin executable */

/* 1: Key Down */

MyEventPtr = (EvQElPtr) NewPtr ( sizeof(EvQEl) );

TheHdr = GetEvQHdr();

MyEventPtr->qType = evType;
MyEventPtr->evtQWhat = 3;
MyEventPtr->evtQMessage = Code;
MyEventPtr->evtQWhen = TickCount();
MyEventPtr->evtQWhere.h = 200;
MyEventPtr->evtQWhere.v = 200;
MyEventPtr->evtQModifiers = Mods;

Enqueue (MyEventPtr, TheHdr);

/* 2: Key Up */

/*** For most applications, Key Up is unneeded ***

MyEventPtr = (EvQElPtr) NewPtr ( sizeof(EvQEl) );

MyEventPtr->qType = evType;
MyEventPtr->evtQWhat = 4;
MyEventPtr->evtQMessage = Code;
MyEventPtr->evtQWhen = TickCount();
MyEventPtr->evtQWhere.h = 361;
MyEventPtr->evtQWhere.v = 98;
MyEventPtr->evtQModifiers = Mods;

Enqueue (MyEventPtr, TheHdr);

*** For most applications, Key Up is unneeded ***/

}

/*****************
 ** MakeMouse.c **
 *****************/

MakeMouse(hzntl,vrtcl) 
int hzntl,vrtcl;
{

MakeMouseDown(hzntl,vrtcl);
MakeMouseUp(hzntl,vrtcl);

}

/*********************
 ** MakeMouseDown.c **
 *********************/

#include <OSUtil.h>
#include <EventMgr.h>

/* mouse down, no key modifier */

MakeMouseDown(hzntl,vrtcl) 
int hzntl,vrtcl;
{

MMDmod(hzntl,vrtcl,0);

}

/* mouse down with key modifier */

MMDmod(hzntl,vrtcl,mod) 
int hzntl,vrtcl,mod;
{

/* locals */

EvQElPtr MyEventPtr;
QHdrPtr TheHdr;

/* begin executable */

MyEventPtr = (EvQElPtr) NewPtr ( sizeof(EvQEl) );

TheHdr = GetEvQHdr();

MyEventPtr->qType = evType;
MyEventPtr->evtQWhat = 1;
MyEventPtr->evtQMessage = 0;
MyEventPtr->evtQWhen = TickCount();
MyEventPtr->evtQWhere.h = hzntl;
MyEventPtr->evtQWhere.v = vrtcl;
MyEventPtr->evtQModifiers = mod;

Enqueue (MyEventPtr, TheHdr);

}

/*******************
 ** MakeMouseUp.c **
 *******************/

#include <OSUtil.h>
#include <EventMgr.h>

/* mouse up, no key modifier */

MakeMouseUp(hzntl,vrtcl) 
int hzntl,vrtcl;
{

MMUmod(hzntl,vrtcl,0);

}

/* mouse up with key modifier */

MMUmod(hzntl,vrtcl,mod) 
int hzntl,vrtcl,mod;
{

/* locals */

EvQElPtr MyEventPtr;
QHdrPtr TheHdr;

/* begin executable */

MyEventPtr = (EvQElPtr) NewPtr ( sizeof(EvQEl) );

TheHdr = GetEvQHdr();

MyEventPtr->qType = evType;
MyEventPtr->evtQWhat = 2;
MyEventPtr->evtQMessage = 0;
MyEventPtr->evtQWhen = TickCount();
MyEventPtr->evtQWhere.h = hzntl;
MyEventPtr->evtQWhere.v = vrtcl;
MyEventPtr->evtQModifiers = mod;

Enqueue (MyEventPtr, TheHdr);

}

/*****************
 ** MakeTimed.c **
 *****************/

#include <OSUtil.h>
#include <VRetraceMgr.h>

MakeTimed(Func,Ticks)
ProcPtr Func;
int Ticks;
{

/* locals */

VBLQElPtr MyVBLptr;

/* begin executable */

MyVBLptr = ( VBLQElPtr ) NewPtr ( sizeof( VBLTask ) );

MyVBLptr->qType = vType;
MyVBLptr->vblAddr = Func;
MyVBLptr->vblCount = Ticks;
MyVBLptr->vblPhase = 0;

VInstall (MyVBLptr);

}

/************
 ** demo.h **
 ************/

/* struct for handling large sets of points */

typedef struct letter {
 int *h;
 int *v;
 } letter;
 
/* functions used to get access to psuedo-globals */

#define SetUpA4()asm {  MOVE.L A4, -(SP)\
 MOVE.L A0, A4   }
 
#define RestoreA4() asm {  MOVE.L (SP)+, A4 }

/************
 ** demo.c **
 ************/

#include “demo.h”

/* psuedo-global data points */

int data1 [20] = { 119,119,128,128,137,146,146,155,155,119, 0 };
int data2 [20] = { 115,187,187,151,169,151,187,187,115,115, 0 };

int data3 [20] = { 155,155,164,164,173,173,182,182,155, 0, 164,173, 0 
};
int data4 [20] = { 160,187,187,178,178,187,187,160,160, 0, 169,169, 0 
};

int data5 [20] = { 182,182,209,209,191,191,209,209,182, 0 };
int data6 [20] = { 160,187,187,178,178,169,169,160,160, 0 };

int data7 [20] = { 200,200,209,209,227,227,236,236,200, 0 };
int data8 [20] = { 115,142,142,187,187,142,142,115,115, 0 };

int data9 [20] = { 227,227,254,254,245,245,236,236,227, 0 };
int data10[20] = { 160,187,187,160,160,178,178,160,160, 0 };

int data11[20] = { 254,254,263,263,272,272,281,281,254, 0 };
int data12[20] = { 160,169,169,187,187,169,169,160,160, 0 };

int data13[20] = { 281,281,308,308,281, 0, 290,290,299,299,290, 0 };
int data14[20] = { 160,187,187,160,160, 0, 169,178,178,169,169, 0 };

int data15[20] = { 308,308,317,317,335,326,335,335,308, 0, 317,326, 0 
};
int data16[20] = { 160,187,187,179,187,178,178,160,160, 0, 169,169, 0 
};

/* main routine */

main() {

/* locals */

letter M, a, c, T, u, t, o, r;
int h_index, v_index;

/* begin executable code */

/* access psuedo-globals */
SetUpA4();

/* load structures */

M.h = data1;
a.h = data3;
c.h = data5;
T.h = data7;
u.h = data9;
t.h = data11;
o.h = data13;
r.h = data15;

M.v = data2;
a.v = data4;
c.v = data6;
T.v = data8;
u.v = data10;
t.v = data12;
o.v = data14;
r.v = data16;

/* select from pallette */
MakeMouse(15,100);

/* draw letters */
DrawLetter(M.h, M.v);
DrawLetter(a.h, a.v); DrawLetter(&a.h[10], &a.v[10]);
DrawLetter(c.h, c.v);
DrawLetter(T.h, T.v);
DrawLetter(u.h, u.v);
DrawLetter(t.h, t.v);
DrawLetter(o.h, o.v); DrawLetter(&o.h[6], &o.v[6]);
DrawLetter(r.h, r.v); DrawLetter(&r.h[10], &r.v[10]);

/* deselect last line */
MakeMouse(400, 250);

/* pop A4 */
RestoreA4();

}

/* routine to draw letters */

DrawLetter ( hArray, vArray )
int hArray[], vArray[];
{

int h_index, v_index;

for (h_index=0,v_index=0; (hArray[h_index+1] != 0) || (vArray[v_index+1] 
!= 0) ; h_index++, v_index++) {
 MMDmod(hArray[h_index], vArray[v_index], 0x0100);
 MMUmod(hArray[h_index+1], vArray[v_index+1], 0x0100);
 }
 
}