Правильный способ проверки от суб-до

В вашем случае кажется, что вы хотите использовать повторно используемый метод проверки, который проверяет общую часть вашей формы.

Шаг 1

Я бы не привязывал клики кнопок к нескольким обработчикам. Это затрудняет отладку кода и может сделать его непредсказуемым (что срабатывает первым?). Вместо этого привяжите событие click к одному обработчику на кнопку и выполните все действия, которые вы хотите в этом обработчике.

Шаг 2

Иногда вы можете захотеть, чтобы некоторые функции были распределены между обработчиками событий. В этом случае я бы создал отдельную функцию, которая возвращает значение, основанное на общей процедуре проверки, и вызовет это из отдельных обработчиков событий.

Вот пример:

    Public Function ValidateCommonFields() As Integer
        Dim returnValue As Integer = -1

        If String.IsNullOrWhiteSpace(MonthSelectBox.Text) Then
            Label1.Text = "You didn't select a month!"
            returnValue = 1
        Else
            Label1.Text = ""
        End If

        If String.IsNullOrWhiteSpace(YearSelectBox.Text) Then
            Label2.Text = "You didn't select a year!"
            returnValue = 2
        Else
            Label2.Text = ""
        End If
        If String.IsNullOrWhiteSpace(FilepathTextBox.Text) Then
            Label3.Text = "You didn't select a file!"
            returnValue = 3
        End If

        Return returnValue
    End Function

    Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles GrossRevenuButton.Click
        Dim validationStatus As Integer = Me.ValidateCommonFields()
        If validationStatus < 0 Then
            Gross_Revenue()
        Else
            Label4.Text = "Something went wrong!"
        End If
    End Sub

Пара других точек стиля:

В конце вашего метода Validator вы снова проверяете все поля. Это кажется ненужным, поэтому я опустил его из своей версии.

Если вам нужно вернуть значения, используйте функцию или переменную экземпляра, доступ к которой могут получить все функции.

Вы заметите, что я использую метод String.IsNullOrWhiteSpace() (представленный в .NET 4) для проверки строк для null. Это проверяет фактическое значение Nothing или строку: "" или строку с только пробелами "", поэтому это чистый способ чтобы проверить все вышеперечисленное. Некоторая документация здесь: http://msdn.microsoft.com /en-us/library/system.string.isnullorwhitespace(v=vs.110).aspx

Использование вызова, пока оно является допустимым синтаксисом, является довольно синтаксисом VBA старого стиля и может быть исключено. Я считаю, что это облегчает чтение кода.

Все это говорит о том, что, как вы делаете проверку, кажется странным.

.NET поставляется с модулями проверки полей формы, поэтому нет причин писать свои собственные (если только вам не нужны высоко настраиваемые функции), но в вашем случае это все обязательные поля, которые поддерживаются из коробка. Подробнее см. В этих ссылках:

• http: //msdn. microsoft.com/en-us/library/system.windows.forms.control.validating(v=vs.110).aspx
• http://blog.scosby.com/post/2010 /02/11/Validation-in-Windows-Forms.aspx

У вашей проверки есть «главный» недостаток. Вы проверяете каждую вещь самостоятельно, поэтому, если пользователь «создает» несколько ошибок проверки, это обеспечивает серьезный плохой UX. Пока мы находимся в UX, ваши сообщения об ошибках могут использовать некоторую любовь: вот небольшая помощь UX. SE

Самое простое исправление для этого - использовать двоичные флаги, похожие на следующие:

[Flags]
Enum ValidatorFlags As Integer
   MonthSelect = 1 ' 0001
   YearSelect  = 2 ' 0010
   FilepathBox = 4 ' 0100
End Enum

Любая комбинация этих флагов, как гарантируется, будет обратна для флагов, которые ее составляют (Sidenote: так работают разрешения linux).

В качестве побочного элемента: атрибут Flags, используемый в этом перечислении, и подробно описанный в этом вопросе SO , позволяет toString() magic (не то, что вам нужно). В принятом ответе (в настоящее время) вы также получите хорошее представление о том, как вы возвращаете исходные ошибки к флагам;) Код также отлично работает без него.

В дополнение к рассмотренным пунктам и очень приятный обзор xDaevax (который также привел меня к вопросу Flags на SO), я хочу упомянуть, что имена ваших контейнеров сообщений об ошибках являются ужасными.

Не указывайте свои переменные

Вместо Label1,2,3, ... используйте описательные имена, как и в ваших InputFields

тогда ваш код будет выглядеть примерно так:

Public Sub Validator 'leaving rest for brevity
    Dim Validator As ValidatorFlags
    If MonthSelectBox.Text = "" Then
       Validator |= ValidatorFlags.MonthSelect
       MonthErrorLabel.Text = "Please select a month."
    Else 
       MonthErrorLabel.Text = ""
    End If

    If YearSelectBox.Text = "" Then
        Validator |= ValidatorFlags.YearSelect
        YearErrorLabel.Text = "Please select a year."
    Else
        YearErrorLabel.Text = ""
    End If

    If FilePathTextBox = "" Then
        Validator |= ValidatorFlags.FilepathBox
        FilepathErrorLabel.Text = "Please select a valid filepath."
    Else
        FilepathErrorLabel.Text = ""
    End If
    Return Validator
End Sub

Действительно маленькая точка стиля, чтобы добавить к другим ответам: я лично предпочитаю String.Empty по пустым кавычкам. Я думаю, что это делает код более понятным. С первого взгляда сложно определить, есть ли пустые кавычки, одно пространство или исходный разработчик просто забыл заполнить текст.

Label1.Text = ""

Использование String.Empty устраняет эту двусмысленность.

Label1.Text = String.Empty