TidTCPCLient erzeugt Stack-Overflow

[rokli]

Hallo Uwe,

den Application.Process habe ich eingebaut, um den Zähler sehen zu können; in einer Version vorher hatte ich alles in´s Memo protokolliert ... und das wurde zu lang, also hab ich nur den Zähler ausgegeben. Aber abgebrochen ist das Programm vorher auch.

@Sherlock: Den gibts leider nicht. Daher bin ich auf den Timer gekommen.

Es gibt einen Event

Delphi-Quellcode:

procedure TfrmMain.tcpClientWork(ASender: TObject; AWorkMode: TWorkMode;
  AWorkCount: Int64);
begin
   //
end;

Aber der hat bei mir nicht funktioniert (es gibt auch noch einen onStartWork und onEndWork). Heißt, ich habe keine Daten bekommen.

[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 ....