Ok, danke!

Ich glaube ich habs begriffen... Wenn ich noch was wissen muss, kann ich euch dann auch im Zweifelsfall per PN anschreiben?

nein! Denn per PN hast nur die etwas davon und andere mit dem gleichen Problem bleiben im Regen stehen. Bei Fragen die im Forum gestellt werden haben alle etwas davon und genau davon lebt ein Forum auch, vom gegenseitigen Helfen

Ups, so war das auch nicht gemeint...

Den entgültigen Lösungsweg hätte ich dann schon gepostet.

Hallo,

wenn der Thread zum Auslesen da sein soll, würde ich folgendes Prinzip verfolgen (als Denkanstoß)

• Thread liest Daten aus der Schnittstelle in einen "eigenen" Puffer und informiert die Anwendung per Message (selbstdefinieren als Information darüber, dass in dem Puffer neue Daten da sind und an welcher Stelle sie stehen (Puffergröße ausrechnen z.B. auf mind. eine Sekunde Zwischenspeicher)
• Thread-Klasse selber hat z.B. eine Funktion Abbruch oder Stopp. Intern wird hierbei TEvent verwendet -> Grund siehe unten
• In der Execute-Methode machst du ein WaitForMultipleObject und "wartest" dort sowohl auf die Schnittstelle (Kann man direkt darauf warten) bzw. auf das TEvent-Object) und entscheidest dann entsprechend Dein verhalten (lesen oder eben abbrechen).

Vorteile:

• Entkopplung des Lese/ Wartezyklus von der Applikation -> die Applikation kann sich also um "ihre" arbeit kümmern
• Daten werden (nochmals) gepuffert für die Anwendung und der Thread wird nicht von der "Verarbeitung" der Daten durch die Applikation aufgehalten (Datenverlust)
• Nicht so Performancelastig, da der Thread wegen WaitForObject nicht so viel Zeit des Prozessors verbraucht wie eine Endlosschleife in einer Applikation

Nachteil:

• Höhere Aufwand der Programmierung
• Einarbeiten in das Thema Threads und deren Eigenarten (FreeOnTerminate/Syncronized ...)
• Erzwungene Trennung und dadurch entstehender Overhead

Viel erfolg dabei

Gruß, Chris

So, es hat funktioniert...

Hier ist mal der Code:

zusammenfalten · markieren

Delphi-Quellcode:

TMyThread = class(TThread)
  protected
    procedure Execute; override;
    procedure Display;
end;

var
 MyThread : TMyThread;

procedure TMyThread.Display;
begin
  // hier Ausgaben eintragen, Memos, Edits, usw.
end;

procedure TMyThread.Execute;
begin
  while not terminated do
    begin
      // hier Anweisungen (bei mir halt Daten von Steuerung lesen)
      Synchronize(Display);
      sleep(xx); // hier schläft der Thread, bevor er weiterläuft
    end;
end;

procedure TForm2.Button1Click(Sender: TObject);
begin
  MyThread := TMyThread.Create(false);
  MyThread.FreeOnTerminate := true;
end;

Nochmals danke euch allen!!!

@ChrisE:

Auf die Schnittstelle warten funktioniert bei der Anwendung nicht so richtig, daher habe ich den Weg gewählt, dass die Daten entsprechend dem Intervall angefodert und ausgelesen werden. Um den Puffer werde ich mich jetzt kümmern...

Ist auch das erste Mal, dass ich einen Thread benutze, muss mich da jetzt sowieso noch tiefer einarbeiten.

Warum ist ThreadGo kein Attribut der Thread-Klasse?

Stimmt eigentlich... werd ich gleich ändern...

Statt des ThreadGo nimmt man Terminated. Das ist eine Property des Thread-Objektes.
"while not Terminated do"

Jetzt hab ich mich so gefreut das es läuft...

also, dann mit WHILE NOT TERMINATED DO

Danke

Hallo,
ich glaube du schiesst mit Kanonen auf Spatzen.

Der Weg über polling und genau das machst du mit einem zyklisch gestarteten thread ist doch völlig überflüssig.
Wir machen sowas Eventgesteuert über die Routine Ontriggeravailable der Portkomponente.(serielle Schnittstelle Asynch pro)
Das heisst die Routine wird jedesmal (oder auch erst nach bestimmten Vorraussetzungen) durchlaufen, wenn ein Zeichen über die serielle Schnittstelle eintrifft.
Geschickt programmiert ist das viel effektiver als der Weg über threads.

Grüsse