How do I make an application with C# Form and native C++ ?

[Steve]

I am working on an application that needs fancy UI. That's why I select C#
form instead of MFC.
But all functionalities are done in C++. How do I combine them together?

Managed C++ would cause too much effert to change. Besides, I need to spend
time to learn it.

thank you very much.

steve

 

[Pavel Minaev]

I am working on an application that needs fancy UI. That's why I select C#
form instead of MFC.
But all functionalities are done in C++. How do I combine them together?

Managed C++ would cause too much effert to change. Besides, I need to spend
time to learn it.

First of all, it's C++/CLI now, not Managed C++. Those are two very
different things, and MC++ is deprecated.

Second, if you merely want to use WinForms (and visual designer, etc),
you don't need C# at all. You can do it all completely in C++/CLI.

And finally, if you're unwilling to learn C++/CLI, then there's really
nothing else I can recommend to you. That language was designed
precisely for situations such as you describe, and allows you to do
what you want with minimal effort. If you aren't even willing to take
that effort, then I don't see how else it is possible to help you
there.

 

[Steve]

Hi Pavel:

I need WinForm to make a good-looking UI (provided by artists).
I also have a C++ network library done by the other team. and 2 game
applications.
Combine all these. I should make a portal / lobby application for
match-making.

Is C++/CLI is the only solution?
thank you.

steve

"Pavel Minaev" <[email protected]>
???????:[email protected]...

I am working on an application that needs fancy UI. That's why I select C#
form instead of MFC.
But all functionalities are done in C++. How do I combine them together?

Managed C++ would cause too much effert to change. Besides, I need to
spend
time to learn it.

First of all, it's C++/CLI now, not Managed C++. Those are two very
different things, and MC++ is deprecated.

Second, if you merely want to use WinForms (and visual designer, etc),
you don't need C# at all. You can do it all completely in C++/CLI.

And finally, if you're unwilling to learn C++/CLI, then there's really
nothing else I can recommend to you. That language was designed
precisely for situations such as you describe, and allows you to do
what you want with minimal effort. If you aren't even willing to take
that effort, then I don't see how else it is possible to help you
there.

 

[Steve]

Thank you, Peter:

Is P/Invoke the most common way to call C++ from C#?

Does C++/CLI work on all WinForm control functionalities?

Regarding Networking,

Do you mean System.Net namespace?

Our Network library is based on Winsock/Linux BSD socket.

Did you imply that there are some other Network library can replace winsock
?

Steve

 

[Steve]

Could the named pipe be the bridge between C# and unmanaged C++ application?

steve

 

[Ben Voigt [C++ MVP]]

First of all, it's C++/CLI now, not Managed C++. Those are two very
different things, and MC++ is deprecated.

Second, if you merely want to use WinForms (and visual designer, etc),
you don't need C# at all. You can do it all completely in C++/CLI.

I think that "WinForms in C++/CLI" is what he didn't want to learn. Because
the designers don't work well in that environment, there are definitely
advantages to writing the GUI in C#.

And finally, if you're unwilling to learn C++/CLI, then there's really
nothing else I can recommend to you. That language was designed
precisely for situations such as you describe, and allows you to do

It's designed to take reusable C and C++ libraries and wrap them into
reusable .NET components, not for creating WinForms GUIs in C++ (although
they tried, C++ was just too different from C# for the designers to work
well, so they're going away).

 

[Ben Voigt [C++ MVP]]

After all, if you do everything in C++/CLI, then you're dealing with the
syntax all the time. But if you do p/invoke, you only have to create the
p/invoke stuff once.

Yet another possibility is to wrap the network library in a managed
C++/CLI library, and then use that from C#. This gives you more explicit
control over how the unmanaged-to-managed conversion happens. But it's
not necessarily less work than just using p/invoke.

If the library interface is object-oriented, then this will be far far
easier than trying to bend p/invoke to do something it's not designed for.

If the library is a C-style API with implementation in C++, then p/invoke
will work ok, but C++/CLI wrappers will still be just as easy, with more
control.