• Advertisement
Sign in to follow this  

State Event design.

This topic is 2964 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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> arguments



I'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.

Share this post


Link to post
Share on other sites
Generic event type it is, but I need for all kinds of events to have multiple arguments of different types.

Share this post


Link to post
Share on other sites
Would an array of void*s then slowly painstakingly casting them to their real types work?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement