|Base untemplated class used for the event instancies. More...|
|Event actors could acts as a server and client on event communication channels. More...|
|Event channel used for communication between application/engine's components. More...|
|Event factories are used to create events of certain types. More...|
|Main class providing the event messaging system. More...|
|static T *||nrEngine::event_cast (Event *base)|
|static SharedPtr< T >||nrEngine::event_shared_cast (SharedPtr< Event > base) throw (Exception)|
In our engine we are trying to improve the normal behaviour of the event management system. We do not only use simple events, instead of this we mix several techniques like signals, triggers and state machines within the concept of events to give the develeoper a possibility to increase the dependecy gap between application modules.
The engine does also use name driven event system instead of id driven design. This is done for the reasons of readability and expandability. So if new event should be added to the system, it can be added by using other name rather then to recompile the application by adding new ids. Also using of string based names for the vents allows better using of scripting.
New type of events could be easely added through plugins, so the engine must not be recompiled. For example: the engine could easely be extended to an input system. The input system can fully be programmed as a plugin. To allow a communication between the components of the engine and application, the new plugin could generate a new type of events, namely "input". Each event listener which is registered for hearing the communication channel for the input events will be informed if there is a new event.
Our events are priority based. This means that each event does get a priority number defining how soon this event should be delivered. In each cycle the application running all events/messages comming to a channel will be collected in a priority queue. When the EventManager gets updated it tells the channels, that they now can deliver the messages to all connected actors. So the events with the highest priority will be delivered as first and the messages with the lowest priority will be delivered as last. If there is two events of the same priority, so it is not defined which one will be delivered as first.
There is also special events having the priority number IMMEDIATE which will cause the channel to deliver this message immediately without be stored in the queue. This actors will be informed about this events as soon as the event is triggered.
C++ does not provide any possibility to write the event management typesafe without big circumastances. There are some techniques, but this will end up in a big code plus a lot of function calls if to provide you the derived class instance instead of the base Event class. However we will try to give you the possibility of using your own event types derived from the base class in a controlled typesafe way. This means that if you handle correctly, so you will never cast to any wrong class by handling events.
One solution were to forbidd plugins to send any new type of events which was not declared in the engine before. This solution might work, but then we loose to generality of our engine, because then we have to implement all things which are needed for properly use in the engine (graphics, inputs, ...)
The other solution is to provide the engine TODO !!!!!!
|static T* nrEngine::event_cast||(||Event *||base||)||
|static SharedPtr<T> nrEngine::event_shared_cast||(||SharedPtr< Event >||base||)|| throw (Exception)