Kerem,
As i said, a "possible" solution for him if he wants, it "could" be a
option for him. The Window Message implies local usage due
to the fact that you cannot send window messages to another
system the "standard" way without some sort of commuincation
protocol like TCP/IP TCP or UDP or something like that. This
should be clear here. I dont want to go too deep in IPC, you
know what i mean,...
I respect that, but it's a lot of code that someone has to write in
order to make this happen, when remoting and WCF are out of the box. The
only reason I would encourage something like this is if you were
communicating with a legacy application which could not be changed.
This shouldnt be a Problem, serializing some data to a byte array. In
native Windows you also have to cast something to VOID* or point
to some address and tell the function how long your data is, so this
is not that different compared to casting something using C or C++
or unmannaged .NET or whatever allows you casting like dynamic,
static or whatever casting,...
You have to be very careful here. In C++, if you had an instance of a
class which contained pointers to other sections of memory, and you just did
a cast to void, you would end up with invalid addresses in the process that
the class was copied to. You need some sort of serialization framework in
C++ to traverse all the members of the class and serialize them into a byte
array. Just casting to VOID* is a VERY bad idea.
With .NET, using serialization, it will traverse the object graph, and
serialize it all into a byte array. Of course, Remoting and WCF will do
this for you out of the box.
.
As i said, since it is a WM_COPYDATA it is restricted to local usage
and you can also read this in the link i provided with my answer to his
question. But on the other hand a console application can send a
Message with WM_COPYDATA to a Windowed Application, and a
Service can also (if interactive) communicate (form service to window)
with a Window (i think it should go because it the runs in the default
desktop, but i am not sure), at least with SendNotifyMessage(). The
Window also could communicate/respond to the service with a User Defined
SC Command even, this is a very "limited" communication.
Console apps can call SendMessage, but they can't receive messages back,
so if you had a console app that had to "listen", then WM_COPYDATA is a bad
idea (unless it creates a hidden window).
With services, it is even more restrictive, because the service would
have to be able to interact with the desktop in order to listen for windows
messages, which isn't a good idea either. I'm not sure if a service can
call SendMessage though without interacting with the local desktop.
My post was "just" a possible "option" for him,...
It's not that it's a bad idea, it just have some severe limitations
which need to be acknowledged.
