Предыстория: у меня есть небольшое приложение для воспроизведения видео с пользовательским интерфейсом, вдохновленным почтенным Sasami2k, только что обновленным для использования VMR9 (т.е. Direct3D9 с DirectShow) и менее нестабильным. В настоящее время это приложение на C ++, использующее необработанный Win32 по необходимости: ни один из различных наборов инструментов не стоит ни черта. WPF, в частности, был невозможен из-за ограничений воздушного пространства.
Итак, теперь, когда существует D3DImage, можно было бы смешивать и сопоставлять D3D / VMR9 / DirectShow и WPF. Учитывая прошлые разочарования по поводу нерастяжимости Win32, это кажется хорошим делом.
Но знаешь, здесь я падаю на первое препятствие.
С помощью Win32 я создал (очень легко) окно без полей, размер которого можно изменять, пропорционально изменять размер, привязываясь к краям экрана и занимая весь экран (включая область панели задач) при максимальном увеличении. Это видео-приложение, так что все это весьма желательные свойства.
Итак, как сделать то же самое с WPF?
В Win32 я использую: WM_GETMINMAXINFO для управления поведением максимизации WM_NCHITTEST для управления границами изменения размера WM_MOVING для управления привязкой к краям экрана WM_SIZING для управления соотношением сторон изменения размера
Однако, глядя на WPF, кажется, что различные события приходят слишком поздно, если я не понимаю документацию?
Например, я не знаю, когда я нахожусь в середине хода, поскольку LocationChanged говорит, что он срабатывает только после перемещения окна (что уже слишком поздно). Точно так же кажется, что StateChanged срабатывает только после того, как окно было восстановлено / развернуто (когда мне нужна информация до максимизации, чтобы сообщить системе правильный максимальный размер).
И я, кажется, совершенно не замечаю, где система сообщает мне об изменении размеров. То же самое и с хит-тестированием.
Итак, я что-то здесь упускаю, или у меня нет другого выбора, кроме как вернуться к подключению wndproc этой штуки? Могу ли я делать то, что хочу, не подключая WndProc?
Если мне нужно использовать WndProc, я мог бы также придерживаться моей существующей кодовой базы; Я хочу иметь более простой и понятный код пользовательского интерфейса, и отказ от WndProc имеет принципиальное значение для этого.
Если мне нужно подключить WndProc, я должен задаться вопросом - почему? Win32 имеет сообщения об изменении размера, перемещении / перемещении, изменении и изменении окна, и все они полезны. Почему бы WPF не воспроизвести тот же набор событий? Похоже на ненужный пробел в функциональности.
Кроме того, это означает, что WPF привязан к конкретной реализации, зависящей от USER32. Это означает, что MS не может (скажем, в Windows 7 или 8) инвертировать слой отображения, чтобы сделать WPF «родным» и имитировать HWND и WndProcs для устаревших приложений - хотя это именно то, что MS должна делать.
