Переопределение WndProc() для дочерних элементов компонентов WinForms / Песочница / Хабр

Иногда функционала компонентов, предлагаемых Windows Forms, начинает не хватать. Основной метод расширения их функциональности — получение своих собственных компонентов, с помощью наследования от готового набора. В данном посте я хочу рассказать о переопределении метода WndProc(), который, как известно, получает все сообщения, адресованные компоненту.

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

Для разминки сначала переопределим WndProc() для самого ListView, а не для его ColumnHeader'ов. Будем ловить щелчки левой кнопкой мыши:

class FixedColumnsListView : ListView { protected override void WndProc(ref Message message) { const int WM_LBUTTONDOWN = 0x0201; switch (message.Msg) { case WM_LBUTTONDOWN: //делаем вид, что обработали сообщение: message.Result = (IntPtr)1; //записываем true в Result //(не обязательно, работает и без этого) //заканчиваем работу WndProc() //без вызова его для базового класса: return; } //так как мы не поймали ничего нас интересующего, //то спокойно отдаем сообщение на обработку WndProc() базового класса base.WndProc(ref message); } } * This source code was highlighted with Source Code Highlighter. Магические константы взять можно отсюда. Получаем ListView, который не реагирует на щелчки левой кнопкой мыши по своей рабочей области. Однако, любопытно то, что щелчки по заголовкам его столбцов все еще обрабатываются без всяких проблем. Перейдем к основной части, переопределению WndProc() для ColumnHeader'ов. Прежде всего, нам нужно получить их дескриптор (handle). Сделать это можно несколькими способами. Например, мы можем воспользоваться WinAPI-функцией SendMessage(): [DllImport("User32.dll")] public static extern IntPtr SendMessage(IntPtr hWnd, int msg, IntPtr wParam, IntPtr lParam); ... //в каком-нибудь методе нашего класса: const int LVM_GETHEADER = 0x1000 + 31; IntPtr columnHeadersHandle = SendMessage(this.Handle, LVM_GETHEADER, IntPtr.Zero, IntPtr.Zero); * This source code was highlighted with Source Code Highlighter. Константы, на этот раз, можно посмотреть тут. SendMessage() в данном случае вернет нам желанный дескриптор. Другой способ получить его — использовать GetWindow(). В связи с тем, что у ListView дочерний элемент только один, можно поступить так: [DllImport("User32.dll")] public static extern IntPtr GetWindow(IntPtr hWnd, uint uCmd); ... //в каком-нибудь методе нашего класса: const uint GW_CHILD = 5; IntPtr columnHeadersHandle = GetWindow(this.Handle, GW_CHILD); * This source code was highlighted with Source Code Highlighter. Теперь нам нужно добраться до WndProc() этого элемента. На помощь приходит готовый .NET-овский класс NativeWindow, который нужно унаследовать и переопределить в нем нужный метод. Опишем свой класс для работы с заголовками столбцов, реализуя в нем все нам необходимое: private class ListViewColumnHeaders : NativeWindow { public ListViewColumnHeaders(ListView parentListView) { const uint GW_CHILD = 5; IntPtr columnHeadersHandle = GetWindow(parentListView.Handle, GW_CHILD); //заменим полученный дескриптор на дескриптор экземпляра нашего класса this.AssignHandle(columnHeadersHandle); //теперь все сообщения, направленные к заголовкам таблицы, будут обрабатываться нами } protected override void WndProc(ref Message message) { const int WM_LBUTTONDOWN = 0x0201; const int WM_SETCURSOR = 0x0020; //событие изменения внешнего вида курсора switch (message.Msg) { case WM_SETCURSOR: case WM_LBUTTONDOWN: message.Result = (IntPtr)1; return; } base.WndProc(ref message); } } * This source code was highlighted with Source Code Highlighter. Отлавливая WM_SETCURSOR мы блокируем изменение курсора на растягивающий при наведении его на границы заголовков. Теперь нам осталось лишь использовать полученный класс по назначению. Инициализировать его будем внутри OnCreateControl() родительского ListView. Единственным оставшимся уязвимым местом получаемого компонента FixedColumnsListView будет то, что юзер сможет сделать AutoResize всех колонок нажав Ctrl-Num+, так что предусмотрим и это. Итоговый вариант: class FixedColumnsListView : ListView { [DllImport("User32.dll")] public static extern IntPtr GetWindow(IntPtr hWnd, uint uCmd); private ListViewColumnHeaders ColumnHeaders { get; set; } protected override void OnCreateControl() { base.OnCreateControl(); ColumnHeaders = new ListViewColumnHeaders(this); } protected override void OnKeyDown(KeyEventArgs e) { if (e.KeyValue == 107 && e.Modifiers == Keys.Control) { e.Handled = true; } else { base.OnKeyDown(e); } } } * This source code was highlighted with Source Code Highlighter. Желаемый эффект достигнут, заголовки стоят намертво, курсор не меняется раздражающе на растягивающий: Справедливости ради, стоит отметить, что отчасти такого же эффекта можно было добиться используя дефолтный ListView, добавив такой обработчик: private void listView_ColumnWidthChanging(object sender, ColumnWidthChangingEventArgs e) { e.Cancel = true; e.NewWidth = listView.Columns[e.ColumnIndex].Width; } * This source code was highlighted with Source Code Highlighter. И еще один костыль для горячих клавиш. Однако, курсор все также обманывающе менялся бы, что, на мой взгляд, несолидно. Ну и кроме того, переопределением WndProc() можно добиться еще множества разных преимуществ. Например, реализовать нормальную работу со скролл-баром компонента.