那么我在这里的 WPF 中缺少什么？答案

【问题标题】：So what am I missing with this here WPF?那么我在这里的 WPF 中缺少什么？
【发布时间】：2008-08-26 10:51:34
【问题描述】：

背景：我有一个小视频播放应用程序，其 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 是这方面的基础。

如果我必须挂钩 WndProc，我不得不想知道--为什么？ Win32 有 sizing/sized、moving/moved、poscharging/poschanged 窗口消息，它们都很有用。为什么 WPF 不复制同一组事件？这似乎是功能上不必要的差距。

另外，这意味着 WPF 与特定的 USER32 相关的实现相关联。这意味着 MS 不能（例如在 Windows 7 或 8 中）反转显示层以使 WPF“原生”并模拟旧应用程序的 HWND 和 WndProcs——即使这正是 MS 应该做的。

【问题讨论】：

标签： wpf winapi

【解决方案1】：

好的，为了回答我自己的问题，我想念 Adorners（在我所做的任何搜索中都没有回来，所以他们似乎没有像他们应该的那样广为人知）。

不幸的是，它们似乎比 WndProc 覆盖要复杂得多，但我认为应该可以对它们进行粗暴处理，让它们做我想做的事情。

【讨论】：

是的，装饰器很方便，但他们最大的 imo 缺点是缺乏 XAML 支持——您必须手动编写所有代码，这很麻烦。我相信这将在即将发布的版本中得到改进。

【解决方案2】：

而且我似乎完全忽略了系统告诉我调整大小的位置。命中测试也是如此。

对于调整大小，您确实错过了SizeChanged 事件。 AFAIK 遗憾的是，.NET 中的 Window 上没有 OnSizeChanging、OnLocationChanging 和 OnStateChanging 事件

我看到了那个，但据我所知，它仅在大小更改后触发，而我需要在调整大小期间触发事件。除非我误读了文档和它居然连续开火？

它不会连续触发，但您可能可以使用 ResizeBegin 和 ResizeEnd 事件并能够做到这一点。

它们不是 WinForms 事件吗？

嗯，你是对的。

【讨论】：

【解决方案3】：

在代码中，您可以将 WindowStyle 属性设置为“无”，将 WindowsState 设置为“最大化”

我不确定 Xaml 会是什么样子。

【讨论】：

【解决方案4】：

您能否覆盖 ArrangeOverride 和/或 MeasureOverride 以弥补那些缺少的调整大小事件？ Measure 是第一遍，当布局需要调整新尺寸时发生，所以它有点像尺寸更改事件。

【讨论】：