Почему вы переопределяете wndproc

Question

Я искал вокруг и на самом деле не видел много информации о том, почему кто-то переопределяет wndproc для обработки сообщений.

Так что интересно:

Почему это сделать?

Когда это сделать?

Какова его общая цель в C#?

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

Другие сообщения, которые я вижу, предназначены для нажатия клавиш, настроек курсора и других различных действий. При этом большинство из этих вещей уже встроено в методы в библиотеках C#. Поэтому снова я возвращаюсь к трем основным вопросам. Любая информация, мнения, примеры и т. Д. Были бы замечательными.

Answer 1

WndProc() очень, очень ядро ​​к способу работы окна Windows. Это метод управляемой обертки вокруг оконной процедуры , функции, которая раньше была написана на языке C. Это то, как вы настраиваете поведение окна, чтобы он реагировал по-разному на уведомления, созданные операционной системой или другими программами.

Обычно вам не нужно переопределять его, метод WndProc() в базовом классе обрабатывает большинство основных уведомлений. Превращение их в дружественные .NET-события, такие как Click и т. Д. Но это еще не так, потому что уведомление слишком неясное или обязательно так, потому что оно ничего не знает о сообщениях, используемых пользовательским окном. В этом случае вы можете отказаться от переопределения WndProc(), чтобы перехватить сообщение. Лучший пример, о котором я могу думать, - создать окно без полей для рисования пользовательского оконного фрейма и по-прежнему давать нормальное поведение в окне. Наиболее легко сделать, перехватывая сообщения, такие как WM_NCHITTEST, не обернутые .NET.

Поистине grokking WndProc() требует чтения оригинальной книги Петцольда «Программирование Windows». Возможно, сегодня это не так просто понять, он предполагает базовое понимание языка C. Какой язык был ориентирован на winapi 30 лет назад, объектно-ориентированные языки не были широко распространены или доступны в то время. Это также в противном случае объясняет, почему писать код внутри WndProc() довольно болезненно, очень мало абстракции, и вы не можете игнорировать указатели.

Microsoft сделала попытку уйти в отставку, начиная с Windows 8 и WinRT api. Не совсем удачный успех, может быть, Windows 10 придаст ему некоторую тягу. Основополагающая технология, которая заставляет WinRT работать под капотом, - это COM, большой шаг вверх от C, потому что он может поддерживать объектную модель. Хотя он хорошо скрыт в прогнозах дружественного языка, COM-программирование - это то, что большинство программистов постараются избежать :)

Answer 2

Я обнаружил, что он полезен для обработки событий нажатия клавиш для UserControl.

События Keypress, keyDown или KeyUp довольно тонкие при ответе с UserControl (даже если KeyPreview установлен в true и все такое). Я обнаружил, что если я переопределяю WndProc(), у меня гораздо больше надежности управления, обрабатывающего команду.