Enter Key behavior

[=?Utf-8?B?TGlzYUNvbnN1bHQ=?=]

I have a data entry application. Due to ease and location, the users
utilizie the enter key to move from field to field, rather than the tab key.
Depending on the data they enter into a field, they may skip fields in the
"tab order" so I do not simply use process tab key. Application works fine
except for an oddity. There is a button on the form. If the user hits enter
to arrive on the button, then swaps (via MDI) to another form, (using
shortcut keys, not mouse) then uses another shortcut key to go back to first
form, even though you set focus to another control on the form, the enter key
will not leave the button. Subsequent use of the enter key is disabled until
you close the form and reopen it. Is there any workaround for this?

[Cor Ligthert [MVP]]

Lisa,

The best workaround is to help your clients to make them use to the tab key
telling that they give them self a disadvantage by not doing that. By
instance they get errors by every new employee they hire.

It is something the same as people who want still the steering wheel on the
back sit, just because they are used by it.
Cor

"LisaConsult" <li**********@online.nospamschreef in bericht
news:D2**********************************@microsof t.com...

>I have a data entry application. Due to ease and location, the users
utilizie the enter key to move from field to field, rather than the tab
key.
Depending on the data they enter into a field, they may skip fields in the
"tab order" so I do not simply use process tab key. Application works
fine
except for an oddity. There is a button on the form. If the user hits
enter
to arrive on the button, then swaps (via MDI) to another form, (using
shortcut keys, not mouse) then uses another shortcut key to go back to
first
form, even though you set focus to another control on the form, the enter
key
will not leave the button. Subsequent use of the enter key is disabled
until
you close the form and reopen it. Is there any workaround for this?

[Linda Liu [MSFT]]

Hi Lisa,

Based on my understanding, you have a WinForm application which contains an
MDI parent and several MDI child forms. On one MDI child form, there're
several TextBox and a Button. The users could press the Enter key to
navigate through the TextBox on the MDI child form. The problem is that
when the focus is on the button, and the user press Ctrl+Tab to switch to
another MDI child form, and then switch back to the previous MDI child
form, the Enter key won't work for navigation any more. If I'm off base,
please feel free to let me know.

I performed a test based on your description, but didn't reproduce the
problem on my side.

The following is the code to navigate through the TextBox controls on the
MDI child form in my test.

public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
this.textBox1.KeyUp += new KeyEventHandler(control_KeyUp);
this.textBox2.KeyUp += new KeyEventHandler(control_KeyUp);
this.textBox3.KeyUp += new KeyEventHandler(control_KeyUp);
this.textBox4.KeyUp += new KeyEventHandler(control_KeyUp);
this.button1.KeyUp += new KeyEventHandler(control_KeyUp);
}

void control_KeyUp(object sender, KeyEventArgs e)
{
if (e.KeyCode == Keys.Enter)
{
this.SelectNextControl(sender as Control, true, true,
false, true);
}
}
}

Is there any difference between your project and mine? If the problem is
still not solved, you may send me a sample project that could just
reproduce the problem. To get my actual email address, remove 'online' from
my displayed email address.
Sincerely,
Linda Liu
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[=?Utf-8?B?TGlzYUNvbnN1bHQ=?=]

Linda,
Thank you for your response. Your synopsis is correct, except that the user
actually uses a hot key which causes the move from screen to screen (not
Ctrl+Tab). The user enters text in Text1,Text2 and Text3 on Screen A, hit
enter and focus is on the button. Then they need to switch to screen B and
add a record. So, the user hits the hotkey (Ctrl+M) on MDI Parent. Screen A
is saved, control toggles to screen B, prepares for an insert and gives the
user control. User completes entry in screen B, then uses a hot key (Ctrl+A)
to toggle back to screen A. So user hits the hotkey, screen B is saved,
control toggles back to screen A, prepares for an insert and places the
cursor in Text1. You can see the blinking focus in Text1. Then user enters
value in text1 hits enter to go to Text2, but the control is actually at the
button. If the user attempts to use the mouse to move to Textbox2, they can,
but anytime enter is hit after that, enter is always designated as the
button. It's like somehow, in this sequence, the form decides to assume that
the button is set as the default Accept Button. If you leave the screen and
get back in, everything works fine. Please note that if a mouse is used in
the process, if the user doesn't move from screen to screen or if they use
the hotkey to insert a record on screen A, but don't move screens, the error
doesn't occur. We've checked code , but we've also seen (in this group) that
others have seen this problem as well, so we are wondering if there is a
workaround.

"Linda Liu [MSFT]" wrote:

Hi Lisa,

Based on my understanding, you have a WinForm application which contains an
MDI parent and several MDI child forms. On one MDI child form, there're
several TextBox and a Button. The users could press the Enter key to
navigate through the TextBox on the MDI child form. The problem is that
when the focus is on the button, and the user press Ctrl+Tab to switch to
another MDI child form, and then switch back to the previous MDI child
form, the Enter key won't work for navigation any more. If I'm off base,
please feel free to let me know.

I performed a test based on your description, but didn't reproduce the
problem on my side.

The following is the code to navigate through the TextBox controls on the
MDI child form in my test.

public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
this.textBox1.KeyUp += new KeyEventHandler(control_KeyUp);
this.textBox2.KeyUp += new KeyEventHandler(control_KeyUp);
this.textBox3.KeyUp += new KeyEventHandler(control_KeyUp);
this.textBox4.KeyUp += new KeyEventHandler(control_KeyUp);
this.button1.KeyUp += new KeyEventHandler(control_KeyUp);
}

void control_KeyUp(object sender, KeyEventArgs e)
{
if (e.KeyCode == Keys.Enter)
{
this.SelectNextControl(sender as Control, true, true,
false, true);
}
}
}

Is there any difference between your project and mine? If the problem is
still not solved, you may send me a sample project that could just
reproduce the problem. To get my actual email address, remove 'online' from
my displayed email address.
Sincerely,
Linda Liu
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[=?Utf-8?B?TGlzYUNvbnN1bHQ=?=]

Cor,
Although your suggestion may seem logical to us, dataentry users who have
heavy number keypad use do not find the tab key to be practical for fast
entry. The loss in productivity is high. The app is a re-write and the
users could do it in VB6, so this is also causing huge questions about why we
are spending money for a rewrite when it's inefficient in user productivity.
We need a workaround that allows them to use the enter key. Thanks

"Cor Ligthert [MVP]" wrote:

Lisa,

The best workaround is to help your clients to make them use to the tab key
telling that they give them self a disadvantage by not doing that. By
instance they get errors by every new employee they hire.

It is something the same as people who want still the steering wheel on the
back sit, just because they are used by it.
Cor

"LisaConsult" <li**********@online.nospamschreef in bericht
news:D2**********************************@microsof t.com...

I have a data entry application. Due to ease and location, the users
utilizie the enter key to move from field to field, rather than the tab
key.
Depending on the data they enter into a field, they may skip fields in the
"tab order" so I do not simply use process tab key. Application works
fine
except for an oddity. There is a button on the form. If the user hits
enter
to arrive on the button, then swaps (via MDI) to another form, (using
shortcut keys, not mouse) then uses another shortcut key to go back to
first
form, even though you set focus to another control on the form, the enter
key
will not leave the button. Subsequent use of the enter key is disabled
until
you close the form and reopen it. Is there any workaround for this?

[=?Utf-8?B?TGlzYUNvbnN1bHQ=?=]

One additional note. When I return to Screen A, the focus of Text1 and the
button are both true even though I set focus to Text1. If I set
Button.enabled = False then the enter key does nothing on the form.
Form.Acceptbutton and Form.Cancelbutton are both nothing.

[ShaneO]

LisaConsult wrote:

I have a data entry application. Due to ease and location, the users
utilizie the enter key to move from field to field, rather than the tab key.
Depending on the data they enter into a field, they may skip fields in the
"tab order" so I do not simply use process tab key. Application works fine
except for an oddity. There is a button on the form. If the user hits enter
to arrive on the button, then swaps (via MDI) to another form, (using
shortcut keys, not mouse) then uses another shortcut key to go back to first
form, even though you set focus to another control on the form, the enter key
will not leave the button. Subsequent use of the enter key is disabled until
you close the form and reopen it. Is there any workaround for this?

Using VB 2005, I have experienced similar to you in the past and, as
strange as it may seem, discovered it was caused by a ToolStrip Control,
although mine was in relation to switching between Tabs on a TabControl,
not MDI forms. Are you using a ToolStrip Control on your Parent Form?
Is so, you may find this is where your problem comes from as it is
capturing the keystrokes when you return to your MDI form, even though
the focus appears to be with the button.

ShaneO

There are 10 kinds of people - Those who understand Binary and those who
don't.

[Linda Liu [MSFT]]

Hi Lisa,

Thank you for your prompt response and detailed explanation.

You have mentioned Screen A and B in your reply. Does the machine has two
monitors?

When the user presses Ctrl+M to switch to Screen B and add a record, is he
using another program, i.e. not the MDI program on Screen A?

I suggest that you set a break point in the KeyDown/KeyUp event handler in
the data entry form and press F5 to start the problem. After you switch to
Screen B and then switch back to Screen A, press the Enter key and debug
your program to see how the KeyDown/KeyUp event handler is executed.

Since the problem doesn't exist unless you switch to Screen B, I suspect
that the problem may be related to the driver of the display card on your
machine. If possible, you may have a try changing the hot key to switch
Screens to see if the problem still exists. You may also have a try
upgrading the driver of the display card, if any.

Hope this helps.
Sincerely,
Linda Liu
Microsoft Online Community Support

[Linda Liu [MSFT]]

Hi Lisa,

How about the problem?

If you need our further assistance, please feel free to let me know.

Thank you for using our MSDN Managed Newsgroup Support Service!

Sincerely,
Linda Liu
Microsoft Online Community Support