Bi-Directional Remoting with Unmanaged app

[victor]

Hello,
I'm facing the following difficulty with a Remoting app which
communicates with an Unmanaged (VC6) app in a two-way manner.
I have done the direction from Framework to VC6 through WIN32-API
delegates, using FindWindow + PostMessage. This works fine.

But now I have to go the other way back: from the VC6 app to the
Framework, also by using PostMessage. What I have in mind is: create a
second remoting path with the Server at the Framework machine and let
its client run on the VC6 machine. This second Client will then
communicate with the first Client via the RemotableObject and pass the
PostMessage data.

In order to receive these PostMessage events I have to install the
WIN32 WindowProc event handler in the Framework app, written in C#.
My problem is the following: how must I implement this WIN32
WindowProc(UINT msg, WPARAM wparam, LPARAM lparam) on my Framework
machine?

Anybody have a code snippet as example?

Thank you very much!
Victor.

[Peter Bromberg [C# MVP]]

Victor,
At first read, your description sounds incredibly complex, that you have to
do this a the OS Window level. Surely there has got to be an easier way
(perhaps, still using Remoting) to handle this inter-app communication
without going through all the coding pain you describe? Maybe more
information about the goal in mind and what exactly you need to be able to do
will elicit better suggestions.
--Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"victor" wrote:

Hello,
I'm facing the following difficulty with a Remoting app which
communicates with an Unmanaged (VC6) app in a two-way manner.
I have done the direction from Framework to VC6 through WIN32-API
delegates, using FindWindow + PostMessage. This works fine.

But now I have to go the other way back: from the VC6 app to the
Framework, also by using PostMessage. What I have in mind is: create a
second remoting path with the Server at the Framework machine and let
its client run on the VC6 machine. This second Client will then
communicate with the first Client via the RemotableObject and pass the
PostMessage data.

In order to receive these PostMessage events I have to install the
WIN32 WindowProc event handler in the Framework app, written in C#.
My problem is the following: how must I implement this WIN32
WindowProc(UINT msg, WPARAM wparam, LPARAM lparam) on my Framework
machine?

Anybody have a code snippet as example?

Thank you very much!
Victor.

[victor]

Peter, thanks for the response!
I'll try to outline my difficulty:
I have to establish a communication (two-way) between a C# remoting
app on one desktop and an unmanaged app, VC6-MFC, running on another
desktop.
The scheme choice of Remoting is fixed, due to the fact that it's part
of a larger project. The fact that 'the other' object is VC6/MFC is
also unalterable due to the same reason on that machine.
So, I'm a bit 'stuck' with this new-old or managed-unmanaged
situation. At least, for the part that the Unmanaged VC6/MFC module
has to signal something to the Managed-C# application.
As I mentioned, the other direction, from Mgd to Unmgd, I've solved
(via FindWindow + PostMessage). But now the other way around .... .
The problem is that I do not know how to implement the WIN32
WindowProc(UINT msg, WPARAM wparam, LPARAM lparam) in my C# module.
Logically it should be like instantiating an ordinary EventHandler,
but ..., I keep stumbling onto a brick wall up to now.
So, I hope you can help me out.

greetz, Victor

On Fri, 28 Jul 2006 16:53:02 -0700, Peter Bromberg [C# MVP]
<pb*******@yahoo.nospammin.comwrote:

>Victor,
At first read, your description sounds incredibly complex, that you have to
do this a the OS Window level. Surely there has got to be an easier way
(perhaps, still using Remoting) to handle this inter-app communication
without going through all the coding pain you describe? Maybe more
information about the goal in mind and what exactly you need to be able to do
will elicit better suggestions.
--Peter