InputState
This class is a container for KeyHandlers? to make input distribution easier. Information about how to use different InputStates is given in the article for the InputManager. This text deals more about the internals.
Overview
What is it anyway? Any InputState can be associated with a certain state or mode in the game. This can be as simple as the in-game console or as complicated as a whole level. It doesn't actually matter, it's up to the programmer to decide. From this article's point of view, the important question is "What next?". Whenever input reaches an InputState, it is automatically sent to all registered InputHandlers. There is no active/inactive, only registered or not.
In most cases, there is only one InputHandler registered in an InputState. For instance, the console only needs an InputBuffer to accumulate text. For this reason InputState is only an abstract class. There are two derivates: SimpleInputStates and ExtendedInputStates, both explained below.
Creating and Destruction
That part is up to the InputManager as the constructors and destructors are private to all other classes. Call InputManager::getInstance().createInputState<InputState derivative>(string name, int priority) in order to get a new InputState. Very important: It really belongs to the InputManager, so it also takes care of its destruction (also in the case of an InputManager destruction!).
SimpleInputState
This is the easier one. It only supports exactly one InputHandler per device, which is mostly sufficient. With methods like setKeyHandler, you can add a KeyHandler (for instance a KeyBinder).
setHandler is quite special, as it will register one InputHandler for all devices, even if the device gets added with InputManager::reload().
ExtendedInputState
Behaves almost exactly like SimpleInputState, but stores an arbitrary number of InputHandlers for each device separately. It also updates the internal list when addHandler was called and the devices change.
Executors
There is a possibility to register an arbitrary function via Executor to be called whenever the state is actually activated (not only added to the list of active states) or deactivated.