Return key causes system sound

[TheNortonZ]

I have a requirement where when the user is in an edit field, they should be
able to hit Enter(return).

When I do this, my system makes a noise as though an illegal entry has been
made.

Is there a reason it is doing this and is there a way to change it?

Thanks.

STom

 

[Robby]

Having the TextMode set to SingleLine will cause this behaviour. Users
should hit the [Tab] key to move to the next field. You can extend the
TextBox class so that it responds to [Enter] as if [Tab] was hit. I think it
would be a better idea simply to get them to start using [Tab] as this is
the norm for Windows apps.

Robby

 

[TheNortonZ]

Yes, I agree that it is normal in every Windows application in the entire
universe to do TAB. Unfortunately when you have whiney a#$ people who have
lived on mainframes or worse yet have only ever used Excel....you have to
give them the ability to hit enter to do something in the field.

I'm just going to let it beep at them. Hopefully it will drive them crazy
enough to move into the 21st century and use the tab key.

Thanks for the info though!

STom

Having the TextMode set to SingleLine will cause this behaviour. Users
should hit the [Tab] key to move to the next field. You can extend the
TextBox class so that it responds to [Enter] as if [Tab] was hit. I think
it would be a better idea simply to get them to start using [Tab] as this
is the norm for Windows apps.

Robby

I have a requirement where when the user is in an edit field, they should
be able to hit Enter(return).

When I do this, my system makes a noise as though an illegal entry has
been made.

Is there a reason it is doing this and is there a way to change it?

Thanks.

STom

 

[TheNortonZ]

Oh, but just in case I do decide to extend it, what do I override to get
this to happen?

STom

Having the TextMode set to SingleLine will cause this behaviour. Users
should hit the [Tab] key to move to the next field. You can extend the
TextBox class so that it responds to [Enter] as if [Tab] was hit. I think
it would be a better idea simply to get them to start using [Tab] as this
is the norm for Windows apps.

Robby

I have a requirement where when the user is in an edit field, they should
be able to hit Enter(return).

When I do this, my system makes a noise as though an illegal entry has
been made.

Is there a reason it is doing this and is there a way to change it?

Thanks.

STom

 

[Robby]

Well they are not on mainframes or in Excel so they need to learn the new
way for doing things. Don't give in. They need to upgrade.



Robby

Yes, I agree that it is normal in every Windows application in the entire
universe to do TAB. Unfortunately when you have whiney a#$ people who have
lived on mainframes or worse yet have only ever used Excel....you have to
give them the ability to hit enter to do something in the field.

I'm just going to let it beep at them. Hopefully it will drive them crazy
enough to move into the 21st century and use the tab key.

Thanks for the info though!

STom

Having the TextMode set to SingleLine will cause this behaviour. Users
should hit the [Tab] key to move to the next field. You can extend the
TextBox class so that it responds to [Enter] as if [Tab] was hit. I think
it would be a better idea simply to get them to start using [Tab] as this
is the norm for Windows apps.

Robby

I have a requirement where when the user is in an edit field, they should
be able to hit Enter(return).

When I do this, my system makes a noise as though an illegal entry has
been made.

Is there a reason it is doing this and is there a way to change it?

Thanks.

STom

 

[Robby]

Extending the TextBox consist of making a control and having it inherit from
System.Windows.Forms.TextBox instead of System.Windows.Forms.Control. In its
KeyPress event you can check if [Enter] was pressed and send [Tab] instead.
You should also restrict the TextMode property to SingleLine because this
extended TextBox will never be able to hold multiline text. Then you need
to use this control in place of the TextBox control.

HOWEVER, there is a much bigger problem. If they do not learn to hit [Tab]
instead of [Enter] to move to the next control then you will have to extend
EVERY control (MS controls and 3rd party controls) to this behavior. You
will basicly loose all the [Enter] key functionality of all your controls.
Look at the multiline problem above. This is total madness.

Every control expects [Tab] to move to a the next control. This is the
normal behavior in windows programs. Do you see the problem you will create
if you allow this to persist. The cost developement, debugging, supporting,
.... EVERYTHING goes skyward very quickly. This [Enter] extension may seem
cute on the form you are working on now BUT they will expect this
functionality on EVERY form and EVERY application you design. Start to add
ComboBoxes, CheckBoxes, ListBoxes, DataGrids, other MS and 3rd party
controls that deal with [Enter] differently than they deal with [Tab]. You
will basicly loose all the [Enter] key functionality of all your controls.
Look at the multiline problem above. Do you see what you are getting
yourself into.

They must upgrade their skills when moving to a new system. Hitting [Tab]
instead of [Enter] is not rocket science. They can't expect to move to a
new system and do everything the old way.

Robby

PS. hummm ... I just though of something. You could KeyPreview on the form
and send [Tab] when enter is pressed. That would simplify it. But it will
lead to other problems. Don't let them know that. Press the expensive to
develope and support line I rambled on about above. Ramble on about the
increased cost for current and future developement of the system.

End Users: Can't live with them, can't get rid of them with out people
asking lots of questions.

################

Oh, but just in case I do decide to extend it, what do I override to get
this to happen?

STom

Having the TextMode set to SingleLine will cause this behaviour. Users
should hit the [Tab] key to move to the next field. You can extend the
TextBox class so that it responds to [Enter] as if [Tab] was hit. I think
it would be a better idea simply to get them to start using [Tab] as this
is the norm for Windows apps.

Robby

I have a requirement where when the user is in an edit field, they should
be able to hit Enter(return).

When I do this, my system makes a noise as though an illegal entry has
been made.

Is there a reason it is doing this and is there a way to change it?

Thanks.

STom

 

[Robby]

Oh I just though of something else. In the KeyPreview your could switch the
[Enter] and [Tab] keys. When they hit [Enter] send [Tab] and when they hit
[Tab] send [Enter]. Still they will have to learn to hit [Tab] for the
[Enter] functionality and [Enter] for the [Tab] functionality. Silly isn't
it. So since they have learn something new anyway they might as well learn
to hit [Tab] for [Tab] functionality and [Enter] for [Enter] functionality.

The end result is the end users, while they sometimes know what they want
they almost never know what they need. It is up to us to analyse the
situation and developed the best solution. Stress to them that the
mainframe app has almost no user interface and that Excels user interface,
the worksheet, is tightly controlled. Let them know that if they want the
added power and flexibility of the application that they will have to learn
the new user interface interactions.

Robby

Extending the TextBox consist of making a control and having it inherit
from System.Windows.Forms.TextBox instead of System.Windows.Forms.Control.
In its KeyPress event you can check if [Enter] was pressed and send [Tab]
instead. You should also restrict the TextMode property to SingleLine
because this extended TextBox will never be able to hold multiline text.
Then you need to use this control in place of the TextBox control.

HOWEVER, there is a much bigger problem. If they do not learn to hit
[Tab] instead of [Enter] to move to the next control then you will have to
extend EVERY control (MS controls and 3rd party controls) to this
behavior. You will basicly loose all the [Enter] key functionality of all
your controls. Look at the multiline problem above. This is total madness.

Every control expects [Tab] to move to a the next control. This is the
normal behavior in windows programs. Do you see the problem you will
create if you allow this to persist. The cost developement, debugging,
supporting, ... EVERYTHING goes skyward very quickly. This [Enter]
extension may seem cute on the form you are working on now BUT they will
expect this functionality on EVERY form and EVERY application you design.
Start to add ComboBoxes, CheckBoxes, ListBoxes, DataGrids, other MS and
3rd party controls that deal with [Enter] differently than they deal with
[Tab]. You will basicly loose all the [Enter] key functionality of all
your controls. Look at the multiline problem above. Do you see what you
are getting yourself into.

They must upgrade their skills when moving to a new system. Hitting [Tab]
instead of [Enter] is not rocket science. They can't expect to move to a
new system and do everything the old way.

Robby

PS. hummm ... I just though of something. You could KeyPreview on the
form and send [Tab] when enter is pressed. That would simplify it. But
it will lead to other problems. Don't let them know that. Press the
expensive to develope and support line I rambled on about above. Ramble
on about the increased cost for current and future developement of the
system.

End Users: Can't live with them, can't get rid of them with out people
asking lots of questions.

################

Oh, but just in case I do decide to extend it, what do I override to get
this to happen?

STom

Having the TextMode set to SingleLine will cause this behaviour. Users
should hit the [Tab] key to move to the next field. You can extend the
TextBox class so that it responds to [Enter] as if [Tab] was hit. I
think it would be a better idea simply to get them to start using [Tab]
as this is the norm for Windows apps.

Robby

I have a requirement where when the user is in an edit field, they
should be able to hit Enter(return).

When I do this, my system makes a noise as though an illegal entry has
been made.

Is there a reason it is doing this and is there a way to change it?

Thanks.

STom