C# C++ Event question

[Guest]

Does anyone know if it is possible for an Event to be raised/fired in C++ and
then caught/handled in C# and vice versa in a .NET environment? If so, does
the C# and C++ code need to be in the same solution, different solutions,
different threads?

Thanks in advance,

Andrew S. Giles

 

[Thomas P. Skinner [MVP]]

Andrew,

A solution is just a collection of projects that may or may not be related.
Each project is a different application and results in a different assembly
(executable).

If the C++ and C# is managed code using the .NET FCL and they are in the
same project then you can use events regardless of the language.

The use of threads is independent of language or the use of events. Both C#
and C++ managed code can run in the same thread. The compilers translate the
source to MSIL (the intermediate language) and by that time the particular
source language that was used is irrelevant. Hope this helps.

Thomas P. Skinner [MVP]

 

[Guest]

Thomas,

Thanks for the insight. I have another question for you. If I am building
a solution, with multiple projects in it. If the C++ code is in one project,
and the C# in another, can events be thrown by one (in Project A) and caught
by another (in Project B)? Or do the events need to be contained within the
same project (yes, they are custom events). There is also some unmanaged C++
code that I will need to integrate in here as well, but I think I can
encapsulate that into a managed class.

Andrew

 

[Willy Denoyette [MVP]]

Assuming you are talking about native C++, the only way to source events
that can be sinked by C# is to use COM as interop layer.
If however you are talking about managed C++ (MC++, C++/CLI in v2) you can
use the same model (using delegates) as the solution was completely C#.
The way your solutions are laid-out is a non issue here.


Willy.

 

[Thomas P. Skinner [MVP]]

Think of projects as completely different applications. Events supported by
the FCL won't work across applications. There are lots of ways to
communicate between completely independent applications, but none are that
simple. COM is the most likely solution. Unfortunately I am not the person
to provide good advice as far as COM is concerned. Another way that might
apply is to open a TCP connection between the applications and have one
listen for an incoming event. You can do all that in managed code quite
easily. You can spawn a thread to listen on the appropriate port for a
message and then trigger an event.

Thomas P. Skinner [MVP]