Custom Event Receiver and GUI Events

Murcho · Post by **Murcho** » Sun Nov 23, 2008 1:07 pm

I'm looking for some advice on how I should approach my menu event handling. I know for key events it's quite easy to store an array of bools for the keys to switch on and off, and having a function to check for key presses (It's in a couple of the tutorials), but for GUI events, all the tutorials I've read (I admit I haven't been through all of them) reference global variables to perform actions based on GUI events.

Now I'm trying to keep my code neat and separated, so I have a GUI class that handles the creation and maintenance of the GUI, and I'm not quite sure how to get the GUI events to pass off to other classes.

Would it be wise to just keep pointers to the required classes in the Event Receiver class, or would a message passing/Task queue system be a better idea to keep things separated better?

If so, does anyone have any good examples of such systems?

FYI, this is for my tech demo. I'm trying to get into the games industry, so I want to demonstrate the best possible code I can, which is why I'm being a bit pedantic about it.

rogerborg · Post by **rogerborg** » Sun Nov 23, 2008 1:38 pm

Yes, that's pants, isn't it? I've modified 05.UserInterface main.cpp to pass a context structure to the event receiver, and to use enumerated element IDs instead of magic numbers.

Murcho · Post by **Murcho** » Sun Nov 23, 2008 2:32 pm

I have already setup enumerated ID's for all the menu elements, I had a hard time following the code without them.

I'm not quite sure what you mean by a context structure. I've tried doing a few searches on google for the term, but haven't been too successful with them. From what I did find, I assume it just refers to a struct that is relevant to the current class context. Is that right, or am I way off?

I also assume you pass this struct through a function other than the Event Receiver's OnEvent() function.

Would it be possible to post up the structure passing changes you made to the User Interface tutorials? It sounds like it's what I need to get the job done.

Thanks for the speedy response before.

rogerborg · Post by **rogerborg** » Sun Nov 23, 2008 4:15 pm

New source

Diffs to the previous source.

It's nothing clever, it's just putting the globals into a structure and giving a reference to that structure to the event receiver.

vitek · Post by **vitek** » Sun Nov 23, 2008 9:58 pm

Yes, I'm going to pimp the state machine code again... You can encapsulate all of the gui processing in one place pretty easily using this scheme. It might seem complicated, but it does make it easy to avoid a bunch of globals.

GraphT.h
StateT.h
test.cpp

Travis

Murcho · Post by **Murcho** » Sun Nov 23, 2008 11:56 pm

Awesome, love the support here.

I'll go through this stuff today in class. I checked with a couple of class mates this morning on what they did in this situation, and they were just holding pointers to their classes, but I think the provided code will be a much better solution.

Thanks again, and I'll post up my solution once I'm done.

Murcho · Post by **Murcho** » Tue Nov 25, 2008 2:10 am

vitek, can I ask a little clarification on your code?

Is it right to assume that all input handling that will be around for every state (such as a IGUIContextMenu) should be put in the Global state onEvent function, and then specialized input only handled within each individual state?

I used a similar state machine setup in a previous project, but my coding partner implemented it and just glossed over the top of it for me. It wasn't as complex as this setup, but it looks like once this is up and running, it will be easier to maintain.

vitek · Post by **vitek** » Tue Nov 25, 2008 6:01 am

That is how I would use it, but you don't necessarily need to do it that way.

That is actually a complicated question. If you have some UI feature that is always visible, then you could put it into a global state. If you really wanted to, you could put it directly into the derived graph type. You could even put some things into a non-global state, but then all generated events wouldn't go to that state when it was not active.

Heck, if you really wanted to, you could make a state that was itself a graph with multiple states.

Travis

Murcho · Post by **Murcho** » Tue Nov 25, 2008 6:16 am

I was chatting to my housemate about it and he handed me a giant book on graph theory. I knew it was a big subject, but didn't quite realize how big it actually was.

I'm slowly trotting through the project now, with that approach, but graph theory and state machines look like some pretty deep and powerful stuff. I think I'll be looking into them a lot more after this project. So much to learn!

Thanks for the clarification.