Hi,

Using the latest 0.9.29 revision of Lazarus, I found another regression bug (works in 0.9.28.2). The documentation hint over methods are blank. See attached screenshot.

Lazarus 0.9.29 r24818 FPC 2.4.1 x86_64-linux-gtk 2 (beta)

I dont know if many of you guys who use win32 are aware of a bug / limitation of sendmessage in windows , when you are trying to send a message to another application , when the message gets there both lparam and wparam are invalid ( or pointing to rubish ) ( i also got the same issue on SimpleIPC on win32 to the same result when you try to send data with the message - as it uses sendmessage to do the low level work - i think !! )

with in the same application it seems to work , but when you use more than one application together or one application sending a message to a prev instance of the application ( ie you run it for the second time , the second copy is sending a message to the first copy ).

the best work around i've found is to use a NamedPipe which i know is win32 only ( not sure about other os's ) , i basically created a "ServerPipe" and a "ClientPipe" and use this pipe to send info from the second application back to my main application to get around the sendmessage issue.

I know alot of you guys are not using win32 but other variants of linux but for the people who are using win32 this maybe of interest if you have got issues with SendMessage on win32.

My Os is Win7 RTM on one pc and Win7 Retail on the other - both ultimate 64 bit. & i am using pritty much the lastest SVN

i also suspect this method may help anyone using a DLL who needs to pass objects back and forth ( i think havent tested but i think it should be feasable.. )

if any one is interest in the code for this issue feel free to ask , i''m happy to share it.

A big thanks to Paul Ishenin , for all your help , your hardwork has help me in getting the last bit of my application over from delphi 2010 to Lazarus x64.

Cheers

Justin Smyth

AKA

Delphian

Hello Lazarus-List,

Thursday, April 22, 2010, 2:43:04 PM, you wrote:

JS> I dont know if many of you guys who use win32 are aware of a bug / JS> limitation of sendmessage in windows , when you are trying to send a message JS> to another application , when the message gets there both lparam and wparam JS> are invalid ( or pointing to rubish ) ( i also got the same issue on

You can not send data to other applications using pointers and sendmessage because they are in a different process so memory is not shared, so it is not a but nor limitation is a "by design" to allow process isolation. Windows have a special message to send data to other processes, but the amount of data is limited and it must be copied (I think it is transparent) to a shared memory.

JS> the best work around i've found is to use a NamedPipe which i know is win32 JS> only ( not sure about other os's ) , i basically created a "ServerPipe" and JS> a "ClientPipe" and use this pipe to send info from the second application JS> back to my main application to get around the sendmessage issue. JS> I know alot of you guys are not using win32 but other variants of linux but JS> for the people who are using win32 this maybe of interest if you have got JS> issues with SendMessage on win32.

A Pipe is designed just to to such things and they are more or less like sequential files and they share a lot of semantics. Other difference is thay pipes are not usually written to any media.

JS> My Os is Win7 RTM on one pc and Win7 Retail on the other - both ultimate 64 JS> bit. & i am using pritty much the lastest SVN
JS> i also suspect this method may help anyone using a DLL who needs to pass JS> objects back and forth ( i think havent tested but i think it should be JS> feasable.. )

A DLL shares the same process so you can use SendMessage or more simple a direct call to an exported procedure. A different beast is that the DLL has its own memory manager and its own RTL which is a problem to some LCL operations.

----- Original Message -----

I've attached my pipe i use

on the server i do

  fPipeCreated:=false;
  try
    fMplayerPipe := TPipeServer.CreatePipeServer('','MPLAYER64',true);
  except
    on E: Exception do
    begin
      ShowMessage(E.Message);
    end;
    else
    begin
      fMplayerPipe.Destroy;
      Result := false;
      exit;
    end;
  end;
  fMplayerPipe.PipeMesgage:=fEventHandle;

fEventHandle is where my pipe does sendmessage to .

on the client side

      MplayerClientPipe:=TPipeClient.Create('','MPLAYER64');
      MplayerClientPipe.SendString(<your data>);
      MplayerClientPipe.free;

the pipe itself converts the data you send in to a message using sendmessage

Justin Smyth wrote

I know alot of you guys are not using win32 but other variants of linux but for the people who are using win32 this maybe of interest if you have got issues with SendMessage on win32.

Could you show the example that doesn't work?

thanks,
dmitry

Hello Lazarus-List,

Thursday, April 22, 2010, 3:21:01 PM, you wrote:

JS> if this is the case then delphi itself is doing something weird if i can JS> send data from one application to another using Sendmessage ( the message JS> being WM_COPYDATA )
JS> the same cant be said for lazarus/fpc

Well, WM_COPYDATA is the only way to do it in windows, but LCL SendMessage is not Windows SendMessage. Lazarus LCL SendMessage is designed to work with Lazarus LCL, as it must be cross platform. If you need WM_COPYDATA then:

uses ..., Windows;

Windows.SendMessage(.....)

As only in Windows you can "SendMessage" to other process. In resume, LCL SendMessage is to the LCL application (current only) and Windows SendMessage is only for Windows systems.

but LCL

SendMessage is not Windows SendMessage. Lazarus LCL SendMessage is designed to work with Lazarus LCL, as it must be cross platform.

I do know that as well with Delphi as with Lazarus/Windows and with Lazarus/GTK PostMessage is documented, designed and working equal: send a set of three 32 (64) bit values to the main thread of the process the application the thread calling PostMessage is a part of (while the Target-"Handle" needs to be taken from the (main) form's handle property). The received message is propagated via "Dispatch" in the forms "Dispatch" procedure.

But I am astonished to find that SendMessage in fact leads to some code in the gtk interface unit. SendMessage in Windows in fact is documented to send a "Message" (three 32 (64) bit values" to a different process. Same does not need to be done in Lazarus (or Delphi). So this is nothing more than an encapsulation of a Windows OS API. I don't see how this (sending such a Message to a process that is not done in Lazarus) could be implemented in Linux in a useful way. Of course using a pipe or something like that could make this happen for two processes done with Lazarus, but AFAIK, there currently is no implementation for this.

So what does SendMessage do in GTK and what is the difference between PostMessage and SendMessage ? (AFAIK, in Delphi and Lazarus-Windows there is none (but performance), if the target handle is associated to the same process.) The documentation and the wiki does not seem to provide this information.

-Michael

Hello Lazarus-List,

Thursday, April 22, 2010, 5:41:37 PM, you wrote:

MS> So what does SendMessage do in GTK and what is the difference between MS> PostMessage and SendMessage ? (AFAIK, in Delphi and Lazarus-Windows MS> there is none (but performance), if the target handle is associated to MS> the same process.) The documentation and the wiki does not seem to MS> provide this information.

As far as I know (and I could be wrong) LCL SendMessage only handles (passes) messages that it could understand and WM_COPYDATA is not one of them, while Delphi SendMessage is just exactly the same as Windows.SendMessage.

So, LCL.SendMessage is a compatibility layer that transform the windows message style in an operation over the current widgetset. In GTK a message like WM_SHOW will be "converted" in a sequence of GTK operations to show or hide a window/control. This way inside an application there is (or better should not be) any difference to the application running in Windows, GTK, etc...

Of course maybe is reasonable to allow plain SendMessage (LCL.SendMessage) to send a plain (whichever) message when the target is not an LCL handle :-? in Windows platform, but them a lot of posts like WM_COPYDATA works in Windows but fails in Linux will fill the bugtracker.

I don't see why, in Windows, anybody should use SendMessage to send a message top a window that is assigned to the same process. AFAIK, this is what PostMessage (as well the VCL/LCL function as the Windows API call) is provided for.

Of course maybe is reasonable to allow plain SendMessage (LCL.SendMessage) to send a plain (whichever) message when the target is not an LCL handle :-? in Windows platform,

I don't see why. in Delphi VCL, Lazarus Windows LCL and any program done with the Windows API in mind you would use PostMessage here. And thus for compatibility reasons, PostMessage is provided in a platform independent way by the LCL and decently implemented e.g. with the GTK2 interface (aka "Widget Type") (the NOGUI Widget Type just provides a dummy (as expected), I did not investigate the other Widget types, but I believe they do provide4 appropriate implementations.)

but them a lot of posts like WM_COPYDATA works in Windows but fails in Linux will fill the bugtracker.

Of course as these are either implementation-depending features of the Widget set or (in the case of WM_COPYDATA) are unrelated to a "Widget Set" at all and use OS-Depending implementation details. But this does not explain, why "SendMessage" is provided as an
architecture-independently defined but not at all
architecture-independently implemented LCL it not appropriate to use PostMessage (or something completely unrelated) instead of SendMessage in any platform independent code in the LCL (and with that drop the misleading platform-independent definition) ?

-Michael

I now found that SendMessage provides a Result, while PostMessage only returns a success flag. So they are less similar than I thought (and the Windows API definition is still more cryptic :( )

-Michael

AFAIK: In Windows

PostMessage puts a message in the queue and returns immediately.

SendMessage puts the message in the queue and returns with a result after the message has been handled.

But I might be wrong...

John

On Fri, 23 Apr 2010 11:09:35 +0200, Michael Schnell wrote about Re: [Lazarus] SendMessage Bug Work Around.:

[snip]

I don't see why, in Windows, anybody should use SendMessage to send a message top a window that is assigned to the same process. AFAIK, this is what PostMessage (as well the VCL/LCL function as the Windows API call) is provided for.

The SendMessage() and PostMessage() API's have different semantics:

SendMessage() places a message on a message queue and waits for a
return code from the WndProc or DlgProc that processes the message;

PostMessage() places a message on a message queue and returns to continue execution, without waiting for the message to be processed.

This distinction can be very important.

SendMessage on win64 bug is caused by TCopyDataStruct struct being wrong, i've just proven it with the help of dmitry boyarintsev - changing the first part of the data structure to a PtrUInt and it works. it was a dword.

for me i just use my own stuct but i suggest we get a TCopyDataStruct64 added in. this would solve the issue.

From: David W Noon [mailto:]
Sent: 23 April 2010 12:20

this

return code from the WndProc or DlgProc that processes the message;

PostMessage() places a message on a message queue and returns to

continue execution, without waiting for the message to be processed.

This distinction can be very important.

Yep - PostMessage is asynchronous communication, SendMessage is synchronous. A useful analogy would be Post as UDP, Send as TCP. AFAIR, WM_COPYDATA is the only message that can ONLY use SendMessage, since the pointer is only guaranteed valid during the transaction (well, initiator dependant, of course!)

DSP

You might be right.

Yet, I only played with SendMessage to do communication between two or more Delphi applications in Windows. Here the receiving functionality is "procedure ... message" and I did not find a documentation that states that the sending process (better: thread) is supposed to be blocked in SendMessage until the receiving process finished it's message procedure. It should be easy to try this by doing a sleep in the message procedure, but the result might be invalid, as the receiver's RTL could first acknowledge the message to the System (whatever that means) and only call the pascal code afterwards.

-Michael

David W Noon wrote

SendMessage() places a message on a message queue and waits for a return code from the WndProc or DlgProc that processes the message;

That is clear to me after I found that SendMessage returns a value taken from the receiving entity. But this seems quite obscure if the receiver (in Windows) is another process.

PostMessage() places a message on a message queue and returns to continue execution, without waiting for the message to be processed.

That is clear, of course.

This distinction can be very important.

Obviously :).

-Michael

From: Michael Schnell [mailto:]
Sent: 23 April 2010 14:16

more Delphi applications in Windows. Here the receiving

functionality is "procedure ... message" and I did not find a

documentation that states that the sending process (better: thread) is

supposed to be blocked in SendMessage until the receiving process

finished it's message procedure.

It should be easy to try this by doing a sleep in the message

procedure, but the result might be invalid, as the receiver's RTL could first >acknowledge the message to the System (whatever that means) and only call the pascal code afterwards.

-Michael

<Paper Vendor> 'Read all about it!'
http://msdn.microsoft.com/en-us/library/ms644950(VS.85).aspx </Paper Vendor> :-)

Some years ago I had to re-organise my handling of some SendMessage/WM_COPYDATA interactions, since the receiving application would launch a modal dialog which blocked the sending app until the whole process was done. The user would be confused as to why they couldn't refer back to the original app until they had completed the new input dialog that had been launched.

I worked around it by copying the relevant data on receiving the message, and instantiating a 1ms timer to call the correct procedure; the receiving process could then return quickly, and the sending app was no longer blocked. The timer fired the correct dialogs, and the user was none-the-wiser as to the underlying spaghetti that had happened. It was a little hacky, but worked well :-)

DSP

As Lazarus does not provide any help on these RTL functions but the call parameters, the only available documentation seems to be by Microsoft and same is not overridden by the RTL/LCL developers:

I have no idea how (in Windows OS) the "window procedure for the specified window" behaves, if it's a window of a different process and same is a Delphi program that uses "procedure ... message".

AFAIR, WM_COPYDATA is the only message that can ONLY use SendMessage, since the pointer is only guaranteed valid during the transaction (well, initiator dependant, of course!)

In Windows, it makes no sense to send messages like EM_LINEFROMCHAR with PostMessage, as they are used to request a result from the receiver that comes as the SendMessage function value, while PostMessage does not have a function value other than true or false.

Do you suggest that the memory array the pointer defines and the pointer itself automatically is managed to be valid for the receiver ?

-Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100423/a7d86bba/attachment-0001.html>

From: Michael Schnell [mailto:]
Sent: 23 April 2010 14:39

AFAIR, WM_COPYDATA is the only message that can ONLY use

SendMessage,

since the pointer is only guaranteed valid during the

transaction (well,

initiator dependant, of course!) In Windows, it makes no sense to send messages like EM_LINEFROMCHAR

with PostMessage, as they are used to request a result from the

receiver that comes as the SendMessage function value, while

PostMessage does not have a function value other than true or false.

Do you suggest that the memory array the pointer defines and the

pointer itself automatically is managed to be valid for the receiver ?

-Michael

I can only speak from how I've used it.. Windows does 'something' with WM_COPYDATA such that the memory is shared between both processes, whether they be in the same application space or not.

I have used things like [NB away from a dev environment, so OTOH]
PCopyData = TCopyData;
TCopyData = record
  s: string;
end;
Sender:
PCD = new(PCopyData);
PCD^.s := 'Hello';
i := SendMessage(OtherApplicationFormHandle, WM_COPYDATA, PCD,0);
Label.caption := intotostr(i);
Receiver:
PCD := WParam;
Label.Caption := PCD^.s;
result := 5;

Note in http://msdn.microsoft.com/en-us/library/ms644950(VS.85).aspx where it says 'The sending thread is blocked until the receiving thread processes the message. However, the sending thread will process incoming nonqueued messages while waiting for its message to be processed.'

It's exciting stuff! I've found it very useful through the years.

Duncan Parsons wrote

Windows does 'something' with WM_COPYDATA such that the memory is shared between both processes, whether they be in the same application space or not.

Interesting stuff !

Thanks,
-Michael

I did read this, but in fact I can't understand the meaning. If the thread stops in "Send Message", it obviously is not in a "waitForMessage" function. At what code would it start running if a message to be processed arrives ?

-Michael

From: Michael Schnell [mailto:]
Sent: 26 April 2010 10:00

.On 04/23/2010 05:37 PM, Duncan Parsons wrote:
.> Note in http://msdn.microsoft.com/en-us/library/ms644950(VS.85).aspx .> where it says 'The sending thread is blocked until the receiving .> thread processes the message. However, the sending thread will process
.> incoming nonqueued messages while waiting for its message to be processed.'
.>
.I did read this, but in fact I can't understand the meaning. If the thread stops in "Send Message", it obviously is not in a ."waitForMessage" function. At what code would it start running if a message to be processed arrives ?
.
.-Michael

Yeah, that second bit doesn't totally make sense to me either, but has some truth in it in practise..

Scenario I used it in - In a job management system, the user types a job/ticket number in one app (a dedicated viewer), but needs to make modifications; those modifications are done in the editor app. The viewer uses SendMessage with WM_COPYDATA which holds the job/ticket number, and the type of edit. Whilst processing the message, the editor opens a modal dialog to perform the edit.

If the user clicks back to the viewer whilst the modal dialog is open, they cannot interact with the app in any meaningful way - it will not repaint, it will not process mouseclicks in the client area, etc. However.. It /will/ perform minimise/restore operations - so those messages are clearly handled in a different manner to the others, windows is doing something clever with the queues.

As I posted before, I solved this problem by extracting the data during the message process, then instantiating a 1ms timer and returning. The viewer was responsive straight away, and the editor's modal dialog didn't interfere with anything else.

Don't know if that helps you!
Duncan

Hi!

I don't know how big your interest is in this topic, but you might take a look at the source code of ReactOS. There you can see what's happening inside a SendMessage.

To speed up your research I've looked a bit by myself:

SendMessage(W) is defined in dll\win32\user32\windows\message.c. After some preparing (and checking whether it the message can be send directly (same thread)) it finally calls NtUserSendMessage which is defined in subsystems\win32\win32k\ntuser\message.c.
There it jumps around a bit in internal function (co_IntDoSendMessage => co_IntSendMessage => co_IntSendMessageTimeout =>
co_IntSendMessageTimeoutSingle) to finally pass the message into the message queue using co_MsqSendMessage which is defined in subsystems\win32\win32k\ntuser\msgqueue.c.
If you look there you'll see a KeWaitForSingleObject or a KeWaitForMultipleObjects which basically waits for an event which is initialized in this function. This event might signal the completion of the message passing (I haven't studied the code in detail though, so the last assumption might be wrong).

Regards,
Sven

Sven Barth wrote

I don't know how big your interest is in this topic, but you might take a look at the source code of ReactOS. There you can see what's happening inside a SendMessage.

Thanks. I'll not do this :)

It's funny that the API documentation provided by Microsoft seemingly is not understandable to the software experts gathered here ;)

BTW.: I once tried to d/l, create and start a ReactOS life CD, but id would not boot on any of my PCs :( .

Any news about the state of ReactOS ?

-Michael

BTW.: I once tried to d/l, create and start a ReactOS life CD, but id would not boot on any of my PCs :( .

You can try ReactOS on Vmware player or VirtualBox. Will be Lazarus on ReactOS?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100428/d70732d6/attachment-0001.html>

Would it be safe to assume something like FastShareMem ( http://www.codexterity.com) could be used for DLLs to use the same memory manager in the app and the dll ?

Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100506/4a99c71d/attachment-0001.html>