views:

923

answers:

2

Hi all;

My problem seems to be quite simple, but it's not working the intuitive way.

I'm designing a Windows Forms Application, and there is a dialog that should NOT exit when the enter key is pressed, instead it has to validate data first, in case enter was pressed after changing the text of a ComboBox.

I've tried by telling it what to do on KeyPress event of the ComboBox if e is the Enter key:

Private Sub ComboBoxSizeChoose_KeyPress(ByVal sender As System.Object, ByVal e As System.Windows.Forms.KeyPressEventArgs) Handles ComboBoxSizeChoose.KeyPress
    If e.KeyChar = Convert.ToChar(Keys.Enter) Then
        Try
            TamanhoDaNovaFonte = Single.Parse(ComboBoxSizeChoose.Text)
        Catch ex As Exception
            Dim Dialogo2 As New Dialog2
            Dialog2.ShowDialog()
            ComboBoxSizeChoose.Text = TamanhoDaNovaFonte
        End Try
    End If
End Sub

But no success so far. When the Enter key is pressed, even with the ComboBox on focus, the whole dialog is closed, returning to the previous form. The validation is NOT done at all, and it has to be done before exiting. In fact, I don't even want to exit on the form's enter KeyPress, the only purpose of the enter key on the whole dialog is to validate the ComboBox (but only when in focus, for the sake of an intuitive UI).

I've also tried appending the validation to the KeyPress event of the whole dialog's form, if the key is Enter. NO SUCCESS! It's like my code wasn't there at all.

What should I do?

(Visual Studio 2008, VB.NET)

A: 

Although not your answer, I would recommend against using exceptions to control logic flow. That said, try Single.TryParse instead to make your flow less...well, exceptional.

To change the behavior you are seeing, change the dialog's AcceptButton from your Ok button to none. Changing that button's DialogResult to None doesn't keep the click event from firing, only from closing the dialog. Although the behavior may sound like something you desire, the result does not.

Marc
Thanks! but is it resource expensive to use try/exceptions?It seems more intuitive this way, since it's a private sub just used sometimes.
Camilo Martin
+3  A: 

Make sure you don't have a Button on the dialog that is set to something other than DialogResult.None.

For example, if you have a button set to DialogResult.OK, it will act as the "default" button and close your form.

Reed Copsey
This will prevent the dialog from closing, but now the OK button doesn't perform how it is expected to.
Marc
You need to add a click event handler to the OK button, and set the form's DialogResult property, then just close the form. This will make it still behave like a dialog, but force the user to use the mouse instead of being able to hit Enter to close the dialog.
Reed Copsey
@Reed, what you are describing is already the default behavior in VB .NET winforms. The OK button has a click event handler that sets the dialog result and closes it.
Marc
No. I'm referring to the Button's property. There is a Button.DialogResult property, which will cause this result if you use ShowDialog, SEPARATELY from an explicit click event handler. It has the same effect, but also "traps" and does this when you hit enter. I'm saying you need to change that to "None", then put an explicit click handler in place (subscribe to the event). For the property info, see: http://msdn.microsoft.com/en-us/library/system.windows.forms.button.dialogresult.aspx
Reed Copsey
So, if my form's AcceptButton is set to the okay button (which it is by default in the VB dialog template) and I write the click event handler you are referring to (which is also already there by default) but set the button's DialogResult property to None, it will all work? With all due respect, I did just that and the behavior persists.
Marc
You need to clear out the AcceptButton property, too.
Reed Copsey
Thanks, it solved the Enter key issue, it no longer exits. But, as weird as it may be, the KeyPress event seems to do nothing when it happens on the ComboBox. It's annoying, but I've decided to workaround using the TextUpdate event. Thanks for helping =)
Camilo Martin