SendMessage wartet nicht

[Sunlight7]

Hallo zusammen!

Im MSDN steht:

Zitat:

The SendMessage function calls the window procedure for the specified window and does not return until the window procedure has processed the message.

Nun habe ich ein Problem damit, von einem Prozess aus wird SendMessage benutzt um zu einem anderen Prozess eine Nachricht zu schicken, dort wird ein Fenster per ShowModal angezeigt und das ModalResult als Result der Message zurück geschickt, dabei sollte der Thread mit SendMessage warten bis die Nachricht abgearbeitet wurde. Tut es aber nicht, SendMessage kehrt nach kurzer Zeit mit 0 als Result zurück. GetLastError meint dazu kein Fehler, also auch 0.

Pseudo Code:

Code:

Prozess 1:
Result:=SendMessage(RemoteWnd, WM_IPC_SHOWFORM, 0, 0);
// Hier gehts mit Result=0 kurz drauf weiter, obwohl Form2 noch nicht geschlossen wurde.


Prozess 2:
procedure TForm1.WndProc(var Message:TMessage);
begin
   Case Message.Msg of
      ...
      WM_IPC_SHOWFORM: begin
         Message.Result:=Form2.ShowModal;
         Exit; <- Hier gehts erst weiter sobald Form2 geschlossen wurde
      end;
   end;
   ...
end;

Warum wartet SendMessage nicht? Habs auch mit SendMessageTimeout versucht bei gleichem Ergebnis

[Zacherl]

Nimm mal INFINITE statt 0 für das Timeout, dann gehts auch Oder halt direkt SendMessage, wenn du das Timeout nicht benötigst.
Hatte den letzten Satz überlesen.

Verwendest du noch Win2000? MSDN sagt, dass GetLastError eigentlich ERROR_TIMEOUT enthalten sollte:

Zitat:

If the function fails or times out, the return value is 0. To get extended error information, call GetLastError. If GetLastError returns ERROR_TIMEOUT, then the function timed out.

Windows 2000: If GetLastError returns 0, then the function timed out.

[Der schöne Günther]

Dumme Idee: ShowModal() verursacht selber wieder das Senden und Abarbeiten von Messages. Ob der deine Message irgendwie runternimmt, damit nichts anfangen kann und wegwirft? Ich würde es mal nicht an TForm1 binden, sondern generell mit Application.RegisterWndProc(..) oder wie das hieß...

Mit dem "SendMessageTimeout" komme ich nicht klar: Die beiden Nullen sind eigentlich WPARAM und LPARAM. Kommt das "Timeout" nur von einem Test? Denn für "SendMessageTimeout" hat der Aufruf zu wenig Parameter...

[Zacherl]

Zitat von Der schöne Günther:

Dumme Idee: ShowModal() verursacht selber wieder das Senden und Abarbeiten von Messages. Ob der deine Message irgendwie runternimmt, damit nichts anfangen kann und wegwirft?

Au ja, das könnte auch sehr gut sein und würde auch erklären, warum GetLastError keinen Fehlercode zurückgibt. Dann allerdings wundert mich, dass SendMessageTimeout 0 liefert ..

[Neutral General]

Ist ja auch ganz logisch. ShowModal blockiert solange bis dasn Fenster geschlossen wird. Das hat nichts mit SendMessage zu tun.
Dementsprechend kommt er zu dem exit logischerweise auch erst wenn das Fenster geschlossen wurde. Das andere Programm kriegt wohl
vorzeitig eine 0 zurück (Timeout) weil es ansonsten solange hängen würde bis das Fenster wieder geschlossen wird.

Unterm Strich heißt das: ShowModal im WndProc ist keine gute Idee.

[Sunlight7]

Dann wäre aber die Beschreibung im MSDN falsch.
Auch ein SendMessageTimeOut mit ner Zeit gegeben von einer Stunde wartet nicht solange.

[Der schöne Günther]

Kontrollierst du bitte nochmal deinen Quellcode? SendMessageTimeout(..) hat nicht vier Parameter, sondern mehr.

[Sunlight7]

Zitat von Zacherl:

Verwendest du noch Win2000?

Windows 7

[Sunlight7]

Zitat von Der schöne Günther:

Kontrollierst du bitte nochmal deinen Quellcode? SendMessageTimeout(..) hat nicht vier Parameter, sondern mehr.

Das war nur ein Copy & Paste Fehler, sollte nur SendMessage sein

[Zacherl]

Ok nochmal von vorne Ein Result von 0 bei SendMessage deutet NICHT auf einen Fehler hin. Ein Result von 0 bei SendMessageTimeout aber definitiv schon. Ich gehe jetzt einfach mal von SendMessage aus.

Das Problem hat Günther schon korrekt erkannt:
ShowModal startet eine eigene Message-Verarbeitung und sorgt deshalb dafür, dass deine eigene Message vom Default Message-Handler abgearbeitet und aus der Queue entfernt wird. Das ist dann der Moment, in dem SendMessage aufhört zu blocken.