Здравствуйте, mangaman, Вы писали:
F>>Полагаю то, что контрол должен быть именно контролом WPF, а не заврапленным winforms контролом или заврапленным (нативным) окном. M>Я вот как раз эту разницу не понимаю
В классическом Win32/Gdi32/User32 API — каждый контрол — это отдельное окно, например создаваемое через системный вызов CreateWindow (диалоги оставим в покое). Т.е. ещё раз повторю — контрол это окно. WinForms — оборачивают эти системные API в вид более удобный для изпользования в .NET.
Ещё давно существовали т.н. window-less фреймворки, когда создаётся всего одно окно, а для контролов — не создаются — фреймворк же отрисовывает эти контролы (при этом в обоих случаях они отрисовывают сами себя). Вот WPF — это windowless фреймворк, любой браузер — использует схожий подход.
При этом в WPF есть WinFormsHostControl по моему называетя, и позволяет захостить в WPF-окне — "старые" WinForms контролы. Однако при этом, часть функционала потеряется — ну например если идут трансформации (перспектива, повороты) — то для WPF контролов они применимы, а для нативных — нет. Нативное окно всегда прямоугольное (или квадратное).
UPD; Ну если хочется углубится — то лучше взять соответствующие книги.
Здравствуйте, mangaman, Вы писали:
M>Объясните, пожалуйста, на пальцах, что может означать требование "Works natively in a WPF .NET (no hosting necessary)", относящееся к .NET контролу?
Если через аналогии, то WinForms и WPF — это как Windows и Linux — их программы(контролы) несовместимы. Но можно сделать интерпретатор для линукса, который будет разбирать виндовую программу и исполнять. Вот этот интерпретатор — hosting винформсных контролов в WPF приложении.
Смысл такой, у меня есть некое графическое приложение на WinAPI\C++, которое использует DirectX 9 для рендеринга в окно. Мне нужно на его основе сделать wpf компонент, который works natively in WPF. Т.е. рендерить не в окно, а в этот компонент, который (видимо) можно произвольно размещать на формах.
С какой стороны подойти к задаче? Может кто-то посоветует сэмпл\статью с решением? Я пока нагуглил D3DImage компонент. Но может есть более правильные пути?
Тогда твой компонент мог-бы рисовать себя на поверхность, скажем в памяти. А WPF компонент — эту поверхность уже в "контрол".
Т.е. да, нужно что-то вроде D3DImage. Я бы смотрел в этом направлении, но слишком глубоко я не изучал — наверняка кто-то уже делал подобное — нужно или искать или копать.
PS: В практическом смысле, если проблемы будут именно с эффективным трансфером DX поверхностей — то можно для начала упростить и блитить через системную память. Но это уже вопрос приоритетов/оптимизации.
Здравствуйте, mangaman, Вы писали:
M>Я пока нагуглил D3DImage компонент. Но может есть более правильные пути?
D3DImage правильный, но на отладку уйдёт заметное время.
Обрати внимание на потерю контекста (реакцию на Ctrl+Alt+Del), resize, масштабирование для high DPI.
Но ты сначала выясни у клиента или босса, подойдёт ли им D3D interop. А то может под native имели в виду, шоб ты всю графику переделывал с D3D на WPF.
