背景：我有一个视频播放应用程序，其界面受古老的Sasami2k的启发，刚刚更新为使用VMR9(即DirectShow中的Direct3D9)，并且不那么不稳定。当前，它是一个使用原始Win32的C ++应用程序，这是必要的：各种工具包都不值得该死。由于其空域限制，特别是WPF无法实现。

好的，因此，既然D3DImage存在，则可以将D3D / VMR9 / DirectShow和WPF混合并匹配。鉴于过去对Win32的不可扩展性感到沮丧，这似乎是一件好事。

但是，我们知道，我在这里遇到了第一个障碍。

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

OK，那么，如何使用WPF进行相同操作？

在Win32中，我使用：
WM_GETMINMAXINFO控制最大化行为
WM_NCHITTEST以控制调整边框大小
WM_MOVING来控制对齐到屏幕边缘
WM_SIZING来控制调整尺寸的宽高比

但是，查看WPF似乎各种事件都来不及了，除非我对文档有误解？

例如，我不知道何时移动，因为LocationChanged表示仅在窗口移动后才触发(为时已晚)。
类似地，似乎只有在窗口恢复/最大化后才触发StateChanged(当我需要最大化之前的信息时，才告诉系统正确的最大化大小)。

而且我似乎完全忽略了系统告诉我有关调整大小的地方。同样，命中测试。

所以，嗯，我在这里错过了什么吗？还是别无选择，只能退回去钩住这个东西的wndproc了？我可以不挂WndProc而做我想做的事情吗？

如果必须使用WndProc，则最好还是保留现有的代码库。我想拥有更简单，更简洁的UI代码，而离开WndProc对此至关重要。

如果必须挂起WndProc，我想知道-为什么？ Win32拥有调整大小/大小，移动/移动，poschanging / poschanged窗口消息，它们都很有用。 WPF为什么不复制同一组事件？似乎在功能上存在不必要的差距。

另外，这意味着WPF与特定于USER32的实现相关联。这意味着MS不能(例如在Windows 7或者8中)反转显示层以使WPF成为"本机"，并且不能模仿旧版应用程序的HWND和WndProcs-即使这正是MS应该做的。

解决方案

回答

在代码中，我们可以将WindowStyle属性设置为" None"，将WindowsState设置为" Maximized"

我不确定Xaml是什么样的。

回答

And I seem to be completely overlooking where the system tells me about resizes. Likewise the hit testing.

对于调整大小，我们确实确实缺少SizeChanged事件。
不幸的是，在AFAIK中，.NET的窗口上没有OnSizeChanging，OnLocationChanging和OnStateChanging事件

I saw that one, but as far as I can tell it only fires after the size has changed, whereas I need the event to fire during the resize. Unless I'm misreading the docs and it 
  actually fires continuously?

它不会连续触发，但是我们可以使用ResizeBegin和ResizeEnd事件并能够执行该操作。

Aren't they WinForms events?

嗯，你是对的。

回答

好的，要回答我自己的问题，我很想念Adorners(在我进行的任何搜索中都没有回来，因此似乎并没有像应该的那样广为人知)。

不幸的是，它们似乎比WndProc重写要复杂得多，但是我认为应该有可能手动处理它们以执行我想要的操作。

回答

我们是否可以覆盖ArrangeOverride和/或者MeasureOverride来弥补那些丢失的调整大小事件？测量是第一遍，在布局需要调整为新大小时发生，因此有点像大小更改事件。