Nicholas,
Thank you for your input, it definitely helps. With the ActiveX/COM
approach, I think you get everything except the ability to display the
output of the engine in the C# interface. I don't know how a C# app
would host an ActiveX control that is rendering to a native DirectX
Surface. Do you know of any techniques for presenting legacy custom VB
controls (say, an editable dataview) in a C# UI? If there are any, I
would think that the integration points would be similar.
One possibility I've considered is implementing a method in the C# GUI
that the engine could call whenever it completes the rendering of a
frame. This could be implemented in a COM-callable wrapper. If the
engine can render to standard memory buffer, that buffer could be passed
to the GUI for rendering via Managed DirectX. I think this *could* work,
but isn't exactly elegant.
Another approach would be to get the C++ engine to write to directly to
a Managed DirectX device declared in the C# UI. I think that Managed
DirectX is simply a C# abstraction layer that interfaces with the native
APIs. If that is true, one would think that you could get a reference to
the native DirectX device and expose it though COM. Your thoughts?
Nicholas Paldino [.NET/C# MVP] wrote:
John,
There are two ways I can think of making this happen. The first is to
expose the engine as an ActiveX control, and then add a reference to it in
your project, creating an ActiveX host and interop wrapper.
The second way is to create a managed wrapper, which exposes a managed
interface which you can just use natively in .NET code.
Hope this helps.