Object mit SendMessage an MainThread senden

[himitsu]

Zitat von stoxx:

müsste eigenlich sein: (ohne @)

Integer(LogMsg) Weil ein Object ist schon selbst ein Pointer.
Ein TObject auf Integer zu casten hat eigentlich immer funktioniert.

Nja, man kann einen Pointer einem Objekt zuweisen ... Delphi interpretiert das dann sozusagen als TObject, welches intern ja ebenfalls ein Pointer ist.

Aber wie ich vorher shcon sagte:
Wenn man die globale Variable referenziert (@) und darauf den Zeiger überbergibt, dann muß am Ziel auch dieser Zeiger erstmal dereferenziert (^) werden,
und wenn man direkt den Objektzeiger übergibt, dann muß nur gecastet werden.



Und da Pointer was Böses sind, sollte man Diese möglicht vermeiden und schon gibt es keine Probleme mehr.

[Mavarik]

Warum TLogMessage als Object?

Delphi-Quellcode:

type
  PLogMessage    = ^TLogMessageMSG;
  TLogMessageMSG = record
                     sLogText : String[255];
                     bIsDebug : boolean;
                   end;
var
  LogMsg: PLogMessage;
const
   PM_MsgFromThread = WM_USER +4;

procedure TComThread.SendMsgToMain(LogText: string; Debug: Boolean);
begin
  New(LogMsg);
  LogMsg^.sLogText:=LogText;
  LogMsg^.bIsDebug:=Debug;
  SendMessage(frm_Main.Handle, PM_MsgFromThread,0,LParam(LogMsg));
end;

Empfangen im Hauptthread:

Delphi-Quellcode:

procedure Tfrm_main.LogMsgFromThread(var msg: TMessage);
var
  P: PLogMessage;
  fdebug: Boolean;
  fLogText: string;
begin
 try
   P := PLogMessage(MSG.LParam);
   fdebug:=P.bIsDebug;
   fLogText:=P.sLogText;
 finally
   Dispose(P);
 end;
end;

Mavarik

[himitsu]

Ob Object oder Record-Pointer, ist fast egal. (der kleiner Overhead des Objects fällt hier praktisch garnicht auf)

Aber wenn schon globale Variable, warum dann einen Record-Pointer?
Der Record direkt als Variable und keiner muß den mehr freigeben und auch vorher nicht erstellen.

PS: Wenn es die globale Variable gibt, dann fällt eigentlich sofort auf, daß man sich hier den Parameter sparen kann, da man auch gleich auf die Variable zugreifen kann.
Und schon fällt noch besser auf, warum diese Variable besser vernichtet gehört.

[Medium]

Eine Liste mit durch Critical Sections gesichertem Zugriff ist imho fast die einzige vernünftige Art Daten unter verschiedenen Threads auszutauschen. Dem Formular dann nur noch per PostMessage() parameterlos mitteilen, dass es da neues drin gibt, und dieses arbeitet immer schon Index 0 ab und löscht aus der Liste bis sie leer ist. FiFo-Style.

Am Rande: SendMessage() ist in Threads, wenn ich mich nicht grad irre, eigentlich sogar ein ziemliches NoGo, da alles was die Empfänger dann tun auf ein Mal im Thread-Kontext statt findet. Und das kann je nach dem auch schon mal so richtig böse knallen, da es OS Ressourcen gibt, die nur im erstellenden Kontext verwendet werden dürfen. Davon ab pausiert der Thread bis alle Handler von den Empfängern fertig sind, und das ist ja nun auch nicht ganz der Sinn von Parallelisierung.

[Captnemo]

So hab ich es jetzt letztlich im Moment auch gelöst. Im MainTread eine Tobjectlist, vom Thread innerhalb ein TCriticalSection Daten hinzu, und per postmessage benachrichtigen.

Aber ich will mir auch nochmal die TThread.Queue anschauen, denn das find auch ganz interessant.

[himitsu]

Nein, SendMessage/PostMessage ist in Threads kein Problem.

Beides trägt die Message in den MessageQueue des Threads ein, in welchem die Komponente erstellt wurde, an die die Message geht.
Verarbeitet wird die Message dann immer von der Messagebehandlung im zugehörigen Thread (meist der Hauptthread).


TThread.Queue ist wie Synchronize, außer daß die Prozedur nicht sofort verarbeitet wird. (von dem "Bug" abgesehn, wenn man was vom MainThread aus daran übergibt)

[stoxx]

Zitat von Medium:

Eine Liste mit durch Critical Sections gesichertem Zugriff ist imho fast die einzige vernünftige Art Daten unter verschiedenen Threads auszutauschen. Dem Formular dann nur noch per PostMessage() parameterlos mitteilen, dass es da neues drin gibt, und dieses arbeitet immer schon Index 0 ab und löscht aus der Liste bis sie leer ist. FiFo-Style.

kann man zustimmen

Zitat von Medium:

Davon ab pausiert der Thread bis alle Handler von den Empfängern fertig sind, und das ist ja nun auch nicht ganz der Sinn von Parallelisierung.

besser Postmessage, oder SendMessageTimeOut verwenden, da bei SendMessage bis zur Bestätigung der Verarbeitung gewartet wird, da hätte man dann auch gleich synchronize verwenden können, wo der Thread ebenso bis zum Ende der Verarbeitung angehalten wird.

Zitat von Medium:

Am Rande: SendMessage() ist in Threads, wenn ich mich nicht grad irre, eigentlich sogar ein ziemliches NoGo, da alles was die Empfänger dann tun auf ein Mal im Thread-Kontext statt findet. Und das kann je nach dem auch schon mal so richtig böse knallen, da es OS Ressourcen gibt, die nur im erstellenden Kontext verwendet werden dürfen.

nein, das stimmt nicht, das ist kein Problem.
PostMessage, SendMessage usw geht in de Queue vom jeweiligem Thread.
Überprüfen kannst Du, von welchem Thread die Funktion aufgerufen wird mit: GetCurrentThreadID

Wenn ein eigener Thread wirklich seine Nachrichten auch behandeln will, sofern er überhaupt welche bekommt, dann mit PeekMessage, TranslateMessage in der Execute Schleife von TThread.

[Medium]

Danke für die Aufklärung! War bisher zu faul das genauer zu testen. Das Problem was ich mal hatte wodurch ich dazu kam, war gelöst als ich noch eine ganze Menge mehr umgebaut habe. Das war dann also schon mal nicht der Suppenspucker.