We have a several large MFC applications which presently call a COM object to bring up a complex dialog. We would like to integrate the dialog into the applications — we do not want to continue to use a COM object.
I’m investigating the possibility of building the dialog in .NET as a separate project (using Windows forms, not WPF) and providing a second C++/CLI project which calls it and which can be called from ordinary C++ code. This structure is so that the several applications that need to incorporate the dialog can just pick up the projects in their solutions. (The apps are legacy apps, and rewriting them extensively is not possible — we’re slowly moving them to .NET, but this is a multi-year project. Converting the apps to C++/CLI is not an option.)
I’ve built this and tested it from a model application, but so far I’m unable to get it to work in the simplest of the large apps, and based on some things I’ve read, I’m beginning to doubt that it is possible. (See this link, especially. I’m aware of this Stackoverflow question, but it does not seem to be relevant.)
So. Is this even possible? Any suggestions on how to proceed?
I finally solved this problem with the help of a very good Microsoft support specialist. There were two problems, one was that the Boost library’s threading is incompatible with C++/CLI in its default state. One solution is to compile with a different set of flags and then statically link it. The other is to use it as a dynamically linked DLL, which is what I wound up doing.
The second part of the solution is to set CLR threading in the linking property to STA, since OLE initializations fails with an unhelpful message if you don’t.