Sign in to follow this  
methinks

How best to communicate with UI?

Recommended Posts

How would people recomend to get a UI to talk to an application? For example, if the user clicks a button labeled "run", what is the best way to then call a function called run? Some ideas I've come across so far are: Callback functions Message (or event) systems Overloading each button with specific input handling functions (sounds messy to me!) So what would people recomend, and why? (In case it makes a difference, this would be in C++)

Share this post


Link to post
Share on other sites
I had the same problem and eventually I went with an elaborate event processing system. One that is polled for during the next time input is read from. It's rather easy to implement one, all you need is a queue (or similar FIFO data structure). The benefit is that you can design a simple event based system that is very extensible using classes and templates. Callbacks are the old C style way of handling events. The down side is that they lock you into using either static functions in a class or free floating functions.

Share this post


Link to post
Share on other sites
Note that most event systems are implemented via callbacks. When the button is clicked the callback is called. The callback adds an event to the queue or calls each of the functions in the event listener list, or otherwise does event-style handling. You might design a system that automates the callback and event generation, but the underlying mechanism is the same.



One difficulty with queued messages and delayed processing is that it can become very painful to debug. When you see the symptoms of a bug several frames or iterations after the actual event that caused the bug, it can be very time consuming to figure out what generated the offending event and why.

That being said, event systems do offer a lot of flexibility.


My preference is a global message bus (with mandatory debug info indicating their timestamp and original source) along with a single callback on the UI element. The callback is able to call any number of event listeners (even zero of them) and also add messages into the global bus for general consumption.

With a global bus, you can more easily log events that are going on in the game, and combined with a good scheduler, you can identify and fix runtime hotspots and overly-chatty interfaces.

Share this post


Link to post
Share on other sites
Quote:
Original post by frob
Note that most event systems are implemented via callbacks.


Not necessarily, but it is the most straight forward method. The Win32 API uses callbacks for all types of enumeration and event processing. I would suggest that you look into this, especially if you don't feel you mastered OO design. Also, Callbacks are not thread safe, you would need to write something a bit more complex in order for your event system to work over thread boundaries.

So, coder beware.

Share this post


Link to post
Share on other sites
Would the terms Model-View-Controller, Model-View-Adaptor, and Model-View-ViewModel be relevant for ideas? These overly contrived concepts may only be relevant when your app starts getting complex or if you want to plan for the time when your app starts getting to complex to manage with comfort. Otherwise, one method would be as good/bad as any other.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this