WinForms Multiline Textbox, Enter key insists on moving focus out of textbox.

Question

I've got a multiline textbox and a button below it.

VB.NET, WinForms, .NET 2.0

System.Windows.Forms.Textbox

Multiline = True

AcceptsReturn = True

AcceptsTab = False

CausesValidation = False

No Events explicitly coded.

I'd like the Enter key to insert line-feeds and never move the focus to the next control (the button).

I'd like the Tab key to always move the focus to the next control in the tab order (the button).

What happens instead is that the Enter key inserts one line-feed and then moves focus to the next control (the button). It also does this with Ctrl-Enter, which really baffles me!

By my reading of the help files and extensive googling, it should work the way I need it to. But obviously I'm missing something. What am I doing wrong?

Answer 1

It definitely shouldn't do that. The only thing I can think is it's not got enough height to accomodate multiple lines. Try adding...

textBox1.ScrollBars = ScrollBars.Vertical

If not I don't know. Try creating a blank project and creating a form with one text box, one button set the properties and see what happens...

Answer 2

A method I often use for this sort of problem is to iteratively add and subtract code until I can narrow it down to the one thing that caused the problem.

For instance, you might start by making a very simple project with just one edit box and one other control, and see what it does. If this code behaves the way you want it to, then you can start adding code bit by bit, getting the simple project closer and closer to intended final product, until the bug appears. Then look at the last bit of code you added, and see if you can subtract bits of that until the bug goes away. Iterating this a few times might help you find the culprit.

Alternatively, you could start with your existing (misbehaving) code, and start simplifying it until the bug goes away. Then you add back part of the last thing you deleted, and iterate as above.

Lastly, in this case you could also try adding an event handler for the edit control's Leave event, and put a breakpoint in the handler. When the BP hits, check the callstack and see if you can get an idea of what code precipitated the focus change. For this to work, your debugger will probably need to be configured to display code that you don't have source for (i.e. disable the Just My Code option in the debugger). You could even paste a (trimmed) callstack into the question if you want to get the group's help in deciphering it.

p.s. Does anybody have a name for the iterative debugging method described above? If not, may I propose calling it Newton's Method (or perhaps Newtoning), since it resembles Newton's Method for iteratively finding roots of mathematical functions.

Answer 3

Turns out that I had forgotten that I had done this (below) elsewhere on the same form:

'http://duncanmackenzie.net/blog/Enter-Instead-of-Tab/default.aspx
Protected Overrides Sub OnKeyUp(ByVal e As System.Windows.Forms.KeyEventArgs)
    If e.KeyCode = Keys.Enter Then
        e.Handled = True
        Me.ProcessTabKey(Not e.Shift)
    Else
        e.Handled = False
        MyBase.OnKeyUp(e)
    End If
End Sub

Answer 4

Charlie, sounds like you might be "unit testing."