A reverse WM_COPYDATA ?

[R.Wieser]

Hello all,

I've written a small console-based program which uses WM_COPYDATA to
transfer blobs of data to another (GUI) app. The problem is that the
console-based app needs to be able to *retrieve* blobs of data too, which
WM_COPYDATA does not seem to allow for.

Question: Is there a WM_*** message which allows me to retrieve date in the
same way WM_COPYDATA transfers it ? (Or maybe a setting I'm not aware of)

Remark:
I really want to KISS this (keep it stupidly simple).

I've also taken a look at a number of other methods (shared memory, pipes,
mailslots, etc), but most all of them either do not scale well, or demand
the presence of a window to handle messages - which also takes away control
from the console app, and needs (hefty) synchronisation mechanisms to be in
place (at both sides).

[JJ]

Post by R.Wieser
Hello all,
I've written a small console-based program which uses WM_COPYDATA to
transfer blobs of data to another (GUI) app. The problem is that the
console-based app needs to be able to *retrieve* blobs of data too, which
WM_COPYDATA does not seem to allow for.

What do you mean? Console process can send/receive data from WM_COPYDATA.

Post by R.Wieser
Question: Is there a WM_*** message which allows me to retrieve date in the
same way WM_COPYDATA transfers it ? (Or maybe a setting I'm not aware of)

IIRC, WM_COPYDATA uses shared memory to transfer the data to another
process.

Post by R.Wieser
I really want to KISS this (keep it stupidly simple).

Then you might want a third party IPC SDK to do all the dirty work.

Post by R.Wieser
I've also taken a look at a number of other methods (shared memory, pipes,
mailslots, etc), but most all of them either do not scale well, or demand
the presence of a window to handle messages - which also takes away control
from the console app, and needs (hefty) synchronisation mechanisms to be in
place (at both sides).

Why not just use a separate console thread to send/receive the data? So that
it won't block the console's main thread. And you can use a message-only
window instead of a normal (visual) window, in order to fullfill the window
handle (and message loop) requirement.

IMO, that's the simplest IPC. Otherwise, I'd use other methods depending on
the task requirements.

If you want a non-blocking IPC, you'll have to make your. e.g. shared memory
with polled event as IPC-data-presence indicator. But it'll only work if the
console's main thread isn't doing or waiting for something else.

[R.Wieser]

Hello JJ,

Post by JJ
What do you mean? Console process can send/receive data
from WM_COPYDATA.

In that case something must be going wrong somewhere, as I definitily do not
see, at the senders side, any change I make to the data at the receivers
side ...

I do however see the result of the SendMessage call reflect the "return
value" I provided at the receivers side.

... but maybe I'm not understanding you here. If you mean that a console
process can receive WM_COPYDATA messages, how ? (withouth runing a seperate
thread running a message(only)window I mean)

Regards,
Rudy Wieser

[JJ]

Post by R.Wieser
Hello JJ,

Post by JJ
What do you mean? Console process can send/receive data
from WM_COPYDATA.

In that case something must be going wrong somewhere, as I definitily do not
see, at the senders side, any change I make to the data at the receivers
side ...
I do however see the result of the SendMessage call reflect the "return
value" I provided at the receivers side.
.... but maybe I'm not understanding you here. If you mean that a console
process can receive WM_COPYDATA messages, how ? (withouth runing a seperate
thread running a message(only)window I mean)
Regards,
Rudy Wieser

WM_COPYDATA requires a window handle, a window message handler, and an idle
thread which is available for executing the message handler. Without any
(one) of those, WM_COPYDATA will not work.

[R.Wieser]

JJ,

Post by JJ
WM_COPYDATA requires a window handle,

As I described, my "server" end is a GUI program (exactly for the reason
you're mentioning). The "client" program however is a console program.

The *sending* of data (initiated-and-controlled by the console program) is
easy enough. Just a single WM_COPYMESSAGE is all it takes (no second
threads with (hidden) windows needed).

The *retrieving* (mind you, *not* "receiving") of data (again,
initiated-and-controlled by the console program) does not seem to be
possible. Whut ? Why ? How ?


Yes, I can create another thread with a (message-only?) window, so I can
*ask* the GUI program to give me some data (using a WM_APP+xxx message
perhaps), and than have the console-programs main thread wait for its second
thread to receive a WM_COPYMESSAGE send by the GUI program, and than copy it
from that second thread to it main one. Phew...

Remember that I said KISS ? The above is why. :-)

Post by JJ
Without any (one) of those, WM_COPYDATA will not work.

My question was *not* a "how do I do this ?" (broad) request-for-solution,
it was about trying to find out if I maybe somehow messed my code up or
simply missed a setting on the WM_COPYDATA message, as I imagined it to be a
single message allowing for both transmitting as well as retrieving data
(mind you, its name contains "copy" (directionless), not "transmit" (from A
to B only) ).

And maybe if the WM_COPYDATA had a(n equally badly named) counterpart that I
was not aware of ...

Regards,
Rudy Wieser

[JJ]

Post by R.Wieser
My question was *not* a "how do I do this ?" (broad) request-for-solution,
it was about trying to find out if I maybe somehow messed my code up or
simply missed a setting on the WM_COPYDATA message, as I imagined it to be a
single message allowing for both transmitting as well as retrieving data
(mind you, its name contains "copy" (directionless), not "transmit" (from A
to B only) ).
And maybe if the WM_COPYDATA had a(n equally badly named) counterpart that I
was not aware of ...

Ah, you meant that WM_COPYDATA is more like WM_SENDDATA, and you need
something like WM_RECEIVEDATA which "pulls" data from a destination to the
sender.

In that case, you can still use WM_COPYDATA. Except that the one who send it
is the destination process, after a request from the source process. i.e.

You could use a custom window message to request data from the source
process to the target process. If the data that defines what data should be
returned doesn't fit into both WParam and LParam arguments, use WM_COPYDATA
to send the request. The target process should accept/deny the request by
setting the window message's result value, so that the source process will
know that the data is underway or not. If the destination process accepts
the request, it would send WM_COPYDATA to the source process with the
requested data.

[R.Wieser]

JJ,

Post by JJ
Ah, you meant that WM_COPYDATA is more like WM_SENDDATA,
and you need something like WM_RECEIVEDATA which "pulls" data
from a destination to the sender.

Exactly.

Though at first I assumed that the receiver of such a WM_COPYDATA message
could just write whatever it wanted in the provided memory block (probably a
chunk of shared memory), and the sender would be able to read it after the
SendMessage returned.

Post by JJ
You could use a custom window message to request data from
the source process to the target process. [snip]

I know. But I really *really* wanted to KISS it. Something a
two-direction WM_COPYMESSAGE would have delivered. Which ment I first
needed to make sure if I didn't simply misunderstand its usage.


And as you might have seen from my other thread, I'm trying to implement
such a WM_RECEIVEDATA message myself (using anonymous (unnamed) shared
memory). I've got an implementation working. But I'm not yet satisfied
with its compexity (on both sides), nor with not knowing why some parts of
it refuse to work as expected (DuplicateHandle on a process pseudo handle
returning an, for my purposes, unusable result)...

Regards,
Rudy Wieser