Jump to content
  • Advertisement
Sign in to follow this  
Joseph.N

A Two-Way Communication Path?

This topic is 2558 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello,

I will try to explain my problem here in my humble language.

I'm working on an application that uses .NET WinForms for the GUI part, and the core application functionality
is coded in C++ in different modules. So I have two main modules:

The managed/WinForm GUI only module

The native C++ DLLs

the communication between the two modules is as follows:

The main program launcher, which is the C# GUI, when it starts it links to
C++ DLLs exposed functions.

The communication is two-way:

C# sends mouse/kbd input to C++ modules and this is very straigh forward no problem at all.

The other way communication is tricky and I'm not sure how to best handle it.

The restriction is that C++ modules are pure native DLLs (no managed C++) or any kind of wrapping.
How can I send messages to the C# module without having to call C# functions?

For instance, I need to make the GUI show a dialog box as a response to some action occurred in the C++ module.

Latency and responsiveness here is very crucial, it should perform at real-time interactive level.

Any thoughts?

Thanks.

Share this post


Link to post
Share on other sites
Advertisement

Just make a C++/CLI wrapper to bridge between the native and the managed sides.


Unfortunately this does not work for me. I don't want to pollute pure C++ modules with any non-portable non-standard proprietary extensions. Not to mention the overhead involved there. C++ modules have to be 100% native!

What I was thinking of is a common intra-process messaging mechanism like the ones used for inter-process communication.

Thanks.

Share this post


Link to post
Share on other sites

[quote name='a_loho' timestamp='1307127003' post='4819173']
Just make a C++/CLI wrapper to bridge between the native and the managed sides.


Unfortunately this does not work for me. I don't want to pollute pure C++ modules with any non-portable non-standard proprietary extensions.
[/quote]

You're not going to be able to call C# from C++ without using some kind of proprietary extension or library!! Make the wrapper thin and isolated if you don't want the managed C++ to spread. The wrapper headers need only expose pure C++ interfaces.


What I was thinking of is a common intra-process messaging mechanism like the ones used for inter-process communication.
[/quote]
You aren't going to beat the speed of calling the C# code from managed C++.

Share this post


Link to post
Share on other sites

You aren't going to beat the speed of calling the C# code from managed C++.

Besides, pipes might not even work on the same process? And even if they did, that's a lot of work and twiddling to figure them out for not much benefit... documentation on them is "meh".

As suggested above, why not just make a 3rd dll to be a mediator between the two using C++/CLI?

Share this post


Link to post
Share on other sites
These modules will very likely be compiled once and used on different Windows platforms that may not support .NET. The idea is to be able to link the pre-built portable modules to different GUI frameworks which could be anything from WinForms to Qt to MFC...In short, we supply both components separately to clients. It may seem too ambitious but I will try figure out something...

Thanks.

Share this post


Link to post
Share on other sites
Then you need to define an abstract C++ interface with derived classes that talk to different GUIs, or an API with different implementations.

One derived class/API implementation would use managed C++ to talk to a .NET GUI, others would make calls to Qt widgets, and so on.

It sounds like your data model needs to know about the GUI, though. That's an unfortunate coupling that I recommend you avoid, if at all possible.

Share this post


Link to post
Share on other sites

It sounds like your data model needs to know about the GUI, though. That's an unfortunate coupling that I recommend you avoid, if at all possible.


Not at all.

Share this post


Link to post
Share on other sites
The C++/CLI Wrapper does not pollute your c++ module. Its a separate module used as an adaptator between the two worlds.
You end up with some kind of three tier architecture :
* your pure c++ module, it has no dependancy
* a C++/CLI module as adaptator, it depends from both the native module and the managed one
* a managed module that host your GUI, it only depends on the C++/CLI module

Share this post


Link to post
Share on other sites
There are other ways of communicating two apps if performance isn't a critical issue. Sockets, pipes, shared memory. You pick.

MHO is that you've already polluted your portable application by making the decision of using .NET for GUI.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!