WinForms Проверяющее событие предотвращает закрытие формы клавиши Escape

Ответ 1

Да, это неудобная причуда метода ValidateChildren. Он не знает, что отмена была задумана. Вставьте этот код, чтобы устранить проблему:

    protected override void OnFormClosing(FormClosingEventArgs e) {
        base.OnFormClosing(e);
        e.Cancel = false;
    }

Чтобы избежать выполнения обработчика события Validate, вызывающего побочные эффекты, например, окна сообщения, добавьте этот оператор в начало метода:

    private void txtName_Validating(object sender, CancelEventArgs e)
    {
        if (this.DialogResult != DialogResult.None) return;
        // etc..
    }

Вставьте этот код в свою форму, чтобы установить набор DialogResult, прежде чем он попытается подтвердить форму:

    protected override bool ProcessDialogKey(Keys keyData) {
        if (keyData == Keys.Escape) this.DialogResult = DialogResult.Cancel;
        return base.ProcessDialogKey(keyData);
    }

Ответ 2

Я просто видел эту проблему, так как я искал решение для нее, и переопределение ProcessdialogKey является одобренным MS решением, пока они не исправят ошибку (Escape должен делать то же самое, что и нажатие Cancel). Обсуждение этой ошибки также найдено здесь (просто работа с Visual Basic вместо С#. Ошибка старше 5 лет и, по-видимому, еще не исправлена): Ошибка или функция? CancelButton vs Escape Key Я пытаюсь выработать решение на С++.

Изменить для добавления: Решение из ссылки в С#:

protected override bool ProcessDialogKey(Keys keyData)
{
    if (keyData == Keys.Escape)
    {
        this.AutoValidate = AutoValidate.Disable;
        cancelButton.PerformClick();
        this.AutoValidate = AutoValidate.Inherit;
        return true;
    }
    return base.ProcessDialogKey(keyData);
}

Ответ 3

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

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

ИМО это довольно затормозило, что они запускают проверку на побег. Кто-нибудь знает, какова идея этого, потому что это не ошибка... но это ошибка.

Если бы этот код вызывал base.ProcessDialogKey(keyData) вместо cancelButton.PerformClick, тогда вы были бы ближе к решению, так как кто-то другой мог бы определить, что делать с ключом эвакуации. Но установка AutoValidate на Disabled здесь, а затем возврат его к исходному значению не препятствует проверке, поскольку он, вероятно, просто для того, чтобы просто отправлять события и помещать сообщение в очередь, не использует это значение до тех пор, пока оно не будет установлено к нему оригинальное значение.

Просто установив для параметра "Отключено" и не возвращая его к исходному значению, он будет работать, но если ключ-побег будет перехвачен, например, вышеупомянутое упакованное combobox, то вы внезапно отключили проверку также на OK.

Туше!

У кого-нибудь есть другие яркие идеи о том, как заставить это работать, без необходимости указывать всевозможные виды управления, которые делают и каковы условия, когда им нужно бежать, например. control - это ComboBox и проверьте, не упало ли оно и если это произойдет.

Ответ 4

Ни обработчики ProcessDialogKeys, ни ответы Validating обработчика не работали для меня, возможно потому, что я использую errorProvider вместо MessageBox. Самый простой ответ, который я получил на работу, - это забыть о Validating и просто использовать следующее: -

buttonOk.Click += (_,__) =>
{
  if(txtName.Text.Length == 3)
  {
    errorProvider1.SetError(txtName, "Wrong Length!");
    DialogResult = DialogResult.None;
  }
  else
  {
    errorProvider1.SetError(txtName, string.Empty);
  }
};