@anonymous:
it is NOT MFC. It''s just an idea of handling events in a more eneric way than using the windows messages.

@Luke:
If you use your event handler a bit more generic, you will see that you dont need pass the mother class to all listeners. Instead trigger an event SWITCH_KEYBOARD_MODE and your mother class is a listener as well which reacts on that event?
Events are perhaps more powerful than you might think of.

And about multiple game modes: If you want generic and without outer information in your class, just make a dynamic list of lists of listeners (list m_pModesList). The you could add a method like "registerKeyboardMode(int nModeID)" and you could dynamically add as much keyboard modes as you wish - without the class having any game logic.

btw, afaik one would call it a singleton, yes.



x = rx ( 1 - x ) ; r > 3.5699
... and chaos may begin ...

I understand exaclty what you mean about not having to pass the mother class to each event listener, & I agree. What about this special case:

The user presses the enter key, this event is decoded & sent to the mother class, the mother class turns around & sends the event to the current game mode''s event handler. You happen to be looking at the menu & the highlighted item (with the focus) is the button that allows you to START the game. Now normally the enter key isn''t an event that tells the mother class to switch game modes... therefore... the button knows what its supposed to do when its activated, but nothing else does. The button''s action needs to be given to it when you create the button & add it to the GUI class. I think this makes sense... a little ???

Hey, you wanted to be generic: a button does not have any logic.

If you want to handle a menu, you create a menu class which registers some keys for itself.

So if you press a button on your gui, it''s decoded and triggers an event which is send to your menu class. This class decodes which button it was and what''s his purpose.

In your case you would have a gui with some buttons, a menu class which has registered the key events for "item up" (key up), "item down" (key down), "execute item" (which could be ).

- Once the gui records a button been pressed it would send a "button pressed" event. That one is captured by the menu class and interpreted as "select item " and "execute item".

- Once the keyboard records a key stroke a key message is send which could either be up or down for selecting an item relative to its precessor or executing the current one ().

So the gui has to know which buttons it should have and how the are labeled, but should only know that it should send a "button pressed" event on a button click (no logic, only display data).
The keyboard doesnt know anything (since it has nothing to be displayed), but was informed by the menu class (by registerKeyEvent) on what keys to listen (no logic).
Only the menu class has information about what should happen on every menu item and how it should be displayed (normally the menu class should inform the gui how it should look like and what buttons it should have).

-> thats modular!

Btw, I think it''s better to handle all events in one class. Add a data to your event class named event type. The event type could be "input" for keyboard or mouse, "game" for game specific events, "general" for communication events between classes, "network", etc... The you could register listeners for an event type only and have a list of events and of listeners for every event type (which should be added dynamical as well).



x = rx ( 1 - x ) ; r > 3.5699
... and chaos may begin ...

Thats exactly what i was looking for.
a nice event handling system.


didnt know you can do that

Lazzar

[edited by - Lazzar on June 1, 2004 4:23:56 PM]

so as lord_jake described it...

The "menu" class contains all the information about what happens when a certain button is pressed...
so when you add a button to the menu... you also have to add an action to perform when that button is pressed... those things go hand in hand... why is it modular if only the menu class knows what actions are performed & not the button''s themselves? the fact that when the button is clicked or activated... that it performs some action... is intrinsic to the button. you don''t have to actually code the action into the button class... you can have a function pointer & some method like this:

GuiButton::addAction(action* newMethod) {   myActions[numActions++] = newMethod;}GuiButton::clicked(void) {   for(int i=0; i< numActions; ++i ) {      myActions[i]();   }}

is this possible?
is this not modular then? maybe I want the buttons to have to much power... the way I think about it:

- Each button is created as a generic Gui object that can receive events.
- It eats the event if its a mouse click that falls inside of it, or if its a hotkey, or perhaps the activation key & the button''s focus property is currenty true (highlighted item).
- When it eats an event, it performs all the actions its supposed to, those actions can be added dynamically (using something like the code above).

PS - you know you''re a coder when you start punctuating sentances with a " ; "