我一直在寻找关于为什么要覆盖wndproc处理消息的信息,但并没有看到太多的资料。
所以我想知道:
为什么要这样做?
何时需要这样做?
C#中它的一般目的是什么?
当我看到串行COM从计算机插入和拔出时,我尝试使用它,但我觉得我更善于依赖自己创建的方法。我看到的其他消息是关于按键、光标设置和其他各种操作的。话虽如此,大多数这些东西已经在C#库中有了内置方法。因此,我又回到了我的三个主要问题。任何信息,意见,示例等都将非常棒。
我一直在寻找关于为什么要覆盖wndproc处理消息的信息,但并没有看到太多的资料。
所以我想知道:
为什么要这样做?
何时需要这样做?
C#中它的一般目的是什么?
当我看到串行COM从计算机插入和拔出时,我尝试使用它,但我觉得我更善于依赖自己创建的方法。我看到的其他消息是关于按键、光标设置和其他各种操作的。话虽如此,大多数这些东西已经在C#库中有了内置方法。因此,我又回到了我的三个主要问题。任何信息,意见,示例等都将非常棒。
WndProc()非常核心,对于Windows窗口的工作方式有很大影响。它是一个可管理的包装器方法,用于窗口过程,旧时以C语言编写的函数。这是您定制窗口行为的方式,使其对由操作系统或其他程序生成的通知做出不同响应。
通常情况下,您不需要覆盖它,基类中的WndProc()方法处理大多数基本通知。将它们转换为友好的.NET事件,例如Click等。但这并不完整,因为通知可能太模糊,或者因为它不能知道自定义窗口使用的消息,所以您可以退回到覆盖WndProc()来拦截消息。我能想到的最好的例子是创建无边框窗口以绘制自定义窗口框架,并仍为窗口提供正常行为。最容易通过拦截像WM_NCHITTEST这样的未包装 .NET 消息完成。
真正理解WndProc()需要阅读Petzold的开创性著作“Programming Windows”。也许今天已经不那么容易理解了,它假设基本了解C语言。30年前,Winapi的目标语言是C语言,面向对象的语言当时并不普遍或可用。这也能解释为什么在WndProc()内编写代码相当痛苦,因为几乎没有抽象性,您无法忽略指针。
Microsoft确实努力退役了它,从Windows 8和WinRT api开始。不算完全成功,也许Windows 10会有所发展。使WinRT在后台工作的基础技术是COM,比C语言大了一步,因为它可以支持对象模型。虽然在友好的语言投射中很好隐藏,但COM编程是大多数程序员会尝试避免的 :)
我发现,在处理UserControl的keypress事件时,它非常有用。
即使将KeyPreview设置为true等,keypress、keyDown或KeyUp事件也很难从UserControl做出响应。我发现,如果重写WndProc(),则可以更可靠地处理控件命令。