Gui system in d3d. While playing the game I'm capturing controller states with directInput for both keyboard and mouse. When I get into a menu mode, for typing or some other fitting example, I would like to pass in input events to the gui system, and have it react accordingly. For instance, mousemove( 3,2 ) -> button at that pos lights up. So my first question is, how should i determine whether a mouse button was pressed, or what is a good way to create /new/ input events without doing something like input->MouseDown( left? ) no? ok how about input->MouseDown( right? ) no? ok ->> input->MouseDown( key46 ) down? ok { MouseEvent *e = new MouseEvent( key46, x, y ); processEvent( e ); } It seems to me that using buffered input would avoid such a pile of no-good. But do I switch from steamed input to buffered? Is there a better way to handle this with DirectInput? Can i avoid using windows messages? Is it worth avoiding? I'm looking to implement an observer pattern for these input events, is this a wise consideration? Secondly: For buttons, when they are clicked... the actions they perform i would like to be different (fancy that). Should they call custom functions using functors? Subclassing them seems pour, and not as flexible as desired. However, would subclassing not be such a bad approach if they functions were performed with scripts? Resulting in a ScriptButton.. or something? I am wide open to hear what everyone has to offer. And why you chose doing it one way vs. another. General tweaks, insights ... all the above. Thanks, ^sf

I'm not entirely sure what your first example is doing. What are left, right, and key46? On-screen buttons? Mouse-buttons and a keyboard key?

My system was pretty simple - the GUI is a tree of elements, each element containing 0..N other elements within its boundaries. When the mouse moves, or a button is clicked, that event (type, plus x/y coords) is sent to the top level element. That decides whether to handle it itself, discard it, or based on position, propagate the event to one of its child elements. And this continues until the event is either handled or ignored. It's largely independent of whether the input itself is event-driven or polled. Polled input just needs a small memory so that it can compare the current state with the last state and send events corresponding to changes accordingly.

sorry for being rapid in my question. To present more clearly:

Currently I can ask my directinput class whether a key is down. I was curious
if there was another way to handle input events in a more event fired manner vs.

if( input->IsKeyDown( LEFT_MOUSE ) ) gui->MouseClick( LEFT, x, y );

By event fired meaning more specifically -> DIKeyboardInput->GetDeviceData() function. With that I can be told 'the number of elements actually obtained.' With this I don't have to ask If( this key down ) or IF( that key down ). I can just loop through the keys that have been modified.
This requires buffered input.

While I'm not using buffed input for the play of my game, how could I integrate this anyway? or is there no way around it without switching device modes? Or is doing if(thiskey/thatkey) a common thing?

Kylotan, with your gui system, at what time do you setup the projection matrix for correct rendering of your gui objects? Are they all tossed into a common class for this handling, and can only be properly used by inserting themselves into that class? Or, are your screen elements self contained? as to say i could do:

Button *but = GetButton();
but->Render();

And it will render correctly?
vs. a possible:

Button *but = GetButton();
interface->Add( but );
interface->Render() {
setup projection here
recurs render elements and children
reset orig projection
}

Thanks for the input. ^sf

^