Pointer error with SendMessage() and LPARAM
-
Hi, We have a problem with corrupted addresses when sending a pointer in the LPARAM argument of ::SendMessage() to another application. Roughly, the code looks like this:
TCHAR g_szName[] = _T("abcd");
VOID SendName(HWND hWnd)
{
::SendMessage(hWnd, WM_USER, 0, (LPARAM)g_szName);
}In the debugger, we can have
g_szNameequal to for instance0x0e006719before the::SendMessage()call. But in the receiving application the higher bits are cleared so we only have0x00006719there, which isn't likely to contain the string we want to use... Any idea why this is? I can assure you it's annoying and it feels like I've done exactly this successfully at least a thousand times before, not to mentionWM_SETTEXT, which is practically the same, only it works... I appreciate any pointers ;) on this subject. Thanks! /Johann Gerell -
Hi, We have a problem with corrupted addresses when sending a pointer in the LPARAM argument of ::SendMessage() to another application. Roughly, the code looks like this:
TCHAR g_szName[] = _T("abcd");
VOID SendName(HWND hWnd)
{
::SendMessage(hWnd, WM_USER, 0, (LPARAM)g_szName);
}In the debugger, we can have
g_szNameequal to for instance0x0e006719before the::SendMessage()call. But in the receiving application the higher bits are cleared so we only have0x00006719there, which isn't likely to contain the string we want to use... Any idea why this is? I can assure you it's annoying and it feels like I've done exactly this successfully at least a thousand times before, not to mentionWM_SETTEXT, which is practically the same, only it works... I appreciate any pointers ;) on this subject. Thanks! /Johann GerellPointers do not generally marshall across process boundaries. You will need to allocate memory using the GlobalAlloc function in order to pass the data between your two applications. WM_SETTEXT has some special processing in it to marshall your pointers for you. I think the same goes with WM_GETTEXT and possibly a few other messages.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life! -
Hi, We have a problem with corrupted addresses when sending a pointer in the LPARAM argument of ::SendMessage() to another application. Roughly, the code looks like this:
TCHAR g_szName[] = _T("abcd");
VOID SendName(HWND hWnd)
{
::SendMessage(hWnd, WM_USER, 0, (LPARAM)g_szName);
}In the debugger, we can have
g_szNameequal to for instance0x0e006719before the::SendMessage()call. But in the receiving application the higher bits are cleared so we only have0x00006719there, which isn't likely to contain the string we want to use... Any idea why this is? I can assure you it's annoying and it feels like I've done exactly this successfully at least a thousand times before, not to mentionWM_SETTEXT, which is practically the same, only it works... I appreciate any pointers ;) on this subject. Thanks! /Johann GerellUse
WM_COPYDATAto send data between applications. /ravi Let's put "civil" back in "civilization" http://www.ravib.com ravib@ravib.com -
Pointers do not generally marshall across process boundaries. You will need to allocate memory using the GlobalAlloc function in order to pass the data between your two applications. WM_SETTEXT has some special processing in it to marshall your pointers for you. I think the same goes with WM_GETTEXT and possibly a few other messages.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!Paul Watt wrote: You will need to allocate memory using the GlobalAlloc function in order to pass the data between your two applications. I can't with pride use a function documented as being there to provide compatibility for 16 bits apps. And, are you really sure it does what it promises? Since Win32 doesn't have separate local and global heaps (only local, right?), how could that function allocate global heap? Pointers do not generally marshall across process boundaries. Yes, of course - I know that. Normally. But last night/morning at 5.30 AM, after long hours preparing for a first press demo of our product some hours later, neither me or my co-worker accepted this reason (happens way too often). I told him (with an enlightened smile) "...but each process has its own address space and pointers from one doesn't translate to the other." Upon which he (of course) replied "Of course." But did we accept that? No. At that hour without any sleep, things should just work... We already use WM_COPYDATA for IPC and that's the way to here also, but this morning I could have sworn there were no such thing as WM_COPYDATA... Thanks anyway! /Johann Gerell
-
Use
WM_COPYDATAto send data between applications. /ravi Let's put "civil" back in "civilization" http://www.ravib.com ravib@ravib.comDefinately. That's what we've been doing and should without question continue to do. Early morning hours can do much damage to ones brain. Thanks for the input! /Johann Gerell
-
Pointers do not generally marshall across process boundaries. You will need to allocate memory using the GlobalAlloc function in order to pass the data between your two applications. WM_SETTEXT has some special processing in it to marshall your pointers for you. I think the same goes with WM_GETTEXT and possibly a few other messages.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!Paul Watt wrote: You will need to allocate memory using the GlobalAlloc function in order to pass the data between your two applications. That is incorrect. The local/global distinction is a holdover from Win16. From MSDN:
Memory objects allocated by GlobalAlloc and LocalAlloc are in private, committed pages with read/write access that cannot be accessed by other processes. Memory allocated by using GlobalAlloc with GMEM_DDESHARE is not actually shared globally as it is in 16-bit Windows. This value has no effect and is available only for compatibility. Applications requiring shared memory for other purposes must use file-mapping objects.
I wish it were still as easy as calling GlobalAlloc. ;) --Mike-- Friday's GoogleFight results: Britney Spears 2,190,000 - Erica Weichers 23 :( 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click! My really out-of-date homepage Sonork-100.19012 Acid_Helm
-
Hi, We have a problem with corrupted addresses when sending a pointer in the LPARAM argument of ::SendMessage() to another application. Roughly, the code looks like this:
TCHAR g_szName[] = _T("abcd");
VOID SendName(HWND hWnd)
{
::SendMessage(hWnd, WM_USER, 0, (LPARAM)g_szName);
}In the debugger, we can have
g_szNameequal to for instance0x0e006719before the::SendMessage()call. But in the receiving application the higher bits are cleared so we only have0x00006719there, which isn't likely to contain the string we want to use... Any idea why this is? I can assure you it's annoying and it feels like I've done exactly this successfully at least a thousand times before, not to mentionWM_SETTEXT, which is practically the same, only it works... I appreciate any pointers ;) on this subject. Thanks! /Johann Gerell -
Paul Watt wrote: You will need to allocate memory using the GlobalAlloc function in order to pass the data between your two applications. I can't with pride use a function documented as being there to provide compatibility for 16 bits apps. And, are you really sure it does what it promises? Since Win32 doesn't have separate local and global heaps (only local, right?), how could that function allocate global heap? Pointers do not generally marshall across process boundaries. Yes, of course - I know that. Normally. But last night/morning at 5.30 AM, after long hours preparing for a first press demo of our product some hours later, neither me or my co-worker accepted this reason (happens way too often). I told him (with an enlightened smile) "...but each process has its own address space and pointers from one doesn't translate to the other." Upon which he (of course) replied "Of course." But did we accept that? No. At that hour without any sleep, things should just work... We already use WM_COPYDATA for IPC and that's the way to here also, but this morning I could have sworn there were no such thing as WM_COPYDATA... Thanks anyway! /Johann Gerell
-
Definately. That's what we've been doing and should without question continue to do. Early morning hours can do much damage to ones brain. Thanks for the input! /Johann Gerell
Johann Gerell wrote: Early morning hours can do much damage to ones brain. :) I couldn't agree more. Happens to me at least 5 times a day! /ravi Let's put "civil" back in "civilization" http://www.ravib.com ravib@ravib.com