那么,我在WPF中错过了什么?

背景:我有一个小视频播放应用程序,其UI灵感来自古老的Sasami2k,刚刚更新为使用VMR9(即DirectShow的Direct3D9),不太稳定。目前,它是一个使用原始Win32的C++应用程序,出于必要:各种工具包都一文不值。特别是WPF,由于其空域限制而无法实现。

好的,既然D3DImage已经存在,那么混合和匹配D3D/VMR9/DirectShow和WPF可能是可行的。鉴于过去对Win32不可扩展性的不满,这似乎是一件好事。

但你知道,我在第一个栏就摔倒了。

使用Win32,我(非常容易)创建了一个无边框窗口,该窗口可以调整大小,按比例调整大小,捕捉到屏幕边缘,并在最大化时占据整个屏幕(包括任务栏区域)。这是一个视频应用程序,所以这些都是非常理想的属性。

好吧,那么,如何用WPF做同样的事情呢?

在Win32中,我使用: WM_GETMINMAXINFO用于控制最大化行为 WM_NCHITTEST用于控制调整边框大小 WM_MOVING用于控制屏幕边缘的捕捉 WM_SIZING用于控制调整大小的纵横比

然而,从WPF来看,各种事件似乎来得太晚了,除非我误解了文档?

例如,我不知道什么时候我正在移动,因为LocationChanged说它只在窗口移动后才会触发(这太晚了)。 同样,StateChanged似乎只在窗口恢复/最大化后才会触发(当我需要最大化之前的信息时,告诉系统正确的最大化大小)。

我似乎完全忽略了系统告诉我关于调整大小的地方。命中测试也是如此。

那么,嗯,我是遗漏了什么,还是我别无选择,只能重新连接这个东西的wndproc?我可以在不挂接WndProc的情况下做我想做的事情吗?

如果我必须使用WndProc,我不妨坚持使用我现有的代码库;我希望有更简单、更清晰的UI代码,而摆脱WndProc是实现这一目标的基础。

如果我必须钩住WndPoc,我不得不怀疑-- 为什么? Win32有大小/大小、移动/移动、位置更改/位置更改窗口消息,它们都很有用。为什么WPF不复制相同的事件集?这似乎是功能上不必要的差距。

此外,这意味着WPF与特定的USER32依赖实现相关联。这意味着微软不能(比如在Windows 7或8中)反转显示层以使WPF“原生”并为遗留应用程序模拟HWND和WndProcs——尽管这正是微软应该做的。