Блокировка автовыделения текста в поле EDIT

При создании диалогового окна, а также при перемещении по его элементам клавишей табуляции, текст в полях типа EDIT автоматически выделяется. Это стандартное поведение системы, так предусмотрено разработчиками Windows. Интересный вопрос, почему сделано именно так. Может быть самому Биллу Гейтсу было лениво нажимать кнопки Ctrl+A перед копированием текста из форм, может быть еще что-то, ответа я не знаю. Но зато у меня есть ответ на другой вопрос: можно ли сделать так, чтобы текст в поле EDIT автоматически не выделялся?

Перед тем, как принять решение о (не)выделении текста в поле EDIT, система посылает элементу диалогового окна сообщение WM_GETDLGCODE, которое должно вернуть соответствующий набор флагов. Так вот, если в ответе взведен флаг DLGC_HASSETSEL, то текст выделяется. Несложно догадаться, что по умолчанию этот флаг взводится всегда. При этом сообщение WM_GETDLGCODE самим диалоговым окном никак не обрабатывается, так что нужно воспользоваться уже известным нам субклассированием. Будь то разовое для конкретного поля или универсальное субклассирование, не важно.Важно то, что при поступлении элементу диалогового окна сообщения WM_GETDLGCODE, в итоговом ответе системе мы должны подавить флаг DLGC_HASSETSEL.

Делается это очень просто. В субклассированном обработчике элемента диалогового окна ловим сообщение WM_GETDLGCODE, отправляем запрос дальше по цепочке через CallWindowProc, но в полученном ответе сбрасываем соответствующий флаг DLGC_HASSETSEL:Теперь при первоначальной прорисовке диалогового окна или при путешествии по элементам окна при помощи табуляции, текст в субклассированном поле ввода выделен не будет. Цель достигнута.

Но раз уж речь коснулась сообщения сообщения WM_GETDLGCODE и сопутствующих флагов, то давайте еще разберем флаг DLGC_WANTMESSAGE. На секунду отвлечемся. Как известно, если в диалоговом окне нажать клавишу Esc, то окну будет отправлено сообщение WM_CLOSE, неважно, был ли в это время активен какой-нибудь из его элементов или было активно само окно. Возвращаемся к теме. Перед тем, как отправить сообщение WM_CLOSE главному обработчику диалогового окна, система интересуется, а нет ли у активного элемента диалогового окна желания как-то прореагировать на нажатие кнопки Esc? Опять же, как несложно догадаться, при стандартном поведении означенных элементов, такого желания у них возникать не должно. По умолчанию флаг DLGC_WANTMESSAGE возвращается сброшенным, но раз уж мы субклассировали обработчик элемента, то почему бы не обработать и этот флаг? Отрабатываем сообщение, как показано выше, затем для ответа взводим флаг DLGC_WANTMESSAGE. Таким образом главный обработчик диалогового окна никогда не узнает о том, что от него хотела система.В то же время мы можем легко узнать, какую кнопку нажал пользователь и какую реакцию системы стоит ожидать. Скан-код нажатой клавиши передается в параметре сообщения wParam. Так, для клавиши табуляции он равен 9, для Esc - 27 и так далее. Реакция поля ввода при этом может быть соответствующей. Например, при табуляции делаем вид, что ничего не происходит и не взводим флаг, курсор при этом перемещается дальше. А вот при нажатии Esc очищаем поле ввода и не передаем управление главному обработчику окна. Другие действия зависят от поставленной задачи.

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

Комментарии

Добавить комментарий

Для вставки цитаты выделите текст и нажмите сюда

Имя*:

Текст комментария (не более 2000 символов)*:

*Все поля обязательны для заполнения.

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