Question

This is a thought problem, and one I have been wrestling with for about a day.

I am writing an engine for a game in C (open source, for fun), and all of the interface (read GUI) elements deal with mouse input in a function interfaceMouse(). Basically, I call interfaceMouse() on a regular basis to see if the user has acted with the interface.

I would like this function to take latest mouse click, see if it interacts with any GUI element, and then return how that mouse click interacted with the gui element.

Given two different gui elements:

• buttons (user clicked button A)
• select menus (user selected option 1 of menu A)

I’m trying to figure out how best to return an interface event to the calling function. My best guess right now is linked lists for each type of event (buttonEvents, selectEvents), and functions like getNextButtonEvent(), which returns an event-specific value. interfaceMouse() returns a value dependent on the type of event the mouse event triggered, and then the calling function will have to retrieve that event from the respective list with getNextTypeEvent().

I’m not very satisfied with this approach, and was wondering if anyone has a better idea or could provide some additional foresight?

Answer 1

From your description, I’ve made a couple of assumptions, but here is how I would handle it:

interfaceMouse() determines what needs to occur from the mouse interaction, but does not process that actual interaction (or, processes the interaction but wants to explicitly return what was done). What I would do is have interfaceMouse() return a struct defined similar to:

struct 
{
    int event_type; /* Enumerated type */
    void* element; /* Pointer to the element, however it's defined in the code */
    void* event_data; /* Pointer to the data about the event */
 } event_result;

You can define the calls by accessing the element based on type (say, another struct with function pointers, or have event_data hold the function pointer and element be passed to it, etc.).

C is one of those languages where it requires a lot more thought of your data modeling, but can end up being as elegant or convoluted as you’d like.