Подтвердить что ты не робот

Почему некоторые текстовые поля не принимают Control + A ярлык для выбора всех по умолчанию

Я не знаю, является ли вопрос глупо, но я нахожу несколько текстовых полей здесь и там в моей собственной программе, которая принимает ярлык Control + A, чтобы выбрать весь текст "по умолчанию" с "без кодирования".

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

Примечание. Я не говорю об этом фрагменте кода:

if (e.Control && e.KeyCode == Keys.A)
{
    textBox1.SelectAll();
}

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

Изменить: Все остальное (Control + Z, Control + X, Control + C, Control + V) работает по умолчанию!!! Почему бы не Control + A??

Обновление: Текстовые поля, принявшие Ctrl+A по умолчанию, были маскированные текстовые поля, а не обычные. И в этот момент я был с .NET 2.0. Но я предполагаю, что исходная проблема была чем-то еще, поскольку я вижу, что <.NET > работает нормально по умолчанию в коде .NET 2.0.

4b9b3361

Ответ 1

Возможно, вы ищете свойство ShortcutsEnabled. Установка его в true позволит вашим текстовым полям реализовать ярлык Ctrl + A (среди прочих). Из документации:

Используйте свойство ShortcutsEnabled для включить или отключить следующие сочетания клавиш быстрого доступа:

  • Ctrl + Z

  • Ctrl + E

  • Ctrl + C

  • Ctrl + Y

  • Ctrl + X

  • Ctrl + BACKSPACE

  • Ctrl + V

  • Ctrl + DELETE

  • Ctrl + A

  • SHIFT + DELETE

  • Ctrl + L

  • SHIFT + INSERT

  • Ctrl + R

EDIT:
Однако в документации указано:

Элемент TextBox не поддерживает горячую клавишу Ctrl + A, когда Multiline значение true.

Вам, вероятно, придется использовать другой подкласс TextBoxBase, например RichTextBox, чтобы он работал.

Ответ 2

Действительно, CTRL + A не будет работать, если вы не добавите что-то вроде этого:

  private void textBox1_KeyDown(object sender, KeyEventArgs e)
  {
      if (e.Control && (e.KeyCode == Keys.A))
      {
          if (sender != null)
               ((TextBox)sender).SelectAll();
          e.Handled = true;
      }
  }

Ответ 3

Этот ответ работал у меня по аналогичному вопросу (который не отмечен как принятый)

protected override bool ProcessCmdKey(ref Message msg, Keys keyData)
{
    const int WM_KEYDOWN = 0x100;
    var keyCode = (Keys) (msg.WParam.ToInt32() &
                          Convert.ToInt32(Keys.KeyCode));
    if ((msg.Msg == WM_KEYDOWN && keyCode == Keys.A) 
        && (ModifierKeys == Keys.Control) 
        && txtYourTextBox.Focused)
    {
        txtYourTextBox.SelectAll();
        return true;
    }            
    return base.ProcessCmdKey(ref msg, keyData);
}

Оригинальное сообщение: Как разрешить ctrl + a с TextBox в winform?

Ответ 4

Убедитесь, что Application.EnableVisualStyles(); не комментируется в static void Main()

Это может отключить Ctrl + A

Ответ 5

Этот вопрос требует ответа, который нельзя дать в виде избежания кода, поскольку API Win32 в основе других методов не позволяет этого. Если другие методы разрешают это, они просто пишут код для вас.:)

Итак, реальный вопрос: какой самый маленький, опрятный способ сделать это? Это сработало для меня:

Во-первых, нет необходимости обрабатывать WM_KEYDOWN! И нет необходимости тестировать клавишу Ctrl уже вниз. Я знаю, что большинство примеров здесь (и CodeProject и многие другие) все говорят, что есть, но он не вылечивает звуковой сигнал, который возникает всякий раз, когда возникает WM_CHAR, который не обрабатывается.

Вместо этого попробуйте обработать WM_CHAR и сделать там Ctrl + A:

LRESULT CALLBACK Edit_Prc(HWND hwnd,UINT msg,WPARAM wParam,LPARAM lParam){
  if(msg==WM_CHAR&&wParam==1){SendMessage(hwnd,EM_SETSEL,0,-1); return 1;}
  else return CallWindowProc((void*)WPA,hwnd,msg,wParam,lParam);
}

Не забудьте подклассифицировать элемент управления EDIT на этот Edit_Prc(), используя WPA = SetWindowLong (...), где WPA - это адрес оконной процедуры для CallWindowProc (...)