NonVCL datei

[sirius]

Zitat von Assertor:

Zitat von Luckie:

Achtung. Die Indys brauchen das Application-Objekt.

Nur für das häßliche TIdAntiFreeze (a.k.a. Delphi-Newbie-Warum-Freezt-mein-Form-bei-Blocking-Sockets & Aber-Ich-Versteht-Threads-Nicht). Wenn man das nicht nutzt, läuft Indy natürlich komplett ohne Application Objekt.

Gruß,
Assertor

Die Serverkomponente (bspw. TCPServer in v9) benutzen doch einen Thread und der wiederum benutzt synchronize und das geht nur mit Application-Objekt. Das liegt mir zumindest so im Gedächtnis.

[DeddyH]

Zitat von sirius:

@Deddy, du willst doch ne Message bekommen da kann man doch nicht 0 übergeben.

Ich hatte das beim ersten Lesen für ne Komponente gehalten

[mjustin]

Zitat von sirius:

Zitat von Assertor:

Zitat von Luckie:

Achtung. Die Indys brauchen das Application-Objekt.

Nur für das häßliche TIdAntiFreeze (a.k.a. Delphi-Newbie-Warum-Freezt-mein-Form-bei-Blocking-Sockets & Aber-Ich-Versteht-Threads-Nicht). Wenn man das nicht nutzt, läuft Indy natürlich komplett ohne Application Objekt.

Gruß,
Assertor

Die Serverkomponente (bspw. TCPServer in v9) benutzen doch einen Thread und der wiederum benutzt synchronize und das geht nur mit Application-Objekt. Das liegt mir zumindest so im Gedächtnis.

Synchronize synchronisiert mit dem Hauptthread. Das muss aber nicht der GUI-Thread sein. TThread.Synchronize greift daher nicht auf TApplication zu, das ja wäre auch irgendwie ein schräges Design.

Viele Grüße

[sirius]

Ach na eben. hmmm Wäre mir das mal eher aufgefallen. Ich hatte da sicher mal vor Jahren nachgesehen und mir dies so gemerkt, weil ja standardmäßig, das Applicaton-Objekt in WakeMainThread reinhängt. Aber das kann man ja problemlos ändern.

Ohje: Ich weis gar nicht wie viele Aussagen über TThread ich hier in dem Forum revidieren müsste

[shmia]

Ich habe hier jetzt zwei Extreme gesehen - Indy, die eierlegende Wollmilchsau und WinSocket-API, die low-Level Schnittstelle.
Beides ist für ein Konsolenprogramm eher ungeeignet, da entweder zu fett oder zu kompliziert und nicht objektorientiert.
Aber es gibt auch noch etwas dazwischen, nämlich die Unit ScktComp.
Damit kann man sowohl TCP-Server als auch Clients schreiben.
Aber halt nur TCP/IPv4 (IPv6 oder UDP sind nicht vorgesehen).

Für einen TCP-Client als Konsolenprogramm ist die Unit ScktComp die ideale Lösung.
Man muss mit ungefähr 13 KByte zusätzlichen Code rechnen.

[mjustin]

Zitat von shmia:

Ich habe hier jetzt zwei Extreme gesehen - Indy, die eierlegende Wollmilchsau und WinSocket-API, die low-Level Schnittstelle.

Im Mittelfeld spielt da noch Ararat Synapse eine Rolle: sehr übersichtlich, kompakt, schlank, und leistungsmäßig in allen Tests (TCP Client seitig) mit Indy auf einer Höhe. Und auch kostenlos / Open Source. ScktComp ist schon lange deprecated, wie schon gesagt wird daran nichts mehr getan.

[Luckie]

Zitat von sirius:

Die Serverkomponente (bspw. TCPServer in v9) benutzen doch einen Thread und der wiederum benutzt synchronize und das geht nur mit Application-Objekt. Das liegt mir zumindest so im Gedächtnis.

Genau das hatte ich auch im Kopf.

[sirius]

Zitat von shmia:

Für einen TCP-Client als Konsolenprogramm ist die Unit ScktComp die ideale Lösung.
Man muss mit ungefähr 13 KByte zusätzlichen Code rechnen.

Das ist Ansichtssache. Grade bei einem Konsolenprogramm sind die recht einfach zu handhabenden WinApi-Befehle sehr passend.

[jokerfacehro]

also mit ScktComp hab ich schon mal nen Chat programm geschrieben.
und jetz ma wirklich rudimentär mit den sockets zu arbeiten ist cool

Für AsyncSelect brauch ich jetz aber kein Fenster, wenn ich dem Thread richtig gefolgt bin? ^^

[sirius]

Für Asyncselect brauchst du ein Fenster. Die Frage ist nur, ob du asyncSelect brauchst.

Du kannst auch mit EventSelect ein Ereignis setzen lassen, wenn etwas an deinem Socket passiert. Oder du fragst regelmäßig mit Select dein Socket ab, ob etwas passiert ist. Oder du rufst einfach recv auf, welches dein Programm blockiert. Oder du setzt dein Socket auf nichtblockierend und rufst recv auf, wenn am Socket nix passiert ist, gibts einen Fehler zurück (WSAEWouldBlock).
Du kannst auch die komplette Socketarbeit in einen Thread auslagern und dort blockierend arbeiten.

Du siehst: Möglichkeiten über Möglichkeiten...
Asyncselect ist nur eine, aber eine (und die einzige) die definitiv ein Fenster brauchst.