> 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
[quoted text clipped - 15 lines]
>>
>> STom
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?
[quoted text clipped - 20 lines]
>>>
>>> STom
Robby - 10 Dec 2004 23:23 GMT
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.
[quoted text clipped - 63 lines]
>>>>
>>>> STom