Bristol Wearable Computing

[ Home | Plans | Meetings | Members | Search | Papers | Links | CyberWear | LocoSoft]

EventMan Application Writers Guide


This guide is designed to outline the ideal structure of an EventMan application. The two header files ApplicationMod.h and EventAPI.h define the interface between the EventMan and an application, and it is probably worth familiarising yourself with these two files before continuing.

At the time of writing, the EventMan is very stable, but lacks many features that would make application development easier. Ideally, the EventAPI.h would lose some functions that are currently present, and these functions would be transparently implemented in the EventMan instead. Specifically, event and device resource deallocation could be handled automatically by the EventMan with little overhead. This would save application writers from having the track event ID's so that they can be free'd in AppClose(). While it would be nice to implement all these things, the future of the EventMan cannot be assured, and it is highly possible that it's structure may radically change to accommodate new ideas or innovations. Until the EventMan has been proved in use, loading features into EventMan would be pointless.

The Rules That Must Be Obeyed (And Why)

A Word About Event Handlers

All event handlers should have the following prototype:

int FuncName(revents_t Event);

An application can have as many event handling functions as it wishes, and doesn't have to have any. The address of an event handling function is passed to the EventMan when a new event is created. The event handling function will then be called when the event is triggered.

It is entirely possible to have only one event handling function, and to use the EId returned in the revents_t structure (defined in ApplicationMod.h) to decide upon the course of action.

Any data that was requested for return with the event will be returned in the revents_t structure, and different data items will be present in the data array in the same order as data was requested by the application. The data in this structure should not be modified or freed. Instead, if this data is needed for longer than the scope of the function, or if the data needs to be modified, it should first be copied out into some other space.

Event handlers have return codes like the AppInit() function. Again, either EM_EXIT or EM_SUCCESS can be returned (same meaning as for AppInit()) and other return values give undefined results. The return of the EM_EXIT value can be used to allow termination of an application upon some event. Note that AppClose() will be called if it is defined.

Considerations of the Current EventMan Implementation

Example 'Hello World' Application


#include <stdio.h>
#include "ApplicationMod.h"
int AppInit() {
  printf("Hello World\n");  
  return EM_EXIT; 


gcc -c Test.c
ld -shared -o Test.o ApplicationLib.a –lc


unicrest.gif (4191 bytes)

The material displayed is provided 'as is' and is subject to use restrictions.
For problems or questions regarding this web contact Cliff Randell.
Last updated: January 14, 2000.
logoep.gif (1404 bytes)
ęCopyright Hewlett-Packard 1997-2000.