ClientSocket bekommt keine Verbindung

[UliBru]

Ich hab nun

Delphi-Quellcode:

Client.ClientType := ctBlocking

getestet und damit klappt es auch. Das was der ursächliche Grund.
Da sich mit TClientSocket ein kleineres Programm ergibt als mit TIdTCPClient verwende ich nun doch wieder das TClientSocket.

Das Programm sieht nun so aus:

Delphi-Quellcode:

  Client := TClientSocket.Create(nil);
  try
    Client.Host := '127.0.0.1';
    Client.Port := 8078;
    Client.ClientType := ctBlocking;
    try
      Client.Open;
      Client.Socket.SendText(AnsiString(s));
      Client.Close;
    except
      on E: Exception do; //ignore, do nothing
    end;
  finally
    Client.Free;
  end;

[Morphie]

Ähm, warum nutzt du nicht einfach das Event OnConnect dafür?
Depending on the service, this may be the point when the socket should start reading or writing over the connection.

[Aphton]

Eine kleine Bemerkung, die du unbedingt durchlesen solltest, falls du bei den Nativen Komponenten bleibst (TClientsocket/TServersocket).
Es kann sein, dass es diese Problem bei Indy nicht gibt, da Indy das selbst auch intern macht - kenn mich mit Indies ned so aus.

[UliBru]

Zitat:

Zitat von Morphie (Beitrag 1197957)

Ähm, warum nutzt du nicht einfach das Event OnConnect dafür?
Depending on the service, this may be the point when the socket should start reading or writing over the connection.

Ähm, gute Idee. Werde ich gern auch mal testen.
Es scheint mir als ob man nur durch Trial & Error lernt. Die Beschreibung einer Komponente mit den jeweiligen Methoden und Eigenschaften besagt ja nicht direkt etwas darüber, WIE man das nun richtig einsetzt. Und dann studiert man ja auch nicht jede Methode bis ins Letzte. Also schaut man nach Beispielen. Und bei den Beispielen hier im Forum, oder http://www.delphi-treff.de/tutorials...programmierung als auch z.B. about.com und woanders habe ich es so vorgefunden, wie ich es denn realisiert habe. Wobei das

Delphi-Quellcode:

ctBlocking

in keinem der Beispiele vorkam. Oder, dass man die Abfrage auf aktiv nicht braucht, weil Exception. Das OnConnect ist auch nicht aufgetaucht, bis eben auf Deinen Hinweis.

[Zacherl]

Zitat:

Zitat von mjustin (Beitrag 1197942)

Man kann das if IdTCPClient1.Connected then ... weglassen, denn wenn der Verbindungsaufbau mit IdTCPClient1.Connected scheitert, wird eine Exception ausgelöst. Die Zeile mit der Abfrage auf Connected würde also nie erreicht.

Sicherheitshalber würde ich das Free in einem finally Block platzieren.

Dies gillt ebenfalls für die normale TClientSocket Komponente. Open() löst eine Exception aus, fals die Verbindung fehlschlägt.

Zitat:

Zitat von Morphie (Beitrag 1197957)

Ähm, warum nutzt du nicht einfach das Event OnConnect dafür?

Ich bin mir ziemlich sicher, dass dieses Event nur für die non blocking Variante funktioniert und bei dieser benötigt man wieder zwingend eine Message Queue (und ein Window?).

Zitat:

Zitat von Aphton (Beitrag 1197970)

Eine kleine Bemerkung, die du unbedingt durchlesen solltest, falls du bei den Nativen Komponenten bleibst (TClientsocket/TServersocket).
Es kann sein, dass es diese Problem bei Indy nicht gibt, da Indy das selbst auch intern macht - kenn mich mit Indies ned so aus.

Pakettrennung muss sowohl bei Indy, als auch bei den normalen Socket Komponenten per Hand implementiert werden.