TidTCPCLient erzeugt Stack-Overflow

[Bowler]

Müsste das nicht ehr ein TCP-Server sein? So wie ich das sehe schickst Du ja vom Client keinen Befehl an den Scanner, um dann das Ergebnis abzufragen, sondern der Scanner schickt was, wenn er was hat.
Dann könntest Du mit dem OnExecute des TCP-Servers darauf reagieren und schauen was geliefert wird. Ich glaube das ist auch das Event was Sherlock meint.
Der TCP-Server macht ja einen Thread auf und steht dann blockierend auf dem Socket und wartet, bis was ankommt. Wenn was kommt, wird es verarbeitet. Das ganze passiert dann in einer Schleife.

Ich habe leider gerade kein Delphi hier, um genau zu schauen, wie die Events heißen, aber das kam mir gerade in den Sinn, als ich Deinen Beitrag gelesen habe.

Oder verstehe ich das falsch. Das setzt natürlich voraus, dass der Scanner sich zu Deinem Programm verbindet, und was schickt. Dein Programm läuft als Server in einem Loop und reagiert nur.

[rokli]

Guten Morgen!

Leider musste ich gestern weg und konnte nicht mehr antworten.

Also es verhält sich so, dass der Barcode Scanner ein TCPServer ist. Und dieser Server sendet das, was er als Barcode gelesen hat. Damit (so habe ich es interpretiert) habe ich auf "meiner" Seite einen TCPClient genommen ... was ja auch in den ersten 15 bis 20 Minuten funktioniert.

Im Moment läuft der Aufbau übrigens wieder ohne den Application.ProcessMessages.

[rokli]

So sieht der Fehler aus, den ich da bekomme.

[Sherlock]

Kannst Du eigentlich isolieren, in welcher Zeile der Fehler auftritt? Hast Du sowas wie MadExcept oder EurekaLog?

Ausserdem sellt ein Server in einer normalen Welt Daten bereit, die ein Client abholen kann, so er denn lustig ist. Also müsste es eigentlich so sein, daß in mehr oder weniger Regelmäßigen Abständen Dein client eine Verbindung aufbaut, und mal nachsieht, obs was neues zu holen gibt. Dein Konstrukt sieht mir nicht so ganz danach aus. Aber dazu kenne ich die Indys zu schlecht.

Sherlock

[rokli]

Hallo Sherlock,

genauso soll es sein! Innerhalb des Timers wird in der Zeile strLine = tcpClient.IOHandler.ReadLn ermittelt, ob der Server etwas bereit gestellt hat. Wenn das der Fall ist, soll der Wert in strLine im if-Konstrukt weiter verarbeitet. Wenn der Server keine Daten bereit gestellt hat, läuft der Timer einfach weiter.

Im Moment Trenne ich die Verbindung vor dem If und Verbinde nach dem If wieder - das werde ich mal in die Schleife verlegen, sodass nur getrennt wird, wenn die Variable gefüllt ist.

Die beiden Tools habe ich leider nicht.

[TiGü]

Zitat von rokli:

Die beiden Tools habe ich leider nicht.

http://madshi.net/madExceptDescription.htm -> zum ausprobieren kann man es kostenlos runter laden!

[rokli]

Vielen Dank TiGü, hatte mich aber schon für EurekaLog entschieden - muß ich nur noch installieren.

Das Ändern des Disconect / Connect in die if Sequenz hat nichts gebracht ... nun werde ich versuchen, ob EurekaLog was heraus bringt!

.. und ich muss dringend was essen ....

[Sir Rufo]

Probiere er einmal das hier aus:

Delphi-Quellcode:

procedure TForm1.timScanTimer( Sender: TObject );
begin
  timScan.Enabled := false; // Timer anhalten
  try
    // nix im Buffer, dann brauche ich auch nicht fragen ...
    if tcpClient.IOHandler.InputBufferIsEmpty
    then
      Exit; // tschüss bis später

    tag := 5;
    Inc( intLine ); // Durchläufe zählen
    Label1.Caption := IntToStr( intLine ); // Durchläufe anzeigen
    // Application.ProcessMessages;

    tcpClient.IOHandler.CheckForDisconnect( ); // ist die Verbindung noch da?
    strLine := tcpClient.IOHandler.ReadLn; // Inhalt nach Zwischenvariable

    tcpClient.Disconnect; // Client abschalten
    try
      if strLine <> ''
      then
        begin // ein Barcode wurde erkannt
          memLog.Lines.Add( TimeToStr( now( ) ) + strLine ); // Barcode in Memo schreiben
          strLine := ''; // Zwischenvariable leeren
        end;
    finally
      tcpClient.Connect; // und Client wieder anschalten
    end;
  finally
    timScan.Enabled := true; // Timer wieder starten
  end;
end;