Wie stelle ich sicher dass ich nichts von VCL verwende

[Viktorii]

Hallo.

Ich bin mir da bei einer Sache schon seit langem unsicher. Ich weiß, dass ich in einem Thread die VCL nicht verwenden darf. Ich weiß aber nicht genau was jetzt zur VCL gehört.

Wie es mir scheint ist in diesem Fall die Unit Forms := pfui.

Ist Forms die einzige Unit die zur VCL gehört? Wenn ich diese also nicht benutze bin ich auf der sichern Seite bzw.andere Units darf ich verwenden wie ExtCtrls, SysUtils?

[sirius]

Also wenn "Ctrls" drin vorkommt, sieht es auch böse aus.
VCL steht für VISUAL Component Library. Du musst dir nicht merken, welche Units verboten sind, sondern einfach nur, dass du im Thread keine Bildschirmausgaben generierst.

[Viktorii]

Hmmm... Verstehe dass noch nicht so ganz... dass das V für Visuall steht weiss ich ja :-D
aber wie ist es zB. mit Application.ProcessMessages? Hat ja nicht direkt was mit der Bildschirmausgabe zu tun. Aber in einem Thread sollte man das auch nicht verwenden, oder?
Und wie ist das zB. mit TTimer? Der kommt ja aus ExtCtrls, macht aber auch keine Bildschirmausgabe. Darf ich den nun verwenden oder nicht? usw.
Irgendwie blicke ich dass nicht was ich warum verwenden darf und was nicht :(
Deswegen dachte ich, wenn ich einfach die und die Units nicht verwende, dann ist alles okay. Ist aber natürlich auch blöd wenn ich Units nicht verwenden würde, die nur teilweise 'bösen' Inhalt haben. Dann könnte ich den 'guten' Inhalt dieser Unit ja auch nicht verwenden...
Wie Du siehtst: Ich bin verwirrt :?

[alzaimar]

Do sollst einfach nichts auf den Bildschirm malen, also Label, Buttons, Listboxen etc. in Threads verwenden.

Meiner Ansicht nach ist es ein Designfehler, wenn ich in einem Thread mit 'Application.ProcessMessages' arbeiten muss.

[hazard999]

Application.ProcessMessages sollte auf den Thread sowieso keine Auswirkung haben.

IMHO sollte der Thread eine eigene MessageLoop haben, ProcessMessages arbeitet nur die Loop des Mainthreads ab.

Delphi-Quellcode:

   
   PeekMessage(MsgRec, 0, 0, 0, PM_NOREMOVE);
   bWorking := false;
   if Terminated then
      bWorking := true;
   while not Terminated do
   begin
      if not bWorking then
      begin
         GetMessage(MsgRec, 0, 0, 0);
         while PeekMessage(MsgRec, 0, 0, 0, PM_REMOVE) do
         begin
            TranslateMessage(MsgRec);
            DispatchMessage(MsgRec);
         end;
      end
      else
         bWorking := false;
    end;

Dieser Code erstellt im Thread eine Message-Loop.
GetMessage wartet auf die nächste Nachricht.
Mit Translate und Dispatch den Inhalt der Loop lesen.

QED => Application.ProcessMessages bewirkt im Thread nix, ausser das du vielleicht eine fürchterliche Race-Condition heraufbeschwörst wenn im MainThread Application.ProcessMessages verwendet wird

[sirius]

GetMEssage und Peekmessage kurz hintereinander? Da gehen dir abher ein paar MEssages verloren.

[Viktorii]

Der Grund warum ich Application.ProcessMessages ist folgender: Ich habe eine DLL geschrieben, welche von anderen Programmieren benutzt werden soll. Die Funktionen sollen auch in einem Thread aufrufbar sein. Dazu habe ich hier schon mal gepostet.

Nun wird eine Funktion dazu verwendet einen DSP per USB zu pollen. Ist unschön, aber lässt sich durch den Anwendungsfall nicht ändern. Nun kann es sein, dass der DSP (aus welchen Gründen auch immer) rebootet. Das heißt er ist nach einigen Sekunden wieder da. Wenn dies passiert, muss ich in der Funktion solange warten (ich darf nicht vorher aus der Funktion zurückkehren) bis er wieder da ist. Dazu habe ich mir ein 'Notifyer Objekt' gemacht. Ich reagiere auf die entsprechenden WM, prüfe dann auf VendorID usw. Nun möchte den Notifyer alle 100 ms abfragen ob sich was getan hat. Ich habe also erst sleep(100) gemacht und dann nachgeschaut. Das funktioniert allerdins nicht. Sleep scheint wohl die ganze Anwendung komplett lahm legt und somit hat mein Notifyer die WM wohl nicht mitbekommen. Dann habe ich mir als Alternative zu sleep diese Lösung überlegt:

Delphi-Quellcode:

        Sleeper := 0;
        while Sleeper < 100 do
        begin
          Sleep(1);
          inc(Sleeper);
          Application.ProcessMessages;
        end;

So funktioniert es zwar, aber wenn die Funktion in einem Thread aufgerufen wird, wird somit ja auch Application.ProcessMessages in einem Thread aufgerufen. Kann ich denn irgendwie dafür sorgen dass die mein Notifyer mit einer anderen Lösung als der oben Genannten weiterarbeiten kann?

[Luckie]

Wieso brauchts du Application.ProcessMessages in einem Thread? Hast du mal in der Hilfe nachgeguckt, was diese Methode überhaupt macht? Sie sorgt dafür, dass dein Fenster die Nachrichtenschlange abarbeitet und so noch auf eingaben reagiert. Da ein Thread aber sowieso von deinem Hauptthread mit dem Fenster entkoppelt ist, ist der Aufruf von Application.ProcessMessages unsinnig.

[Viktorii]

Ja, ich habe da schon mal nachgelesen:

Da der Notifyer nicht mehr funktioniert hat, bin ich davon ausgegangen dass die WM noch in der Nachrichtenschlange hängt und nicht abgearbeitet wird. Deswegen dache ich, ich kann das so umgehen:

Zitat:

Unterbricht die Ausführung einer Anwendung, so dass die Botschaftswarteschlange verarbeitet werden kann.

Beschreibung
Durch einen Aufruf von ProcessMessages ermöglichen Sie der Anwendung, die Botschaften in der Warteschlange abzuarbeiten. ProcessMessages durchläuft die Windows-Botschaftswarteschlange so lange, bis diese leer ist, und gibt die Steuerung dann wieder an die Anwendung zurück.

Dass sich das jetzt nur auf Eingaben bezieht, wird für mich aus der Hilfe nicht ersichtlich :?

Bezieht sich dass nicht auch auf WM?

[Luckie]

Alle Windowsnachrichten, die mit WM_... anfangen sind Fensternachrichten, das heißt, sie werden an Fenster gesendet. Hat dein Thread ein Fenster und eine Nachrichtenschleife?