Так чего же мне не хватает с этим вот WPF?

Фон: у меня есть небольшое приложение для воспроизведения видео с UI, вдохновленное почтенным Sasami2k, только что обновленное для использования VMR9 (т. е. Direct3D9 с DirectShow) и менее нестабильное. В настоящее время это приложение C++, использующее raw Win32, по необходимости: ни один из различных наборов инструментов не стоит ни гроша. WPF, в частности, было невозможно из-за ограничений его воздушного пространства.

OK, так что теперь, когда существует D3DImage, вполне возможно смешать и сопоставить D3D/VMR9/DirectShow и WPF. Учитывая прошлые разочарования в неразрешимости Win32, это кажется хорошей вещью.

Но знаешь, я падаю на первом же препятствии здесь.

С помощью Win32 я создал (очень легко) окно без границ, которое можно изменять, изменять размер пропорционально, привязывать к краям экрана и занимать весь экран (включая область панели задач) при максимальном увеличении. Это видео-приложение, так что все это довольно желательные свойства.

OK, так как же сделать то же самое с WPF?

В Win32 я использую: WM_GETMINMAXINFO для управления максимизацией поведения WM_NCHITTEST для управления изменением размера границ WM_MOVING для управления snap-to-screen-edges WM_SIZING для управления соотношением сторон изменения размера

Однако, глядя на WPF, кажется, что различные события прибывают слишком поздно, если я не ошибаюсь в документации?

Например, я не знаю, когда я нахожусь в середине движения, так как LocationChanged говорит, что он срабатывает только после перемещения окна (что слишком поздно). Аналогично, похоже, что StateChanged срабатывает только после восстановления/максимизации окна (когда мне нужна информация до максимизации, чтобы сообщить системе правильный максимальный размер).

И я, кажется, совершенно упускаю из виду, где система говорит мне о размерах. Точно так же и хит-тестирование.

Итак, эм, я что-то упускаю здесь, или у меня нет другого выбора, кроме как вернуться к подключению wndproc этой штуки в любом случае? Могу ли я делать то, что хочу, не подключая WndProc?

Если мне придется использовать WndProc, я могу также придерживаться своей существующей кодовой базы; я хочу иметь более простой и чистый код UI, и уход от WndProc является фундаментальным для этого.

Если мне действительно нужно зацепить WndProc, я должен задаться вопросом - почему ? Win32 получил сообщения окна sizing/sized, moving/moved, poschanging/poschanged, и все они полезны. Почему бы WPF не повторить тот же набор событий? Это выглядит как ненужный пробел в функциональности.

Кроме того, это означает, что WPF привязан к конкретной реализации, зависящей от USER32. Это означает, что MS не может (скажем, в Windows 7 или 8) инвертировать слой отображения, чтобы сделать WPF "native" и эмулировать HWNDs и WndProcs для устаревших приложений-даже если это именно то, что должен делать MS.