Trivialproblem beim Öffnen eines TClientSocket

[Nimral]

Hi allseits,

hin und wieder könnte man an Delphi/WIndows verzweifeln. Wenn immer es eine Möglichkeit gibt, dass triviale Dinge schief gehen, tun sie es auch.

Mein abgespeckter Code heute steckt in einem simplen VCL Form, das einen TClientSocket beherbergt, und einen Button. Patscht man auf den Button, wird folgender Code angeschmissen:

Code:

procedure TClientMainForm.onReloadButtonClick(Sender: TObject);

begin
  Try
    if not ClientSocket.Active then // Socket öffnen
      begin
      ClientSocket.Port := StrToInt(ReadProgramConfig('CLIENTPORT'));
      ClientSocket.Host := ReadProgramConfig('SERVER');
      ClientSocket.Active := true;
      end;
    // Text senden
    ClientSocket.Socket.SendText('###')
  Except
    on e: Exception do
      ShowMessage(e.ClassName + ' ' + e.Message);
  End;
end;

ClientPort und Server liefern eine Port Nummer und eine IP ADresse, auf der anderen Seite lauert eine TServerPort Komponente. Simpel genug, denke ich. Was passiert: drücke ich den Button, wird der Port auf dem Server geöffnet, aber die drei '#' verschwinden im Nirvana. Die Exception triggert nicht. Drücke ich den Button nochmal (und auch jedes weitere Mal) kommen die drei '#' durch. Nehme ich die Abfrage auf .active raus, kommen die drei '#' nie durch, es wird lediglich serverseitig jedes Mal der Socket neu geöffnet.

Schätze konkret: in dem Durchlauf, in dem die Routine den Port öffnet, geht der darauffolgende SendText ins Nichts. Muss sie den Port nicht öffnen, weil ich schon mal auf den Button gedrückt hatte, klappt es.

Die nahgeliegende Frage: was mache ich falsch?

Gruss aus Bayern,

Armin.

[Uwe Raabe]

Steht das

Delphi-Quellcode:

ClientType

-Property des

Delphi-Quellcode:

TClientSocket

auf

Delphi-Quellcode:

ctBlocking

?

[Nimral]

Zitat:

Zitat von Uwe Raabe (Beitrag 1305621)

Steht das

Delphi-Quellcode:

ClientType

-Property des

Delphi-Quellcode:

TClientSocket

auf

Delphi-Quellcode:

ctBlocking

?

Hi Uwe,

Code:

  object ClientSocket: TClientSocket
    Active = False
    ClientType = ctNonBlocking
    Port = 0
    OnConnect = ClientSocketConnect
    OnDisconnect = ClientSocketDisconnect
    OnRead = ClientSocketRead
    OnError = ClientSocketError
    Left = 768
    Top = 312
  end

Also nonblocking. Sollte ich mal blocking probieren? Möchte den Port allerdings nonblocking fahren!

Fällt mir grad auf ... was auch noch fehlt ist der Code des OnConnect Handlers, vielleicht ist ja der der Bösewicht?

Code:

procedure TClientMainForm.ClientSocketConnect(Sender: TObject;
  Socket: TCustomWinSocket);
  begin
  DisplayMessage('Connect: ' + ConstructPrefix(Socket));
  end;

DisplayMessage schreibt einen Text in die Statuszeile des Forms, in der Form z.B. "Connect: 127.0.0.1:8888", zur Kontrolle. Sollte eigentlich nicht weh tun, oder?

Gruss Armin.

[Uwe Raabe]

Wenn du non-blocking arbeitest, dann ist der Port nach dem Active := true noch nicht offen. Deswegen verschwindet der nachfolgende Send-Befehl im Nirwana.

Bei non-blocking musst du halt mit dem Senden warten, bis der Port wirklich offen ist. Das geht am besten über den OnConnect-Event.

Alternativ kannst du auch zyklisch das Active abfragen, das bei non-blocking nämlich trotz des Setzen auf true erst später true zurückliefert.

[Nimral]

Zitat:

Zitat von Uwe Raabe (Beitrag 1305653)

Wenn du non-blocking arbeitest, dann ist der Port nach dem Active := true noch nicht offen. Deswegen verschwindet der nachfolgende Send-Befehl im Nirwana.

Bei non-blocking musst du halt mit dem Senden warten, bis der Port wirklich offen ist. Das geht am besten über den OnConnect-Event.

Alternativ kannst du auch zyklisch das Active abfragen, das bei non-blocking nämlich trotz des Setzen auf true erst später true zurückliefert.

Hi Uwe,

:-D:-DHabs noch nicht probiert, aber das klingt so schlüssig dass es sicher klappt. Herzlichen Dank!:-D:-D

Gruss Armin.