What I really need to know is what is the best way of doing this, how do I create the event and send it to the correct object?
Do I make the event class keep track of all objects that are running and figure out what object is supposed to get the event or do I make the event class only know which window is in front and has focus and send it to that window to figure out who's to get the event?

How would I construct the event part of the basic classes (window, button etc).
One way I've thought of is to make all the classes accept all events, creating an event class all classes would inherit, and simply return them all unless the corresponding function was overridden or is there some easy way to let the class accept only the events it wants? I guess that would require the object to register itself with the parent object or the event generator and request the events it wants but I think that would require me to create an event mask in every object that is generated so it's a little less appealing but should be easy to implement.
Speed is not of much issue at this point but is always worth considering. What I might want to do is to create a sort of multi-tasking environment inside the program so that null events might be used for some small calculations etc. That probably requires the event mask.

Does anyone know of any good website or a good book that explains clearly how to write an event generating engine and class like I'm trying to explain?

Gulli

PS. If I'm not explaining this clearly enough please just ask.

A great book on OO programming is

Design Patterns: Elements of Reusable Object-Oriented Software

Erich Gamma, Richard Helm et al
ISBN0-201-63361-2

My copy was about £30 but it's probably cheaper on Amazon. For those who don't know design pattern describe common programming constructs in OO programming - this book is basically a wealth of experience on how to solve particular problems in OO design. However, having said that it doesn't have a general eventing mechanism - partially because it has several different ideas. Further ideas on patterns can be found from

http://hillside.net/patterns/patterns.html

Anyway back to your question. Whatever you decide to do you only want to send events to the objects that actually want them. This means that objects should register themselves with some event manager.

How objects receive events is up to you. One way is to group common events (window opened, window closed etc) and then define abstract classes which much be implemented by objects which want to receive those interfaces. Java works like this. Anyway your objects register themselves as wanting to receive a specific block of events and the event manager merely calls the appropriate method on the objects interface. The nice thing about this is that it's neat, it's easy to see how events should be handled (fill in the virtual functions) but it's also difficult to add new events.

A better approach might be to design a generic event interface, something like

class CEvent {
public:
CEvent(int t) { type = t; }
int eventType() { return type; }

const int EVENTTYPE1 = 1; // Bits
const int EVENTTYPE2 = 2;
const int EVENTTYPE2 = 4;
...
private:
int type;
};

class CEventHandler {
public:
virtual boolean eventHandler(CEvent &event) = 0;
};

All classes are derived from CEventHandler and implement the eventHandler method. All this method looks like is a switch statement decoding the event and taking the appropriate action.

Then you can have an event manager with an interface like

class CEventManager {
public:
boolean register(CEventHandler &object int eventMask);
boolean unregister(CEventHandler &object int eventMask);
};

The event manager contains a list for each possible event. The register method places the object on the list for each event in the event mask. The unregister method removes the object from the event lists specified in event mask. As events occur you traverse the appropriate list creating events and calling the object handlers.

The only flaw with what I've said is that the CEvent class assumes that all events have the same form (ie you don't pass event specific data to the object). What may be better is to make CEvent an abstract class and derive specific event classes from it. The evenHandler method can then cast the CEvent object to the object appropriate to the event.

Hope that's some help. I have a generic event mechanism in C which was written for a game engine. Let me know if you want me to mail it to you. It's not as powerful as what I suggest above but it may give you some ideas. Failing that it's part of the OS/G distribution at

http://www.comp.lancs.ac.uk/computing/users/johnstlr/riscos/threed.html

although this is a 300k download. The source files are Event.c and EventH.h

[Edited by johnstlr at 09:44, 15/1/2001]

1) He states that his program runs outside of the WIMP. It's not a Wimp task so the facilities built into RISC OS aren't applicable.

2) It seems that the requirement is for event passing in a "single address space". Structuring the program as a series of co-operating Wimp tasks is a) complex and b) more heavy-weight.

Finally he might be doing it to learn about eventing mechanisms rather than just using one.

I would guess that this isn't practical for two reasons

1) He states that his program runs outside of the WIMP. It's not a Wimp task so the facilities built into RISC OS aren't applicable.

2) It seems that the requirement is for event passing in a "single address space". Structuring the program as a series of co-operating Wimp tasks is a) complex and b) more heavy-weight.

Finally he might be doing it to learn about eventing mechanisms rather than just using one.

Correct on all three accounts
Mostly I'm doing this to learn the eventing mechanisms, writing the program itself is merely a way of learning how but it might become useful on its own.

Gulli

[Edited by Gulli at 14:32, 16/2/2001]