"Chain of event receivers"

If you are a new Irrlicht Engine user, and have a newbie-question, this is the forum for you. You may also post general programming questions here.
Post Reply
Tihtinen
Posts: 76
Joined: Fri Jan 08, 2010 3:12 pm
Location: Finland

"Chain of event receivers"

Post by Tihtinen »

This is all around the API but what it actually means? Is it all classes that inherit IEventReceiver and implements OnEvent(...)? Or does it require a call to the IrrlichtDevice->setEventReceiver(...) ?

In the first case, how does the engine know about all event receivers it should pass the event into :roll:
And in the second case, how can I determine all the classes I want to pass events into? What is a difference between a current event receiver all other receivers in the "chain"?

I'm just trying to do my own classes that post and receive events, just like for example IGUIElements. Please correct me also if I'm doing it wrong.

EDIT: And to specify, I can do everything I want by:
A) Creating a few master event receivers for different situations and make the other classes make queries from these.
B) Inherit all classes interested in events from IEventReceiver, and always call device->setEventReceiver(this) when necessary.

I just want to know what is the way intended in the engine.
Last edited by Tihtinen on Wed Jun 02, 2010 11:19 am, edited 1 time in total.
slavik262
Posts: 753
Joined: Sun Nov 22, 2009 9:25 pm
Location: Wisconsin, USA

Post by slavik262 »

Correct me if I'm wrong, but all it's saying with the chain is that events are continuously passed to event receivers until one handles it (and returns true). In example, if the main receiver set by setEventReceiver returns false, the event is passed on to other things, such as IGUIElements. The engine knows how to pass the event to the IGUIElements because they are registered with the IGUIEnvironment.
LordNyson
Posts: 31
Joined: Tue Nov 11, 2008 12:02 pm
Location: Perth, Australia

Post by LordNyson »

Only the event receiver object that has been passed to the device is active. For example:

I have two event receivers:

Code: Select all

GUIEventReceiver my;
KeyEventReceiver e;
Now in this case I have two event receivers for different things, one is for my GUI and one is for my keys, I cannot have them both active at the same time as far as I know. So you switch between them.

Code: Select all

device->setEventReceiver(my);
if(condition)
   device->setEventReceiver(e);
Or you could create a class that houses both these event receivers and switches between them aka:

Code: Select all

if(event.EventType==EET_KEY_INPUT_EVENT)
    e->OnEvent(event);
else
    my->OnEvent(event);
As far as I'm aware this is the way in which irrlicht runs. So now to answer your question directly, if your doing GUI elements that post their own events and receive events I would suggest some kind of containment within an event receiver, for these classes to communicate. So have a containment class and then a list or some other type of dynamic data structure that adds to an underlying event receiver, then when it receives an event it passes a message to that event receiver. I mean the ways in which you could do this are limitless, now if you are doing classes that post events say for instance a network interface that changes some irrlicht things you will probably need to integrate it with the irrlicht event receiver, if not, just write your own.

Tried to cover all bases, but you should be more specific with exactly what your trying to do in future I may have missed the target. :)
But the cage only had "Warning: Vicious Lions" on it! Im a programmer! I only listen to errors!
Tihtinen
Posts: 76
Joined: Fri Jan 08, 2010 3:12 pm
Location: Finland

Post by Tihtinen »

LordNyson wrote:Tried to cover all bases, but you should be more specific with exactly what your trying to do in future I may have missed the target. :)
Yeah, thanks : ) I understood now.

And I couldn't be very specific, as I'm currently only trying to find the limits of using the event system to it's full efficiency in different things (including this GUI thing, but also using my own user events for gameplay triggers etc). It seems quite flexible, so I wanted to find out : )
Post Reply