Trying to make text box 1 active after text box 2 has enter key pressed

[chris52672]

If I have text box 1 (Password Enter) and I have text box 2 (Password Reneter).

After text has been entered in text box 1 and the enter key is pressed to make text box 2 active (the curser will jump from text box 1 to text box 2.

Any ideas

[tlhintoq]

After text has been entered in text box 1 and the enter key is pressed to make text box 2 active (the curser will jump from text box 1 to text box 2.

Are you trying to ask "How do I make the cursor move from textbox1 to textbox2 when the user presses the enter key in textbox1?"

In textbox1 handle the KeyPress event something like this

        private void tbPassword_KeyPress(object sender, KeyPressEventArgs e)
        {
            if ((Keys)e.KeyChar == Keys.Enter) btnLogInRead_Click(this, EventArgs.Empty);
            if ((Keys)e.KeyChar == Keys.Up) tbName.Focus();
            if ((Keys)e.KeyChar == Keys.Right) btnLogIn.Focus();
        }
 

In this example you can see 3 different actions that could take place:
If [Enter] is pressed it is the same as clicking the "LogInRead" button. This is where you might want to have it shift fields. Me personally, I always expect an enter key to press the default button on the form.
If the [Up] arrow key is pressed, then focus shifts to the "Name" textbox.
if the [right] arrow key is press, focus shifts to the LogIn button (but doesn't click it)

[IanWright]

Far easier than that is to setup the tab index correctly for all your controls. It should then jump automatically I believe, certainly will if the user presses tab which is consistent with most password UI's.

[tlhintoq]

Its always easier to change the conditions that you want to match the behavior of the program, than to change the behavior of the program to match the user desires. But that's not the way we are supposed to write code. Coders do not tell the client how their work flow is supposed to go, or how they have to work the program to make it behave. We have a responsibility to provide a good user experience in addition to the requested functionality. "Good enough" is never good enough.

In this case BOTH should/could happen. The tab order should be set so standard WIndows conventions of tabing are followed. But the OP's stated desire was to have the same behavior when the [enter] key was pressed.

We love options.

Though I agree with you. Generally speaking I don't use [enter] as a tab. But it can be handy to monitor it just the same. For example you could have a Username and a Password text box with no [submit] button at all. Tab between the two fields and pressing [enter] checks the user's credentials. As you can see in the sample code I provided pressing [enter] is the same as clicking the LogIn button, not the same as tabbing to the next control.

This can let you provide more intuitive behavior than just [tab]. Notice that the up and down keys are mapped to other controls. I think its always nice for a user to not have to hit [tab] 47 times to get to a control directly above the current control. It doesn't take much to have all your text boxes in an array and to calculate that the control directly [up] is the one 16 before the current one, for example. [up] 3 times beats repeatedly mashing [SHIFT] + [TAB]