Can the following Function be used "as is" as:
a MadRemote thread function, which will be copied to and then executed in the context of another process.
If not, please what will need to be changed?
Thanks!

No, that doesn't work. Using "string" ends up in calling all kinds of Delphi magic RTL functions, which are not available in the other process. TStrings methods are also not available in the other process.

You can use a different solution, though:

(1) LB_GETCOUNT and LB_GETTEXTLEN work directly without any fancy stuff, anyway.
(2) Allocate memory in the other process by using madRemote.AllocMemEx.
(3) Use SendMessage from your program, but give in the buffer you just allocated in (2).
(4) Use ReadProcessMemory to copy the content of the buffer to your own process.
(5) Use madRemote.FreeMemEx to free the memory in the other process again.

Still same old battle:
LB_GETCOUNT works fine.
But LB_GETTEXTLEN and WM_GETTEXT rquire that i be attached to that process somehow. As is, LB_GETTEXTLEN always returns a length of 4 (length of pointer).
So, as you say, i've got to change Tstrings and Strings to some thing else:
Will type RECORDS work, and pass stuff back and forth
one line at a time?
I am hoping to whittle it down to your
function GetCmdLineThread(buffer: pchar) : dword; stdcall;
example, one line at a time.
Thanks!...Vern

(1) You shouldn't use WM_GETTEXT on a list box. Use LB_GETTEXT instead.
(2) You can't use "RetBuffer := PChar(params)", because params is a pointer which is valid only in the other process. Instead use ReadProcessMemory to copy the content of params to RetBuffer.
(3) The following code is obviously wrong:

1 Ok, i was switching them back and forth, trying to get one or other to work. Will stick with LB.
2. Instead use ReadProcessMemory to copy the content of params to RetBuffer.
Aha, that's where ReadProcessMemory comes in.
3. Oops.
Thanks!

What i would like to do in your
function GetCmdLineThread(buffer: pchar) : dword; stdcall;
Is to add another parameter:

The code below runs, but ReadProcessMemory always returns #0(s) in RetBuffer.
LB_GETTEXTLEN always returns 4 in y , so i plugged 'len' with 260 to match RemoteBuff.
I believe LB_GETTEXTLEN must run in remote process; hWnd is OwnerDrawn ListBox,
which is why i have been leaning toward converting your 'RemoteCmdLine.dpr'.

Oh, then forget it. LB_GETTEXTLEN won't work in that case, regardless from which process you call it. "RemoteCmdLine" won't help, either.

The only thing which might work is hooking TextOutA/W and ExtTextOutA/W and then invalidating the listbox, hoping that it's not double buffered. For that purpose you must use madCodeHook and put all the hooking code into a hook dll. That's gonna be difficult.