C ++ / CLI, XAML and event handlers

Question

I am new to the Windows world and I think I am getting lost in the weeds on the issue. I would like to get advice from people with experience with C ++ / CLI and WPF and XAML.

I have win32 code and I need to run the WPF GUI. I found this MS pass pattern that uses C ++ / CLI . I adapted it for my purposes and it works great.

Then I wanted to tear out WPF programming material and use XAML instead. This means that I can pass the XAML to the designer and get myself out of the UI design cycle, where I certainly don't belong. After reading the WPF Interaction Projects section of WPF and Win32 Interoperation on MSDN , I decided to go with the XamlReader::Load option and load the unbound XAML at runtime. My XAML markup is a Canvas UIElement , which I programmatically add as a child of my C ++ / CLI Grid root element. This works great.

Now I want to add an event handler to the controls in XAML. Here I began to run into problems. I am sure that my total ignorance of the Windows world is 95% of what killed me.

I started with a Rob Relyea page describing the various options for the XAML event handler .

I decided to try compiling XAML as a C # DLL. This is basically the same XAML as with boot. I instantiate the object and programmatically add it as a child, as before. But ... I get only a black window. Do not throw any exceptions. I am puzzled.

My question is: have I even taken the right path? On the XAML event-event handlers page, you can use the event handlers defined in uncompiled XAML in the .NET Framework 4. Should I bite a bullet and just upgrade to VS 2010 (now I am on VS 2008), so I can use .Net Framework 4 and just stick with unrelated XAML? Are there any problems with such matters?

Or, if you think the compiled C # DLL is the smart way, do you have any ideas on how I can debug the problems that I am having?

Or is there a better and completely different approach?

Thanks in advance for your advice.

ass

Answer 1

I think that the correct answer for this depends on some problems that only you can solve, but I will start by assuming that your C ++ code base is large and complex, that it should be kept.

In addition, the next solution point is that you have UI (possibly GDI) code in C ++ that you save or just non-UI code. If you are trying to save only code other than the UI, I would consider increasing the responsibility of the UI in C #. You may have gone so far as to create your own views, event handlers, and perhaps even view models in C #. This will allow you to better use the VS tool.

If you have an extended C ++ user interface code to save, your current path makes more sense. I do not think this will be impossible, but it will be a rather difficult task for you. The key example here is Visual Studio 2010. This is an example of the premiere of a mixed application and GDI and WPF side by side, unlike any other application that I have ever seen or heard. There are a number of blog posts that I found quite interesting that describe some aspects of what the Visual Studio team did to achieve this integration in the Visual Studio Blog .

I also stumbled upon this video by Henry Sovisral on Refacing C ++ with WPF in Expression Design , which I myself have not seen but discusses the issue of creating WPF UI on top of an existing MFC C ++ application.

Good luck.

I have no specific recommendations on the first part of your question, except to say that a big responsibility in C # will allow you to create a small stub application if necessary, which can significantly help diagnose problems.

Answer 2

Thanks to everyone for the answers. As for getting stuck in the C # DLL, I found this C ++ / CLI sample: http://msdn.microsoft.com/en-us/library/aa970266.aspx . Using this, I found my mistake and was able to download WPF without any problems.

However, the whole motivation for loading the C # DLL was that I realized that this was a way to programmatically handle event handlers. Following the suggestion of AresAvatar, I found that I can use FindName to attach handlers, both in the C # DLL and in my original free-XAML approach. So I do not need a C # DLL!

Now everything works beautifully. Thanks again for your help and suggestions.