C ++ / CLI, XAML и обработчики событий

Question

Я новичок в мире Windows, и я думаю, что теряюсь в сорняках из-за проблемы.Я хотел бы получить совет от людей с опытом работы с C ++ / CLI, WPF и XAML.

У меня есть код win32, и мне нужно запустить WPF GUI.Я нашел этот пример прохождения MS, в котором используется C ++ / CLI .Я адаптировал его к своим целям, и он прекрасно работает.

Далее я хотел бы извлечь программные материалы WPF и использовать вместо этого XAML.Это так, чтобы я мог передать XAML дизайнеру и вытащить себя из цикла разработки пользовательского интерфейса, к которому я совершенно точно не принадлежу.Прочитав раздел «Проекты взаимодействия WPF» в Взаимодействие WPF и Win32 на MSDN , я решил воспользоваться опцией XamlReader::Load и загрузить нескомпилированный XAML во время выполнения.Моя разметка XAML - Canvas UIElement, которую я программно добавляю как дочерний элемент моего корневого Grid C ++ / CLI элемента.Это прекрасно работает.

Теперь я хочу добавить обработчик событий к элементам управления в XAML.Это где я начал сталкиваться с неприятностями.Я уверен, что мое общее незнание мира Windows составляет 95% того, что меня здесь убивает.

Я начал со страницы Роба Рельея, в которой описаны различные опции XAML-и-обработчика событий .

Я решил попробовать скомпилировать XAML как C # DLL.Это в основном тот же XAML, что и в случае загрузки во время выполнения.Я создаю экземпляр объекта и программно добавляю его как ребенка, как и прежде.Но ... я не получаю ничего, кроме черного окна.Никаких исключений не выбрасывают.Я сбит с толку.

Мой вопрос, я даже направляюсь по правильному пути?На странице XAML-и-обработчиков событий сказано, что вы можете использовать обработчики событий, определенные в некомпилированном XAML в .Net Framework 4. Должен ли я прикусить пулю и просто перейти на VS 2010 (сейчас я на VS 2008), чтобы я мог использовать.Net Framework 4 и просто придерживаться скомпилированного XAML?Есть ли какие-то проблемы с такими действиями?

Или, если вы считаете, что скомпилированная C # DLL - разумный путь, есть ли у вас какие-либо идеи о том, как я могу отладить возникающие у меня проблемы?

Или есть ли лучшийи совсем другой подход?

Заранее спасибо за совет.

Полли

Answer 1

Я думаю, что правильный ответ для этого зависит от некоторых проблем, которые могут решать только вы, но я начну с предположения, что ваша кодовая база C ++ является большой и достаточно сложной, чтобы ее стоило сохранить.

Помимо этого, следующим моментом принятия решения является ли у вас код пользовательского интерфейса (возможно, GDI) в C ++, который вы сохраняете или только не-пользовательский код.Если вы пытаетесь сохранить только код, не относящийся к пользовательскому интерфейсу, я бы подумал о том, чтобы повысить ответственность пользовательского интерфейса в C #.Возможно, вы зашли так далеко, что создали свои представления, обработчики событий и, возможно, даже просмотр моделей в C #.Это позволит вам лучше использовать инструментарий VS.

Если у вас есть обширный код пользовательского интерфейса для сохранения в C ++, тогда ваш текущий путь имеет больше смысла.Я не думаю, что это будет невозможно, но у вас впереди немало проблем.Ключевым примером здесь является Visual Studio 2010. Это лучший пример смешанного приложения, в котором GDI и WPF соседствуют друг с другом, в отличие от любого другого приложения, которое я когда-либо видел или слышал.Есть ряд постов в блоге, которые мне показались довольно интересными и описывают некоторые аспекты того, что команда Visual Studio сделала для достижения этой интеграции на Блог Visual Studio .

Я также сталкивался с этимвидео Генри Совизрала о Refacing C ++ с WPF в Expression Design , который я сам не видел, но обсуждает возможность размещения пользовательского интерфейса WPF поверх существующего приложения MFC C ++.

Удачи.

У меня нет каких-либо конкретных советов по первой части вашего вопроса, кроме как сказать, что возложение большей ответственности на C # позволит вам при необходимости создать небольшое приложение-заглушку, которое может иметь большое значение для диагностики проблем.

Answer 2

Спасибо всем за ответы.Что касается застревания в C # DLL, я нашел этот пример C ++ / CLI: http://msdn.microsoft.com/en-us/library/aa970266.aspx. Используя это, я нашел свою ошибку и смог загрузить WPF без проблем.

ОднакоВесь мотив загрузки DLL на C # заключался в том, что я понял, что это способ программного присоединения обработчиков событий.Следуя предложению AresAvatar, я обнаружил, что могу использовать FindName для присоединения обработчиков - как в C # DLL, но он также работал с моим первоначальным подходом свободный XAML.В общем, мне не нужна C # DLL!

Теперь все работает хорошо.Еще раз спасибо за вашу помощь и предложения.