Ok, This is getting on my nerves. I have subclassed my main form to recieve windows messsages, so my helper application can send data to my form via sendmessage. It reconigises the correct message, but when im attempting to copymemory it, im just getting junk. Originally i figure it was because of the data being free'd before i attempted to copymemory it, then i read up on sendmessage and it doesnt return untill my application is done processing. Any ideas anyone?
In Helper App:
Call SendMessage(hlpApp, WM_HELPER, bufString(0).lenFileName / 2, VarPtr(FileName))
as you can see, wParam is the filename length and lparam is a pointer to the file name in memory
In main app:
Public Function WindowProc(ByVal hWnd As Long, _
ByVal uMsg As Long, _
ByVal wParam As Long, _
ByVal lParam As Long) As Long
Dim retval As Long
Dim tmpBuff() As Byte
Debug.Print uMsg
If uMsg = WM_HELPER Then
ReDim tmpBuff(wParam)
Call CopyMemory(VarPtr(tmpBuff(0)), VarPtr(lParam), wParam)
....
Any ideas? Thanks in advance.
Crouching Tiger, Drunken Kitty
Replace WM_HELPER with WM_COPYDATA in both apps. It will copy the memory into temporary memory that's in the context of the receiving application so that you can access it.
Edit: Sorry, use the COPYDATASTRUCT in the LPARAM of the message. That gives it the size and data to copy.
Still having the same problems. WM_COPYDATA just provides information that i can pass in the wparam and lparam. I suggest it has something to do with my byvals and byrefs varptrs ect. Not sure, the copy succedes, just returns random data, so im going to play around untill i get the results im looking for.
Originally Posted by Curiosity
Crouching Tiger, Drunken Kitty
Trust me, the memory manager won't allow one application the access another's memory, otherwise you could read password data, crash other programs, etc. It will give you a pointer inside your own heap that's all garbage instead. There's memory mapped files, but this is easier.
In C, to send the command line to a running instance of the same app I use this:
COPYDATASTRUCT cds;
cds.dwData = 0;
cds.cbData = lstrlen( lpszCmdLine ) + 1; // extra byte for the null
cds.lpData = lpszCmdLine;
SendMessage(hwnd, WM_COPYDATA, 0, (LPARAM)&cds);
Then getting the message looks like:
case WM_COPYDATA: or OnCopyData()
COPYDATASTRUCT *pcds = (COPYDATASTRUCT *)lParam;
char *pszCmdLine = (char *)pcds->lpData;
If you print the values for lParam and lpData, they will be different for both sender and reciever because the entire message packet is allocated in the reciever's heap then copied into it using the cbData member to determine the size.
blah wtf, ok ive got it almost working, now its giving me the first 3 chars, and the rest garbage, iunno wtf.
edit:
my code looks pretty much like that, (except for the pointers), if only it were that easy in vb. In my subclassed WindowProc event, it checks for WM_COPYDATA, and does teh following
but tmpbuff has the first 3 chars now, but the rest is garbage.Code:Call CopyMemory(cdsData, ByVal lParam, Len(cdsData)) MsgBox cdsData.dwData & " pointer: " & cdsData.lpData ReDim tmpBuff(cdsData.dwData) Call CopyMemory(tmpBuff(0), ByVal cdsData.lpData, cdsData.dwData)
Crouching Tiger, Drunken Kitty
Actually, thinking about it. If i place the data in wParam OR lParam i should be able to access it in my application because it should place it on the stack before the subsequent call
Crouching Tiger, Drunken Kitty
oh my god. That was the stupidest thing ive ever done. Never mind, i got it working, problem was im just a moron. =/
Crouching Tiger, Drunken Kitty
hehe. C and VB pointers are different.
heh thanks for your help. The reson it wasnt acting right is because i had cds.dwdata and cds.cbdata used backwards in both apps. So 1 app was passing it right, and the second app was reading it wrong.
Crouching Tiger, Drunken Kitty
Posting Permissions
LinkBack URL
About LinkBacks
Reply With Quote
Bookmarks