Hi,

ich habe ein kleines Problem... Und zwar habe ich eine TCLientSocket komponente und habe diese auf ctNonBlocking gesetzt... Seit ich dieses getan habe werden meine Texte erst abgesendet wenn z.B. mein OnClick-Event des auslösenden Buttons vorüber ist... Früher sendete er den Text sofort wenn ich

gemacht habe... Weiß jemand was es mit dem ctBlocking und ctNonBlocking auf sich hat die Hilfe gibt nicht wirklich was her

MFG N3tw124rd

Hallo,

das Ganze verhält sich so: Im NonBlocking-Mode wird der Sendevorgang quasi wie ein Mausklick behandelt, er muß sich quasi anstellen und warten bis er senden darf. Im Blocking-Mode geht es sofort los, wobei der Sendevorgang aber in einem extra-Thread abläuft damit wenn es mal länger dauert nicht alles so lange steht.

Entschuldigt, wenn ich das hier nochmal ausgrabe, aber die Einstellung hat Folgen, die ich nicht verstehe.

Und zwar kann mein Client nichts mehr empfangen, wenn er auf ctBlocking eingestellt ist. Ich weiß nicht, ob das Ereignis OnRead ausgelöst wird oder ob er schlicht nicht vom Socket lesen kann.

Auf jeden Fall wäre es für mich wichtig zu wissen, da ich in einer anderen Client-Anwendung (eine kommerzielle Software, in der man Delphi-Code ergänzen kann) auf jeden Fall den ctBlocking brauche. Wäre schade, wenn man dort keine Daten empfangen könnte.

Danke für Eure Hilfe

Viele Grüße

IIRC brauchte man bei ctBlocking auf jeden Fall einen Thread zur Verarbeitung von Fenster-Nachrichten, da die Winsock-API Nachrichten-Orientiert arbeitet. Wenn das Lesen also nicht im Hauptthread geschieht, sollte das eigentlich so funzen.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Ich habe noch nie was mit Threads am Hut gehabt und weiß auch ehrlich gesagt nicht, was das ist. Ich glaube, in dem Fall sollte ich es wohl doch ohne ctBlocking versuchen.

Mein eigentliches Problem ist, dass ich in dieser Software einen Client habe und der sich öffnen und Daten absenden soll. Wenn ich nicht auf ctBlocking schalte, scheint er die Befehle gar nicht chronologisch abzuarbeiten oder zu warten, bis einer abgearbeitet ist (z.B. Open).

Man kann auch auf processmessages ausweichen. Wenn ich jedoch solange processmessages ausführe, bis der Socket geöffnet ist (repeat processmessages; until CliSo.Active;), dann kriegt er eine Endlosschleife, wenn der Server gar nicht da ist. Darum gibt es folgende Möglichkeiten:

1. Man fragt ab, ob der Server da und geöffnet ist (keine Ahnung wie das geht)

2. Ich finde irgendwann heraus, wie ich in diesem Pascal-Programm (Es ist eine pas-Datei, die mit "Program" beginnt) das Ereignis ClientConnect einbinde. In der Delphi-Entwicklungsumgebung gibt es das ja, indem man in der Ereignisliste das entsprechende Feld doppelklickt.

Ich hoffe, es ist einigermaßen klar, wo der Hase langläuft. Wenn ich mich missverständlich/undeutlich/falsch ausgedrückt habe, bitte ich das zu entschuldigen. Ich habe gerade wieder mit Delphi nach 7 Jahren Abstinenz angefangen (an der Uni gabs nur C++) und bin schon froh, dass ich Narses' Socket-Protokoll umsetzen konnte.

Viele Grüße

Schau dir mal von NArses die Tutorials zum TClientSocket und TServerSocket an. Dort hat er einige Dinge noch mal ganz ausführlich erklärt. Vielleicht helfen die ja schon weiter.

@Non-Blocking: Bei Non-Blocking solltest Du die von der Komponente gelieferten Ereignisse OnRead, OnWrite usw. verwenden. Hat Narses aber IIRC in seinen Tuts auch noch mal ausführlicher erklärt.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Moin!

Trazom hat folgendes geschrieben:

Und zwar kann mein Client nichts mehr empfangen, wenn er auf ctBlocking eingestellt ist.

Doch, er kann empfangen, aber...

Trazom hat folgendes geschrieben:

Ich weiß nicht, ob das Ereignis OnRead ausgelöst wird oder ob er schlicht nicht vom Socket lesen kann.

...es wird eben kein Ereignis mehr dafür ausgelöst. Du musst hier zwangsweise mit Threads arbeiten!

Trazom hat folgendes geschrieben:

in diesem Pascal-Programm (Es ist eine pas-Datei, die mit "Program" beginnt) das Ereignis ClientConnect einbinde.

Ah, ich glaube, jetzt ahne ich langsam, wo hier das Problem steckt: du hast eine Konsolenanwendung, keine VCL-Anwendung mit einem TApplication-Objekt, richtig?

Trazom hat folgendes geschrieben:

Ich habe noch nie was mit Threads am Hut gehabt und weiß auch ehrlich gesagt nicht, was das ist. Ich glaube, in dem Fall sollte ich es wohl doch ohne ctBlocking versuchen.

Dann wird´s Zeit für Luckies Thread-Tut.

cu
Narses

Narses hat folgendes geschrieben:

Trazom hat folgendes geschrieben: in diesem Pascal-Programm (Es ist eine pas-Datei, die mit "Program" beginnt) das Ereignis ClientConnect einbinde. Ah, ich glaube, jetzt ahne ich langsam, wo hier das Problem steckt: du hast eine Konsolenanwendung, keine VCL-Anwendung mit einem TApplication-Objekt, richtig? cu Narses

Allerdings. Vergessen wir das mit den Threads mal, das führt wahrscheinlich zu weit. Problematisch ist, dass ich diese Ereignissteuerung brauche aber da keine Form mit Komponenten habe. Kann ich eine VLC-Anwendung schreiben, die ich von dieser Konsolenanwendung aufrufe?

Viele Grüße

Moin!

Trazom hat folgendes geschrieben:

Problematisch ist, dass ich diese Ereignissteuerung brauche aber da keine Form mit Komponenten habe.

Das ist ein gräßliches hacken, einer Konsolenanwendung eine MessageLoop zu verpassen (also VCL-kompatibel) und kommt letztlich auch nicht wirklich ohne einen (weiteren) Thread aus... Mein Tipp: vergiss es.

Du kannst aber den TClientSocket im blocking-mode betreiben und da es eh eine Konsolenanwendung ist, blockiert sie halt in der Zeit, die der Socket zur Verarbeitung braucht. Man muss halt noch dazu wissen, dass in diesem Fall allerdings immer mit Exceptions um sich geworfen wird - eben auch kein OnError-Ereignis!

Ich habe dir mal eine kleine Demo-Projektgruppe angehangen, die verdeutlicht, was da passiert und wie man das grundsätzlich angehen könnte. Der Server ist eine VCL-Anwendung, die einfach nur "rumsteht" und Connects, Disconnects und Daten (als Text interpretiert) protokolliert (horcht auf Port 12345). Dann gibt´s noch zwei Clients, einen VCL-blocking und einen Konsolen-Client (sendet ParamStr(1) als Text an localhost:12345), Rest wird aus dem Code klar, denke ich.

cu
Narses