So I originally had my input system set up with only the game part in mind. It listens to keyup/down events, marks the key as pressed/unpressed and then when the next update comes around, it sends out the state, and marks the current state as the previous state.
When I started implementing more complex UI elements, I realized this was a problem. Textboxes want to be notified of repeated keydown events so you can hold a key, scrollbars want repeated mouse down events, etc. On the other hand, the game only wants to know if a key is down and needs to keep track of the current/previous state for hotkeys and such.
What I would like to do is find a way to design the input system so it works for both cases. How can I support the repeating *down messages that the UI needs while also maintaining a current/previous input state that the game needs?
It occurs to me that I could perhaps just separate the two, using the input state manager only for the game input while hooking the UI manager directly into the keyboard/mouse input events. To me this seems less-than-ideal. For one, it seems a bit sloppy to be hooking the input in 2 different places. Also, doing so would remove the ability to send the current/previous input state to the UI. I'm not sure if this is even needed for the UI though. Maybe I'm just over-engineering things? I would like to have that ability if it's needed though. How have other people set up their input systems in such a situation?