Hallo HobbyCoder


hier findest du u.a. auch ein Beispiel "Fenster ohne VCL via sep. Thread steuern":

http://stackoverflow.com/questions/1...hout-using-vcl

Du siehst auf dieser Seite auch, wie du Buttons und Co - wie du es gern hättest - zur Laufzeit generierst.

(Ich hatte dir den Link via PM gesendet, du hast ihn wohl übersehen .)

Danke Michael. Hatte ich auch schon gesehen.
Ich werde das auch erst mal so stumpf umsetzen, damit ich die Anforderungen, die ich in meiner Anwendung habe, erst einmal am Laufen habe.

Da ich aber denke, dass ich sowas öfter mal gebrauchen könnte, werde ich mir daraus mal was basteln, was dann leicht wieder verwendbar ist. Wenn das soweit ist, dann werde ich das hier mal posten. Wird aber noch etwas dauern, weil ich leider nicht meine komplette Zeit dafür zur Verfügung stellen kann.

Hey

Da mich dieses Thema auch schon lange interessiert hat; man könnte sich bei solchen Wrapperklassen auch noch einen weiteren Vorteil sichern: Das Verwenden mehrerer Threads. Das Argument "Synchronisierung" kann man damit tatsächlich auch erschlagen. Windows bietet von Haus aus schon eine Messagequeue für die Nachrichtenbehandlung der Fensterereignisse an (klar, muss ja intern auch irgendwie funktionieren). Das MSDN schreibt dazu:

Zitat:

The function fails if the specified thread does not have a message queue. The system creates a thread's message queue when the thread makes its first call to one of the User or GDI functions. For more information, see the Remarks section.

Man könnte die PostThreadMessage Funktion also benutzen, um kustomisiert auf bestimmte Threadereignisse zu reagieren; oder sehe ich das falsch? Mir schwebt sowas wie ein "Callback" für die WndProc vor. Man registriert eine Callback Funktion auf einen Msg -Code, sodass man dann einfach jedes Mal, wenn man der GUI etwas mitteilen möchte, einfach PostThreadMessage aufruft (oder wenn man das an ein hwnd binden möchte, eben SendMessage /PostMessage ) und die Synchronisierung einfach über Windowsboardmittel durchführt. Wisst ihr was ich meine? Macht das für euch auch Sinn? Ich denke, dass man so zum Beispiel ein Log in einem Memo führen könnte, da die Messages ja immer hübsch einzeln "reinblubbern" - und das egal wie viele Threads im Hintergrund beteiligt sind.

Brighty

P.S. Habe gerade interessehalber diesen Artikel gelesen. Vielleicht interessiert er in diesem Kontext den ein oder anderen. (Falls jemand sprachliche Unterstützung möchte, kann ich btw. gerne übersetzend aktiv werden...)

Zitat von BrightAngel:

Macht das für euch auch Sinn?

Das ist in der Tat sogar eine sehr beliebte Synchronisierungsmethode. Kann man auch ohne Probleme verwenden, um aus einem TThread.Execute heraus Daten an das Hauptformular zu schicken ohne Synchronize zu verwenden.

Siehe auch meinen Beitrag #29 in diesem Thread dazu

Brighty

Zitat von BrightAngel:

Siehe auch meinen Beitrag #29 in diesem Thread dazu
Brighty

@Brighty: ups, sorry, habe dein Link übersehen, Da steht ja genau das drin, was jaenicke erklärt hat, habe ich mir gleich in Evernote gespeichert.

@jaenicke: Danke für den Tipp! Jetzt habe ich aber Gewissheit, dass ich vermutlich meine Berechnungen in einem 2. Thread reingeben soll.

Ich hätte aber im Falle von Peekmessage einfach die Nachrichtenschleife wie folgt gebaut und scheint auch zu funktionieren:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TDataThread.Execute;
var
  Msg: TMsg;
begin
  hdlg := CreateDialog(HInstance, MAKEINTRESOURCE(100), Self.Handle, @DlgFunc);
  ShowWindow(hdlg, SW_SHOW);

  while not terminated do
  begin
    BERECHNE_WAS; // <-------------- ich würde hier gerne was berechnen lassen
    if PeekMessage(msg, hdlg, 0, 0, PM_REMOVE) then
      begin
        TranslateMessage(Msg);
        DispatchMessage(Msg);
      end;
  end;
end;

Laut MS Doku in C ist aber gar kein TranslateMessage und DispatchMessage mehr drin.

markieren

Code:

fDone = FALSE;
while (!fDone)
{ 
    fDone = DoLengthyOperation(); // application-defined function
 
    // Remove any messages that may be in the queue. If the
    // queue contains any mouse or keyboard
    // messages, end the operation.
 
    while (PeekMessage(&msg, hwnd, 0, 0, PM_REMOVE))
    { 
        switch(msg.message)
        { 
            case WM_LBUTTONDOWN:
            case WM_RBUTTONDOWN:
            case WM_KEYDOWN:
                // 
                // Perform any required cleanup.
                // 
                fDone = TRUE;
        } 
    } 
}

Meine Frage wäre aber, wenn ich Peekmessage verwenden möchte, soll ich dann TranslateMessage u. DispatchMessage nicht verwenden, oder kann ich weiterhin TranslateMessage u. DispatchMessage verwenden, wie ich es in vorigen Delphicode gemacht habe?

lg,
jus

Hmm..

Wenn ich in Threads Windows-Messages verarbeiten lassen will, habe ich mir hierfür ein ProcessMessage nachgebaut:

zusammenfalten · markieren

Delphi-Quellcode:

type
  TThreadTerminateBreak = class (TThread);

procedure ThreatProcessRequests(AThread : TThread; WaitForMessage: Boolean);
var
  msg: TMsg;
  Rslt: Boolean;
begin
  while True do
  begin
    if TThreadTerminateBreak(AThread).Terminated and WaitForMessage then break;
    if WaitForMessage then
      Rslt := GetMessage(msg, 0, 0, 0)
    else
      Rslt := PeekMessage(msg, 0, 0, 0, PM_REMOVE);
    if not Rslt then break;
    DispatchMessage(msg);
    Sleep(1);
  end;
end;

Das TranslateMessage ist ja nur für die Konvertierung von Key-Events hilfreich, bei anderen Messages wird es jedoch nicht gebraucht.