Problem in sending WM_COPYDATA message

[Peter S. Lee]

I am trying to make two applications comunicate with each other..

In one application (let's call it A), I use "FindWindow" function to get the
handle of the other application (B).

B application is the dialog based application with the window text "AAA."

In A:
HWND hWnd = FindWindow ("#32770", "AAA");
-> The resulting hWnd is not NULL.. so..

SendMessage (hWnd, WM_COPYDATA, (WPARAM)thisHwnd, (LPARAM)data);
-> Also, it works..

In B application, however, the handler of WM_COPYDATA that is OnCopyData
(..) is not called..

WHEN I changed SendMessage like following..
SendMessage (HWND_BROADCAST, WM_COPYDATA, ...);

the OnCopyData function is called..

I can't find anything wrong in my program..

Can anybody help me?

ANY helps or comments would be appriciated..

Peter S. Lee

[James Pannozzi]

There is a known bug using OnCopyData.
Use ON_MESSAGE
Using Broadcast is bad, see note below.
Jim

See following earlier post found from Deja.

ON_MESSAGE(WM_COPYDATA, OnCopyData)

LRESULT CMyWnd::OnCopyData( WPARAM wParam, LPARAM lParam )
{
CWnd* pWndSender = CWnd::FromHandle((HWND)wParam);
COPYDATASTRUCT* pcds = (COPYDATASTRUCT*) lParam;

/* Do your work here */

return TRUE; // handled
}

Note: WM_COPYDATA can be broadcasted over top-level windows,
it is a very bad idea to ignore the sender window because
you can analyze an unknown COPYDATASTRUCT. I do not understand
why the WM_COPYDATA can be broadcasted, it
would be IMHO strictly forbidden !

Submitted By: Stéphane Gibier (1999/07/02)

"Peter S. Lee" <pete...@xecurenexus.com> wrote in message
news:#3cFwBv$AHA.1048@tkmsftngp07...

[Sam Hobbs]

There might be something obvious that more experienced Windows developers
are aware of but if it were me I would use Spy++ to diagnose the problem if
I cannot diagnose it using something easier. And Spy++ is relatively easy to
use. I think I would put a TRACE after FindWindow to show hWnd in hex format
and I would use SPY++ to determine what the handle is for the dialog. If the
two do not agree then I would have something much more specific to diagnose.
The SendMessage with the correct handle should work and probably you are not
getting the correct handle for some reason.

"Peter S. Lee" <pete...@xecurenexus.com> wrote in message
news:#3cFwBv$AHA.1048@tkmsftngp07...

[Peter S. Lee]

Thanks..

But I also tried ON_MESSAGE..
It didnot work, either.. 8(

Peter.

"James Pannozzi" <jpan...@csi.com> wrote in message
news:OE#OJ9w$AHA.1448@tkmsftngp05...

> There is a known bug using OnCopyData.
> Use ON_MESSAGE
> Using Broadcast is bad, see note below.
> Jim
>
> See following earlier post found from Deja.
>
> ON_MESSAGE(WM_COPYDATA, OnCopyData)
>
> LRESULT CMyWnd::OnCopyData( WPARAM wParam, LPARAM lParam )
> {
> CWnd* pWndSender = CWnd::FromHandle((HWND)wParam);
> COPYDATASTRUCT* pcds = (COPYDATASTRUCT*) lParam;
>
> /* Do your work here */
>
> return TRUE; // handled
> }
>
> Note: WM_COPYDATA can be broadcasted over top-level windows,
> it is a very bad idea to ignore the sender window because
> you can analyze an unknown COPYDATASTRUCT. I do not
understand
> why the WM_COPYDATA can be broadcasted, it
> would be IMHO strictly forbidden !
>

> Submitted By: St?hane Gibier (1999/07/02)

[Peter S. Lee]

Thanks..

I see that the problem is disagreement of two hWnd values..
What can I diagnose further?

The hWnd value of FindWindow is not NULL..
Does this mean that it finds the correct window of "AAA" ?

I thought that if I wrote wrong window class name or window title as
arguments of FindWindow,
the hWnd value of FindWindow should be NULL..
Am I wrong?

Please, help me..

Peter.

"Sam Hobbs" <sam...@socal.rr.com> wrote in message
news:OY4BHWx$AHA.1312@tkmsftngp07...

[Sam Hobbs]

Are you sure that FindWindow returns a valid handle? You could use Spy++ to
validate the handle. Validate that the window caption and class matches what
you expect.

I wonder if it is possible you are calling CWnd::FindWindow, which returns
CWnd*, instead of ::FindWindow, which returns HWND. I have not heard of that
happening so I suppose it would not. If, however, you are using a cast for
the return value from FindWindow because the compile complains without it,
then you must take a real close look at that.

Otherwise it seems that the only other possibility is that you have more
than one window with the same class and window name. You could write
something to check that out but hopefully you can use Spy++ to check that
out.

"Peter S. Lee" <pete...@xecurenexus.com> wrote in message

news:ej$t7l2$AHA.1432@tkmsftngp03...

[Joseph M. Newcomer]

Did you put the ON_MESSAGE handler in the right window? You need to
make sure that the window you think you are putting the handler in is
the actual window that is the top-level window. You can do this by
using Spy++ to identify the target window and its handle, and see if
that value is the value you get back from FindWindow. In addition, you
can then have Spy++ trace the messages to see if the window is
receiving it. This may help pin down why the message appears to not be
intercepted.

I have been nailed several times by people who seem to have made the
same HWND_BROADCAST discovery. If you send WM_COPYDATA this way, then
EVERY window will receive it, including those which are expecting
WM_COPYDATA from "friends". What I do in my WM_COPYDATA handling is to
put a 128-bit GUID as the first 16 bytes of the message. When I
receive the message, I check that the GUID that appears in the first
16 bytes is the GUID my "friends" have agreed to put there; if I don't
see that GUID there, I ignore the message. This is critical, because
if you run in an environment where someone has done the HWND_BROADCAST
trick, you are dead meat.

Also, I find the use of "FindWindow" to be risky. When I have two
cooperating processes, I put a registered-window-message handler in
the target. I then do SendMessageTimeout of a Registered Window
Message (using a 200ms delay). The receiver responds to this message
by returning the same Registered Window Message value (it turns out
you can't rely on an unknown message returning 0, which is the defined
behavior of DefWindowProc, because Microsoft violates their own
specification and has some daemon components for Personal Web Server
that return 1 for every message, even messages they don't understand.
Stupid and irresponsible, but that's what it does. Microsoft
explicitly states in one of their design documents that (a) if you
don't understand a message, pass it to DefWindowProc and (b)
DefWindowProc will always return 0 for any message it doesn't
recognize). I find my method to be reliable, because it can be easily
internationalized. Depending on the contents of the window caption, or
the window class name, is far more risky (I once searched by window
class name, and got a window from a completely different application
that used the same window class name).
joe

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www3.pgh.net/~newcomer
MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm