Hi, I simular probem as previous thread.

I need help sovling this problem. The conditions are as follows:

1) On Process with an Edit control.
2) One process with a dll.

When process 2) LoadLibrary the dll, a handle to a GlobalAlloc is created and the handle of the edit control is retrieved.
Process 2) calls a dll function where a call ReadFile retrievs an ascii string. The string is copied to the allocated memory.

Still in the dll function



invoke SendMessage,hEdt1,EM_REPLACESEL,FALSE,pMemory


writes the string in the process 1) edit control. BUT if I change the message to



invoke SendMessage,hWin,WM_USER+100,0,pMemory


a WM_USER+100 is sent to process 1).



.elseif eax==WM_USER+100
invoke SetDlgItemText,hWin,IDC_EDT1,lParam


neither "addr lParam" nor "lParam", can write the sting in the edit control.

Thats my problem. I hope you understand what I mean.

BTW. PostMessage doesn't work either.
Posted on 2003-02-02 14:12:33 by minor28
Well tow possible things to try. Change
.elseif eax==WM_USER+100

invoke SetDlgItemText,hWin,IDC_EDT1,lParam

to
.elseif eax==WM_USER+100

invoke SendMessage,hEdt1,EM_REPLACESEL,FALSE,lParam

Another thing is to make sure the SetDlgItemText is reached. Looking at the code it seems like it should work so maybe there's something silly wrong such as the hWin or hEdt1 variables set wrongly.
Posted on 2003-02-02 14:22:52 by Eóin
You didn't say how and where your pMemory (transmitted as the lParam) is defined.

Is it a global variable available to your EDIT control?

Raymond
Posted on 2003-02-02 14:30:19 by Raymond
Hi E?in,

Doesn't work.

Hi Raymond,

I don't know if it is available to my EDIT control, perhaps not. The pMemory is defined in the dll .data? section as dd
Posted on 2003-02-02 15:07:25 by minor28
So, the dll allocates memory to store a string, and saves the pointer to that memory within its data section. You also state that the dll retrieves the handle of the Edit control and sends the message to it.

Whenever memory is allocated, it is generally a good practice to free it later on. I am "assuming" that the dll would perform that function. Could it be that it does it before returning control to your process? If not, when and how do you free that memory?

BTW did you write that dll or is it part of some other system?

Raymond
Posted on 2003-02-02 22:34:10 by Raymond
I have written the dll myself.

Every two second process 2) reads the file. Actually it is a comma separated string from the commport. Before each reading the dll do a RtlZeroMemory. The dll writes directly to the edit control all right. So long it works fine. However I want process 1) to parse the string before parts of it is sent to edit control. The problem accurres when the dll writes to the control indirectly via parent process 1). I haven't written the parsing code yet so now the whole string should be written.

The memory is freed when exiting the process.
Posted on 2003-02-03 00:56:20 by minor28
There is still at least one detail which is not too clear. Is the Process 1) using only a dialog box as its main window with the hWin as its handle?

Or is it a regular window with an appended Edit control window?

In either case, you may want to send the Edit control a message similar to the one sent by the dll which is known to work properly.

Raymond
Posted on 2003-02-03 10:25:43 by Raymond
Processes have separate memory spaces. You cannot use an address that comes from another process, it will not point to the expected data.

The message WM_COPYDATA will allow you to send data to another process.

How does EDIT do it?
This is what I suspect. In Win32, six predefined controls (EDIT, LISTBOX, etc.) have unique message numbers below WM_USER. The SendMessage/PostMessage dispatcher calls routines that know about these control messages and sends the WM_COPYDATA message (or uses some other method) to put a copy of the necessary strings in the memory of the receiving process.
Posted on 2003-02-03 12:50:12 by tenkey
tenkey, you were right. The pointer didn't point to the expected data only ??????????. The message WM_COPYDATA was the solution to the problem. Now it works.

Thank you E?in, Raymond and tenkey for taking your time to help me.
Posted on 2003-02-03 13:18:18 by minor28