Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Delphi Indy-Komponenten (https://www.delphipraxis.net/92356-indy-komponenten.html)

OG Karotte 19. Mai 2007 12:25

Re: Indy-Komponenten
 
Zitat:

Zitat von CCRDude
Ich benutze inzwischen Synapse...

Dem kann ich mich nur anschliessen, denn auch mir war das "Ergebnis" mit den Indy's "zu groß" und persönlich finde ich sie insbesondere seit der Version 10 sehr unübersichtlich (sowohl in der Komponentenpalette als auch der Quellcode selbst).

Im Gegenzug dazu empfinde ich Synapse deutlich handlicher mit recht gutem Support und einer übersichtlichen Dokumentation.

Allerdings bleibt es auch bei Synapse dabei, das man sich selbst um Empfang und Senden kümmern muss, will sagen auch hier wird kein Ereignis ausgelöst, wenn Daten empfangen werden...

... aber das ganze in einen "Endlos"-Thread gepackt und Prüfung ob Daten anliegen funzt wunderbar (und die eigene Anwendung wird auch nicht "blockiert").

blablab 19. Mai 2007 12:46

Re: Indy-Komponenten
 
@OG Karotte:
Das hört sich ja ganz interessant an. Werd mir das Synapse mal anschaun...

Eine Frage hätte ich noch, da dir der Platzverbrauch von den Indy's ja au nicht so gefällt.

Zitat:

Zitat von Meflin
Zitat:

Zitat von Blablab
gleichzeitig die exe um 100kb größer wird

Wen stört das? Traffic ist billig...

Was antwortet man auf sowas?

Udontknow 19. Mai 2007 12:48

Re: Indy-Komponenten
 
Zitat:

Zitat von blablab
Ob ich jetzt n ereignis bekomm wenn er ne verbindung macht oder was auch immer, auf jeden Fall bekomm ich beim Server n Ereignis, wenn ich daten bekomme und beim Client nicht...

:wall:
Arghhh... Zum dritten Mal: Das OnExecute-Event des TCPServers ist kein Datenempfangsevent! Der einzige Grund, warum beim Server es dieses Event gibt, und beim CLient nicht, ist, daß der Server mehrere Verbindungen auf einmal verwalten muss. Es ist einfach nur da, um dem Programmierer die Möglichkeit zu geben, Code in Abhängigkeit der Verbindung (Parameter AContext bzw. AThread) zu definieren, der dann ausgeführt werden muss. Innerhalb der Execute-Routine (also innerhalb des Verbindungsthreads) wird doch aber genauso "geblockt", wenn du ein Readln o.ä. aufrufst...

Bis dann,

Andreas

jmit 19. Mai 2007 12:53

Re: Indy-Komponenten
 
Hallo,

Zitat:

Zitat von OG Karotte
Zitat:

Zitat von CCRDude
Ich benutze inzwischen Synapse...

Dem kann ich mich nur anschliessen, denn auch mir war das "Ergebnis" mit den Indy's "zu groß" und persönlich finde ich sie insbesondere seit der Version 10 sehr unübersichtlich (sowohl in der Komponentenpalette als auch der Quellcode selbst).

Im Gegenzug dazu empfinde ich Synapse deutlich handlicher mit recht gutem Support und einer übersichtlichen Dokumentation.

Allerdings bleibt es auch bei Synapse dabei, das man sich selbst um Empfang und Senden kümmern muss, will sagen auch hier wird kein Ereignis ausgelöst, wenn Daten empfangen werden...

... aber das ganze in einen "Endlos"-Thread gepackt und Prüfung ob Daten anliegen funzt wunderbar (und die eigene Anwendung wird auch nicht "blockiert").

... und wo kann ich Synapse inkl. Dokumentation herunterladen.

Gruß Jörg

blablab 19. Mai 2007 13:07

Re: Indy-Komponenten
 
@Udontknow:
Tut mir leid wenn ich dich nerv...

Ok, lassen wir das. Ich glaub ich hab verstanden was du meinst.

OG Karotte 19. Mai 2007 13:16

Re: Indy-Komponenten
 
Zitat:

Zitat von jmit
... und wo kann ich Synapse inkl. Dokumentation herunterladen.

Guckst Du hier (die Website) oder hier als direkter Download (ca. 800 kb).

Und als ergänzende Info kann ich diese PDF empfehlen (Ist allerdings (immer noch) in einem sehr frühen Stadium :( ). Trotzdem kann man das eine oder andere dort nachschlagen / vertiefen.

@blablab:

Zitat:

Zitat von blablab
...Was antwortet man auf sowas?

Nichts, warum auch, denn es stimmt:
mal kostet der Traffic (ich nehme mal an es wird der Download gemeint) nichts (Fulltimeflat), mal ein wenig (Flatrate nach Traffic) und mal 'n bisschen mehr (Modem / ISDN (Na ja, es sei denn es ist eine SAT-Verbindung, dann sind es ca. 9 Euronen die Minute, aber das ist eher die Aussnahme)).

Aber bei den heutzutage üblichen Proggrössen fallen diese 100k auch nicht mehr so in's Gewicht...

Meflin 19. Mai 2007 14:09

Re: Indy-Komponenten
 
Zitat:

Zitat von blablab
Ne, eigentlich störn mich die 100KB, die wahrscheinlich net alle notwendig sind und wegen den vielen Dateien in der Uses-Klausel zustandekommen. Und ich frag mich auch, wie die 100KB zustandekommen nur zb für nen TCP-Server...

Wieso? Stört dich dann auch, dass eine leere (!) Delphi-Anwendung ~400kb (abhängig von der Delphi-Version) groß ist? Ist ja wohl auch net wirklich nötig oder. Aber ich bin mir sicher, da hast du dir auch nicht den Kopf darüber zerbrochen, weil es nunmal einfach so ist.

Zitat:

Aber probiers mal aus den Code in dein Projekt zu kopiern. Das wird schwierig, derade deswegen, weil du die vielen Dateien in der Uses-Klausel hast und die einzelnen Dateien wieder viel in der Uses-Klausel stehn haben...
Ich wüsste nicht wieso. Und ich wüsste auch keinen triftigen Grund, weswegen man seine Uses-Liste so klein wie möglich halten sollte und wieso deshalb die Indy-Units in den Uses stören :gruebel:

Zitat:

Ich wollte nämlich mal mit dem Debugger gucken, wieso er fürn Get() mal 5s und mal 20s TimeOut braucht. Aber leider funktioniert der Debugger in den TCP-Komponenten net...
Wieso sollte der Debugger da nicht gehen? Strg + Click auf IdTCPClient/Server Unit, Breakpoint setzen, fertig.



Alle Zeitangaben in WEZ +1. Es ist jetzt 16:11 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz