I am currently having problems from finding my way into the component-oriented XNA design.

I read an overview over the general design pattern and googled a lot of XNA examples. However, they seem to be right on the opposite site. In the general design pattern, an object (my current player) is passed to InputComponent::update(Player). This means the class will know what to do and how this will affect the game (e.g. move person vs. scroll text in a menu).

Yet, in XNA GameComponent::update(GameTime) is called automatically without a reference to the current player.

The only XNA examples I found built some sort of higher-level Keyboard engine into the game component like this:

class InputComponent: GameComponent
{
    public void keyReleased(Keys);
    public void keyPressed(Keys);
    public bool keyDown(Keys);

    public void override update(GameTime gameTime)
    {
        // compare previous state with current state and
        // determine if released, pressed, down or nothing
    }
 }

Some others went a bit further making it possible to use a Service Locator by a design like this:

interface IInputComponent
{
    public void downwardsMovement(Keys);
    public void upwardsMovement(Keys);
    public bool pausedGame(Keys);

    // determine which keys pressed and what that means
    // can be done for different inputs in different implementations
    public void override update(GameTime);
 }

Yet, then I am wondering if it is possible to design an input class to resolve all possible situations. Like in a menu a mouse click can mean "click that button", but in game play it can mean "shoot that weapon".

So if I am using such a modular design with game components for input, how much logic is to be put into the InputComponent / KeyboardComponent / GamepadComponent and where is the rest handled?

What I had in mind, when I heard about Game Components and Service Locator in XNA was something like this:

• use Game Components to run the InputHandler automatically in the loop
• use Service Locator to be able to switch input at runtime (i.e. let player choose if he wants to use a gamepad or a keyboard; or which shall be player 1 and which player 2).

However, now I cannot see how this can be done.

• First code example does not seem flexible enough, as on a game pad you could require some combination of buttons for something that is possible on keyboard with only one button or with the mouse)
• The second code example seems really hard to implement, because the InputComponent has to know in which context we are currently. Moreover, you could imagine your application to be multi-layered and let the key-stroke go through all layers to the bottom-layer which requires a different behaviour than the InputComponent would have guessed from the top-layer.
• The general design pattern with passing the Player to update() does not have a representation in XNA and I also cannot see how and where to decide which class should be passed to update(). At most time of course the player, but sometimes there could be menu items you have to or can click

I see that the question in general is already dealt with here, but probably from a more elobate point-of-view. At least, I am not smart enough in game development to understand it. I am searching for a rather code-based example directly for XNA.

And the answer there leaves (a noob like) me still alone in how the object that should receive the detected event is chosen. Like if I have a key-up event, should it go to the text box or to the player?