views:

597

answers:

1

Here is my prototype:

    [DllImport("user32.dll", CharSet = CharSet.Auto)]
    public static extern bool PostMessage(int hhwnd, uint msg, IntPtr wparam, IntPtr lparam);

And here is how I'm using it:

PostMessage(HWND_BROADCAST, msg, Marshal.StringToHGlobalAuto("bob"), IntPtr.Zero);

In a different thread I can intercept this message, but when I try to get bob back using:

string str = Marshal.PtrToStringAuto(m.WParam); // where m = the Message object

I don't get bob in str.

I'm thinking this has got to be due to the fact that I referenced the "bob" string on one thread's stack and that reference has absolutely no meaning in a different thread's stack. But if that's the case, are these wparam and lparam pointers only really used for messages being passed in the same thread?

Edit* Correction: By thread I mean Process. This is a problem of passing a string between processes, not threads.

+1  A: 

HGLOBALs arn't, in any way, global anymore. Not since win16. And HWND_BROADCAST looks like you are sending the message to a different process, never mind just a different thread.

So, unless you either use one of the standard messages that the OS knows how to marshal, you need to place your string, "bob" in a shared memory area that different processes can access.

Chris Becke
Chris, do you know how to do either one of those? Is it as simple as using a different Marshal method?
Nick
see nobugz's answer for some examples of inter process methods.I don't really see what you are trying to do with this method, so its hard to give advice on what ipc mechanism would be best. If you are sending window messages for whatever reason, WM_COPYDATA would be convenient, but never broadcast as other apps might be handling it with their own expectations of the data received.
Chris Becke