Справочная информация: у меня есть небольшое приложение для воспроизведения видео с пользовательским интерфейсом, вдохновленным почтенным 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.