State Event design.
Author
Okay, I have a class-based state machine, each state is a child class of CState and gets events. Right now I have events like keyboard input and functions like CState::onHidden(bool hidden). My question is this: Would it be better to remove onHidden and replace with an event or keep adding more onX functions?
Also, on another topic, how do I hide the GNOME panels?
Quote:Original post by JookiaRight now I have events like keyboard input and functions like CState::onHidden(bool hidden). My question is this: Would it be better to remove onHidden and replace with an event or keep adding more onX functions?
You mean replace with a single event function taking an event object as a parameter? It depends on a lot of other factors, like how many events you have now, how many you're likely to have in the future, how the events are produced, and how they are meant to be be used. code pls?
IMO an onX function is an event, so you've currently got 2 different event systems -- onFooBar( SpecificEvent ) and onEvent( GenericEvent )
I'd try and just use one system or the other for all of your events.
I'd try and just use one system or the other for all of your events.
I prefer the onEvent(GenericEvent) interface mentioned above, because it keeps the interface clean. I am also fine with trading speed and type safety for flexibility and extensibility here (my events have a string type, and the dispatcher has no idea about the event type except for registering interest of listeners in a specific event type, so it can handle any event that might ever be created without any code rewrite), but this is not necessarily the prevalent opinion.
This kind of system also has the advantage of being easier on logging - just dump all events to a log file in that class and you've got yourself a cheap accounting trail. You can also inject fake events for testing purposes.
This kind of system also has the advantage of being easier on logging - just dump all events to a log file in that class and you've got yourself a cheap accounting trail. You can also inject fake events for testing purposes.
Author
I plan to have key press events along with object and world events like onObjectTouch and all that crap. Is it better to have onEvent and have all those as events or scrap the onEvent and have those as functions?
If I do the onEvent method, how am I going to have generic events that need special params like onObjectTouch(player, normal) and onStateHidden(hidden)
If I do the onEvent method, how am I going to have generic events that need special params like onObjectTouch(player, normal) and onStateHidden(hidden)
Quote:Original post by Jookia
If I do the onEvent method, how am I going to have generic events that need special params like onObjectTouch(player, normal) and onStateHidden(hidden)
The way I solved this was to add an argument map to the message class. In pseudocode:
class Event: string type map<string, object> argumentsI'm sure it's possible to cook up something similar with the collection classes in C++. Another possibility is subclassing Event and downcasting in the onEvent() handler based on event type. Strictly speaking that's not very OOP-like, though.
Author
Generic event type it is, but I need for all kinds of events to have multiple arguments of different types.
Author
Would an array of void*s then slowly painstakingly casting them to their real types work?
Maybe, but it will be gross and unstable. If you're willing to do that, why not just do strings? It will be cleaner and more extensible.
Author
But that'd require more memory wouldn't it? Why not an enum? Or some crap? I don't know what I'm talking about, could you spoon feed me an example event + how to send/recieve it?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
