Windows messages between a console application and unmanaged DLL

  • Thread starter Thread starter Chris
  • Start date Start date
C

Chris

Hi,

Currently, I have a console application written in C# and an unmanaged
legacy DLL written in VC++ 6.0. In the DLL's previous application, when an
event occurs in the DLL, a windows message would be sent to the host GUI
application via PostMessage to WM_USER + X. The GUI application would then
execute a function to retrieve data from the DLL.

With this new setup, I have a console application as the host. I retrieved
the handle for the console application using System.Runtime.InteropServices
and sent it to the DLL. When an event occurs, a windows message should be
sent to the console application from the DLL thus executing a function to
retrieve data from the DLL. Is this old method possible in .net or is there
a new and better way to do it? I haven't been able to figure it out. What
do I need to implement to receive the windows message in the console
application? Also, eventually, the console application will be converted to
a windows service. Will the windows message capture work in there as well?

Thanks for your time and insight,

Chris
 
Chris,

I think that using WM_USER + X is a bad idea. If anything, you should
name it by calling RegisterWindowMessage and then use the message code
returned from that.

This method is not possible because it is a console application.
Consoles don't have message loops.

The service could use the message loop, but I don't really know if it is
a good idea. You would probably have to select "allow service to interact
with desktop" and then on top of that, you would have to run a message pump
in the OnStart method (which would never return, since it is in the OnStart
method), and I don't know if that is a good idea.

I would find another way of getting information into your service. I
would use remoting, or something like that instead of a windows message.

Hope this helps.
 
Hi Nicholas,

I figured it would be a bad idea ...

Is it possible to do remoting from a C++ DLL? Also, what other alternatives
might there be?

Thanks


Nicholas Paldino said:
Chris,

I think that using WM_USER + X is a bad idea. If anything, you should
name it by calling RegisterWindowMessage and then use the message code
returned from that.

This method is not possible because it is a console application.
Consoles don't have message loops.

The service could use the message loop, but I don't really know if it is
a good idea. You would probably have to select "allow service to interact
with desktop" and then on top of that, you would have to run a message pump
in the OnStart method (which would never return, since it is in the OnStart
method), and I don't know if that is a good idea.

I would find another way of getting information into your service. I
would use remoting, or something like that instead of a windows message.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Chris said:
Hi,

Currently, I have a console application written in C# and an unmanaged
legacy DLL written in VC++ 6.0. In the DLL's previous application, when an
event occurs in the DLL, a windows message would be sent to the host GUI
application via PostMessage to WM_USER + X. The GUI application would then
execute a function to retrieve data from the DLL.

With this new setup, I have a console application as the host. I retrieved
the handle for the console application using System.Runtime.InteropServices
and sent it to the DLL. When an event occurs, a windows message should be
sent to the console application from the DLL thus executing a function to
retrieve data from the DLL. Is this old method possible in .net or is there
a new and better way to do it? I haven't been able to figure it out. What
do I need to implement to receive the windows message in the console
application? Also, eventually, the console application will be
Click to expand...
converted
to
a windows service. Will the windows message capture work in there as well?

Thanks for your time and insight,

Chris
Click to expand...
Click to expand...
 
Back
Top