Является ли WindowsFormsHost подходящим для цели (.net WPF-хостинг WinForms)?

Ответ 1

В настоящее время мы используем WindowsFormsHost в нашем программном обеспечении для размещения элемента управления DataGridView WinForms, и у нас не было никаких реальных проблем с ним. Несколько вещей, на которые нужно обратить внимание:

Во-первых, ограничения воздушного пространства. Практически это означает, что содержимое WinForms всегда появляется поверх содержимого WPF. Поэтому, если вы используете WPF adorners, они будут "обрезаны", если они попадут в область WinForms в вашем приложении.

Во-вторых, поскольку они используют ресурсы Windows, вам необходимо более тщательно управлять временем жизни компонентов WinForms. В отличие от компонентов WPF, элементы управления WinForms предполагают, что они будут удалены, когда они закончатся. Это затрудняет включение их в чистый вид XAML.

Последнее, что элементы управления WinForms не изменяются так же плавно, как и остальная часть WPF-дисплея: они, как правило, приспосабливаются к их новому размеру после того, как вы закончили настройку.

Ответ 2

Одна из проблем, с которыми я столкнулся, заключается в том, что встроенные элементы управления Win Forms не участвуют ни в каких операциях преобразования, применяемых к их контейнеру WPF. Это приводит к визуальным проблесковым эффектам и встроенному управлению, появляющимся в неприемлемом месте. Я работал над этим, связывая видимость хоста Windows Forms с состоянием анимации своего контейнера WPF, так что встроенный элемент управления был скрыт до завершения анимации, как показано ниже.

<WindowsFormsHost Grid.Row="1" Grid.Column="1" Margin="8,0,0,0"
     Visibility="{Binding ActualHeight, RelativeSource={RelativeSource
     Mode=FindAncestor, AncestorType=UserControl},
     Converter={StaticResource WinFormsControlVisibilityConverter}}" >

     <winforms:DateTimePicker x:Name="datepickerOrderExpected" Width="140"
        Format="Custom" CustomFormat="M/dd/yy  h:mm tt"
        ValueChanged="OnEditDateTimeOrderExpected" />

</WindowsFormsHost>

Ответ 3

Я размещал элементы управления WPF в WinForms и наоборот без проблем. Хотя, я бы очень интенсивно тестировал такие сценарии, потому что трудно предсказать, как будет себя вести сложный контроль.

Ответ 4

Обратите внимание на отсутствие объекта WPF Application при размещении в Winforms. Это может привести к проблемам, если вы используете существующий компонент WPF и размещаете его в Winforms, поскольку поиск ресурсов и подобные пользователи никогда не будут выглядеть в области приложения. Вы можете создать свой собственный объект Application, если это проблема.

Ответ 5

Как отметил @Kent Boogaart, я столкнулся с ситуацией, когда приложение WPF, размещенное в WinForms, не имеет объекта приложения WPF (например, Application.Current). Это может вызвать множество проблем, таких как диспетчеры, не вызывающие потоки обратно в поток пользовательского интерфейса. Это применимо только в том случае, если вы размещаете в WinForms, а не наоборот.

У меня также были странные проблемы, когда модальные диалоги ведут себя странно (т.е. вызовы ShowModal). Я предполагаю, что это связано с тем, что в WinForms каждый элемент управления имеет свой собственный дескриптор Win32, хотя в WPF имеется только один дескриптор для всего окна.

Что бы вы ни делали, проверьте:)

Ответ 6

Вы можете решить проблему Airspace, используя .net 3.5 SP1:

Эти ограничения воздушного пространства представляют собой огромное ограничение в как WPF, где элемент композиция используется для создания очень богатый опыт пользователей. С D3DImage решение, эти ограничения не являются более длинный подарок!

См. Введение в D3DImage.