Zitat:

Aber mal so nebenbei, was wolltets du mit einer TCP Verbindung auf Port 80 bei Mircosoft?

das war nur zum testen der threads gedacht, mir ist auf die
schnelle kein anderer server eingefallen

Ich würde Host und Port als Parameter an den Thread übergeben und nicht direkt auf Objekte des Hauptformulares innerhalb des Threads zugreifen.

zu welchen problemen kann es denn da kommen?

Du greifst zwar nur lesend auf die eigenschaft zu aber was passiert, wenn der Benutzer im Edit was ändert während der Thread gerade startet? Desweiteren, wenn du die Thread Unit in einem anderen Projekt brauchst, musst du den Code der Thread Unit anpassen. Und ich empfinde es einfach als unschön.

ich hab grad versucht das ein wenig deinen vorschlägen nach
abzuändern, dazu habe ich mir eine neue unit erzeugt und
dort ein paar methoden reingepackt die die requests generieren

(wobei ich anmerken muss das die methode Requests weitere Methoden
in dieser Unit3 nutzt die ich nicht alle in Unit2 auslagern möchte)

markieren

Code:

unit Unit3;

interface

uses
  Classes, SysUtils, Unit2;

type
 TPackets = class(TObject)
 public
    procedure Requests(Step: integer);
 end;

implementation

procedure TPackets.Requests(Step: integer);
begin
      case Step of
        0: Write('Hello');
        1: Write('Bye');
      end;
end;
end.

in der unit2 hab ich dann ergänzt:

markieren

Code:

...

type
  TMyThreads = class(TThread)
  private
    { Private-Deklarationen }
    FStep: Integer;
...

implementation

uses
  Unit1, Unit3;

...
  with IdTCPClient do
    begin
      ....
      try
        Requests(0); //hier wird gemeckert zuviele Parameter
        Requests(1); //und der aufruf in der form ist sicher auch falsch
...

procedure TMyThreads.Requests;
begin
  Packets.Requests(FStep); //hier wird gemeckert Undefinierter Bezeichner 'Packets'
  //wobei type TPackets = class(TObject) in Unit3 ja eigentlich gesetzt ist
  //und dann sind ess ihm natürlich auch noch zu viele Parameter
  //trotz des public procedure Requests(Step: integer); in unit3
end;

Ist natürlich wie erwartet vieles völlig falsch,
hat jemand vielleicht ne idee was ich besser machen könnte?

hm

Hi

Bitte poste deinen Delphi Code doch in den dafür vorgesehenen Delphi Tags: [Delphi] MeinCode [/Delphi]
Nun aber zu deinem Problem:

1. Mit

markieren

Delphi-Quellcode:

with IdTCPClient do
    begin
      ....
      try
        Requests(0); //hier wird gemeckert zuviele Parameter
        Requests(1); //und der aufruf in der form ist sicher auch falsch

rufst du die Methode "Requests" des Threads auf, nicht die in TPackets deklarierte Prozedur. Da TMythreads.Requests keinen Parameter hat, kommt der Fehler. Ich kann ausserdem nicht ganz nachvollziehen, warum du sie eingebaut hast

2. Dein Thread hat anscheinend keine Eigenschaft oder Variable die "Packets" heißt oder du hast sie nicht dazugeschrieben. Du musst erst im Constructor von TMyThreads eine Instanz von TPackets erzeugen, z.B. mit

zusammenfalten · markieren

Delphi-Quellcode:

type
  TMyThreads = class(TThread)
  private
    { Private-Deklarationen } 
    FStep: Integer;
    FPackets: TPackets;

...

constructor TMyThreads.Create(AOwner: TObject ....);
begin
...
 FPackets := TPackets.Create(Self);
...
end;

3. Der Aufruf von Write() in TPackets.Requests wird einen E/A Fehler hervorrufen, es sei denn dein Programm wird eine Konsolenanwendung. Wenn du die Write-Methode der IdTCP Komponente aufrufen möchtest, würde es sich eher anbieten, dies direkt den Thread machen zu lassen. Ich hoffe das war nicht zu vage formuliert, bin nicht besonders gut darin

Wie mein Onkel damals zu mir sagte: "Dein Versuch hat etwas von einem Metzgerslehrling, der sich gleich am Tag seiner Einstellung eine komplizierte Herzoperation vornimmt"

Gruß,
Dani

hallo,

danke für die hilfe, ich hab schon fast befürchtet
dass das wieder etwas komplizierter wird.

da TPackets eine ganze reihe von methoden enthält
um mit dem server kommunizieren zu können, möchte
ich diese wie schon gesagt in eine andere unit auslagern,
mit dem auslagern von write und ähnlichen anweisungn
hab ich gehofft relativ dynamisch auf ereignisse im thread
reagieren zu können, hälst du sowas in der form überhaupt
für sinnvoll?

Hm..keine Ahnung, ob das für dein Projekt sinnvoll ist, aber wegen 10 Methoden würde ich keine neue Klasse erstellen. Beispielsweise wäre das Ergebnis der folgenden beiden Aufrufe das Gleiche:

markieren

Delphi-Quellcode:

procedure TmyThreads.DoSomething;
begin
 {1} Packets.Request(1);
 {2} IdTCPClient.Write('Bye');
end;

Bei solchen Einzeilern halte ich Variante 2 für die Übersichtlichere. Welche Aufgabe haben die Threads eigentlich?

also die ganze geschichte ist schon weitaus umfangreicher
und war vorher ein php projekt das ich nun in delphi
umsetzen möchte, deswegen kämpf ich mich nun durch
die wirren der objektorientierten programmierung,
die besagten einzeiler sind nur zur veranschauung gedachte
und sollen das konkrete problem dastellen, seitenweise
code zu posten halte ich für unnötig