DotNet UI with C++ backend - best way forward?

  • Thread starter Thread starter Takeshi
  • Start date Start date
T

Takeshi

Hi All,

I am impressed with the aesthetic (UI) appeal of DotNet, but not by much
else, like it's new fangled languages etc... I have a legacy C++ 3tier
application, which uses C++ DLLs. I would like to use the DotNet
frontend (e.g. the PL provided by infragistics). However, I don't want
to start messing about with Managed C++ etc. Is there anyway I can use
my C++ DLLs (and C++ code of my application) and "bind" them to a DotNet UI?

Any ideas/suggestions will be very much appreciated.

MTIA

Takeshi

PS: I want to minimise the risk of going out on a limb with a "new"
language that never catches on (Remember Visual J++?), to minimise
future maintainance issues. Consequently, I would much rather prefer
solutions that use "tried and tested" languages like C and C++
(*possibly* VB, but that won't be my first choice since that has also
been given the .NET treatment)
 
Takeshi said:
Hi All,

I am impressed with the aesthetic (UI) appeal of DotNet, but not by
much else, like it's new fangled languages etc... I have a legacy C++
3tier application, which uses C++ DLLs. I would like to use the DotNet
frontend (e.g. the PL provided by infragistics). However, I don't want
to start messing about with Managed C++ etc. Is there anyway I can use
my C++ DLLs (and C++ code of my application) and "bind" them to a
DotNet UI?

Any ideas/suggestions will be very much appreciated.
Click to expand...

You can use Interop from any .NET language to use your DLL as long as they
are straight functions. But you will have to use some .NET language to
implement your .NET front end. Even Interop this way may have some
marshalling issues if the .NET types and the DLL function signature types
are different, which will require some .NET marshalling attributes to get
things right. If you use MC++, you don't need to use Interop as IJW ( It
Just Works ) makes it unnecessary.

However if your DLL is C++ classes, you need to use MC++. You can then:
1) Recompile your DLL as an unmanaged DLL and add DLL functions which create
an object and a return a pointer and delete the object, all from within your
DLL. You will use this creation and deletion rather than 'new' and 'delete'.
Then you can have a pure MC++ front end operating with an unmanaged C++ back
end.
or
2) Create a mixed mode MC++ front end assembly which uses your DLL ( DLL
still needs to be compiled as unmanaged C++ DLL with whatever version of
VC++ you are using ). There are a number of things you need to do in order
to implement your mixed mode MC++ assembly, all documented in MSDN under
"Converting Managed Extensions for C++ Projects from Pure Intermediate
Language to Mixed Mode".
 
Hi Edward,

Thanks for the prompt response. Don't want to use MC++. What about if I
"extern C" my C++ DLLS (i.e. convert them to regular Win32 DLLs) and
then write the GUI logic in VB (calling the functions from VB) ?

Will that work?

Tks
 
Takeshi said:
Hi Edward,

Thanks for the prompt response. Don't want to use MC++. What about if
I "extern C" my C++ DLLS (i.e. convert them to regular Win32 DLLs) and
then write the GUI logic in VB (calling the functions from VB) ?
Click to expand...

It will work since you are using functions and not classes. You still have
to use Interop from VB AFAIK. I am not a VB programmer but I am pretty sure
that Interop applies to VB also, just like it does in C# and MC++. In C# and
C++, Interop works through Platform Invoke and the Dllimport attribute. I
don't know what the VB terminology for Interop is but I am sure it must
exist, and I suspect it is essentially the same as C# and C++. For questions
about VB itself, someone else will have to answer you.
 
Back
Top