Sign in to follow this  
Joseph.N

A Two-Way Communication Path?

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
Just make a [url="http://blogs.microsoft.co.il/blogs/sasha/archive/2008/02/16/net-to-c-bridge.aspx"]C++/CLI wrapper[/url] to bridge between the native and the managed sides.




Share this post


Link to post
Share on other sites
[quote name='a_loho' timestamp='1307127003' post='4819173']
Just make a [url="http://blogs.microsoft.co.il/blogs/sasha/archive/2008/02/16/net-to-c-bridge.aspx"]C++/CLI wrapper[/url] to bridge between the native and the managed sides.
[/quote]

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='RecycledBytes' timestamp='1307127480' post='4819181']
[quote name='a_loho' timestamp='1307127003' post='4819173']
Just make a [url="http://blogs.microsoft.co.il/blogs/sasha/archive/2008/02/16/net-to-c-bridge.aspx"]C++/CLI wrapper[/url] to bridge between the native and the managed sides.
[/quote]

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.

[quote]
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
[quote name='edd²' timestamp='1307128349' post='4819187']
You aren't going to beat the speed of calling the C# code from managed C++.
[/quote]
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
[quote name='edd²' timestamp='1307136366' post='4819227']
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.
[/quote]

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
[quote]
[color=#1C2837][size=2]MHO is that you've already polluted your portable application by making the decision of using .NET for GUI. [/size][/color]

[/quote]

You are absolutely right. I just found that if one of my goals is portability then why I'm using .NET for GUI. I'm reconsidering my decision about .NET and switching to something more efficient better like Qt or GTK.

Thanks for all replies.

Share this post


Link to post
Share on other sites
[quote name='RecycledBytes' timestamp='1308234618' post='4824083']
You are absolutely right. I just found that if one of my goals is portability then why I'm using .NET for GUI. I'm reconsidering my decision about .NET and switching to something more efficient better like Qt or GTK.

[/quote]

If latency is really that important that marshalling overhead matters, then raw OpenGL will barely be enough, even with hardware acceleration of highest grade. Which obviously isn't even remotely available in any kind of portable fashion, since majority of chipsets in use barely support the minimum functionality. Portability has little to do with code itself but more with kernel functionality it requires. Anything high-performance, especially guaranteed performance will not be portable in general sense.

But it makes me wonder what kind of application would require such low latency. Even real-time hardware controls are usually limited to 15-30 fps.

And if running on LCD, then practical update rate is 60Hz. This is still a factor of 1000-1e6 slower than any kind of marshalling.

Share this post


Link to post
Share on other sites
This is relatively simple to handle if your unmanaged code is communicating through the use of callbacks, as all you have to do is provide the callback as a delegate to the unmanaged code. Your other options are to wrap your business logic in some sort of service/RMI framework.

WinForms is portable through the use of Mono, and Silverlight is portable through the use of Moonlight if you are interested in still pursuing .NET GUI technologies.

Edit: And latency certainly should not be an issue using callbacks.

Share this post


Link to post
Share on other sites
If you're talking about Windows why can't you just use the message functions of the Windows API to send messages to the application window via it's handle and have listener classes for incoming messages and handle those messages there? .Net and C++ are more than capable of interacting with the Windows API like this.

Share this post


Link to post
Share on other sites
[quote]
But it makes me wonder what kind of application would require such low latency. Even real-time hardware controls are usually limited to 15-30 fps.

[/quote]

It's a CAD application. The reason I'm concerned about latency and performance of the two-way communication layer is from user perspective. I have no guarantee that the users run the program on fast machines.
If this is the case the delay between user right-click, for example, and a pop-up menu on the GUI side will be, not a huge delay, but at least noticeable. Another situation is when the model updates and the GUI has to reflect this change there will be a noticeable delay too.

[quote]
If you're talking about Windows why can't you just use the message functions of the Windows API to send messages to the application window via it's handle and have listener classes for incoming messages and handle those messages there? .Net and C++ are more than capable of interacting with the Windows API like this.
[/quote]


Sounds a good idea. I will give it a go.

Share this post


Link to post
Share on other sites
[quote name='RecycledBytes' timestamp='1308288738' post='4824358']
Sounds a good idea. I will give it a go.
[/quote]

Not sure if you missed my post or not, but is there a reason why you are not using a callback mechanism for notifying your GUI of events? This prevents you from having to deal with platform specific notifications in your logic. .NET can pass a delegate to an unmanaged method expecting a function pointer, and this is an idiomatic way of handling GUI interactions without needing to know the GUI technology or platform ahead of time.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this