NonVCL datei

[jokerfacehro]

hallo,

ich möchte ein NonVCL programm schreiben. (mit Delphi 7 enterprise)
das programm soll ohne oberfläche arbeiten.
und über einen TCPClient verfügen.

die TCP Kompo wäre mir egal, ob Indy oder standard WIndows Kompo

ich habe allerdings keine ahnung wie ich da ran gehen soll.

[Bernhard Geyer]

Zitat:

Zitat von jokerfacehro

die TCP Kompo wäre mir egal, ob Indy oder standard WIndows Kompo

Bei nonVCL fallen wohl die Indy raus - Ist ja VCL

[DeddyH]

Du müsstest die benötigten Objekte halt zur Laufzeit dynamisch anlegen. Owner kann hier dann natürlich nur nil sein, da Du ja kein TComponent-Objekt hast, welches diese Rolle übernehmen könnte. IIRC gibt es von Luckie hier irgendwo einen entsprechenden Codeschnippsel, aber da ich jetzt Feierabend habe fehlt mir die Zeit zur Suche :zwinker:

[jokerfacehro]

ok, das wäre jetzt kein problem.

allerdings weiß ich nicht, wie ich da sprogramm jetzt aufzubauen habe.

gibt es da wie bei c++ ne main prozedur oder wie sieht das aus ?

Edit: das dynamische erstellen der kompos ist auch kein problem ^^



ich weiß bloß nicht wie die struktur für das hauptprogramm aussieht, da es ja bei delphi keine vorlage dafür gibt

[himitsu]

Indy = "unsichtbare" Kommunicationskomponente

VCL (Visual Component Library) = (oftmals) sichtbare Ein/Ausgabekomponente für ein UI (User Interface)


Also es kommt darauf an, was du durch "NonVCL" erreichen willst, aber von der Definition her ist die Verwendung der Indy in einem NonVCL-Programm kein Wiederspruch.

[sirius]

Ein Tutorial für die Sockets:
http://www.delphi-treff.de/tutorials...ts-mit-winapi/

Edit:

Zitat:

ich habe allerdings keine ahnung wie ich da ran gehen soll.

Du nimmst eine Konsolenanwendung und löschst, dass {$Apptype Console} raus. fertig.
Und jetzt beginnst du mit deinem Code, so in der Art (wenn du Sachen mit Messages verwendest):

Delphi-Quellcode:

begin
  init;
  while getmessage(msg,0,0,0) do
    dispatchmessage(msg);
end.

[jokerfacehro]

@ sirius

so habe ich es jetz auch gemacht, dass AppType wegkommentiert ^^

[jokerfacehro]

ich nehme jetzt direkt nen Socket.

habe gerade die Indy Bibliotheken hinzugefügt und nachm compilieren, warns schon 300KB :shock:


Edit: danke euch für die schnellen antworten :thumb:

[Bernhard Geyer]

Zitat:

Zitat von himitsu

Indy = "unsichtbare" Kommunicationskomponente

VCL (Visual Component Library) = (oftmals) sichtbare Ein/Ausgabekomponente für ein UI (User Interface)

Bis D6 war alles VCL was as Basis TComponent hat. Die Unterscheidung VCL = GUI und Base CLX = Nicht Visuelle Kompos kam erst mit D6 und der (schon gestorbenen) CLX/Kylix.

Und bisher haben fat alle nonVCL'ler gemeint da nicht mal SysUtils eingebunden werden darf.

[jokerfacehro]

noch ne frage


ich hab jetz paar prozeduren die auf einander zugreifen.



1. prozedur
2. prozedur
....

wenn die 1. auf die 2. zugreifen will, kennt delphi die prozedur noch garnicht.
wie muss ich denn die prozeduren vorher deklarieren. ?

[sirius]

Delphi-Quellcode:

procedure xyz; forward;

prcoedure abc;
begin
  xyz;
end;

procedure xyz;
begin
  //...
end;

[mjustin]

Zitat:

Zitat von jokerfacehro

habe gerade die Indy Bibliotheken hinzugefügt und nachm compilieren, warns schon 300KB :shock:

Dann muss da noch etwas anderes mit eincompiliert worden sein - mit Delphi 2009 liegt eine Indy TCPClient Anwendung bei mir (inklusive all dem eigenen Code) bei ca. 180 KB.

[jokerfacehro]

Zitat:

Zitat von mjustin

Zitat:

Zitat von jokerfacehro

habe gerade die Indy Bibliotheken hinzugefügt und nachm compilieren, warns schon 300KB :shock:

Dann muss da noch etwas anderes mit eincompiliert worden sein - mit Delphi 2009 liegt eine Indy TCPClient Anwendung bei mir (inklusive all dem eigenen Code) bei ca. 180 KB.

ich hab Delphi 7 Enterprise mit Indy 10



die exe sollte auf jedenfall unter 100KB liegen und ohne SysUtils komme ich auf 20KB

[Luckie]

Achtung. Die Indys brauchen das Application-Objekt. Und was du willst ist wohl eher ein unsichtbares Konsolenprogramm. Und gibt es einen Grund, warum die Exe nicht größer als 100KB sein darf?

[jokerfacehro]

ich benutze keine Indys weil die mir zu groß werden.
und der sinn von NonVCL sind üfr mich nun mal kleine programme ^^
deswegn will ich unter 100KB bleiben, was auch gut möglich ist

[Assertor]

Zitat:

Zitat von Luckie

Achtung. Die Indys brauchen das Application-Objekt.

:shock: 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

[jokerfacehro]

danke für die info, hilft bestimmt jemandem ^^


ich hab en anderes problem

ich hab hier ein WSAASyncSelect und das braucht en handle ^^
und da ich kein form hab, hab ich auch kein handle

Delphi-Quellcode:

WSAAsyncSelect(FSocket, self.Handle, WM_mySocket, FD_READ or FD_CLOSE or FD_WRITE)

[DeddyH]

Ich kenn das Ding nicht, aber wenn Du einfach 0 übergibst?

[Astat]

Hallo jokerfacehro, GROSSES TIP :warn:

Thread #6 sirius :thumb: , ohne dieses Tutorial durchzuackern, und auch zu verstehen, wirds schwierig mit der Socket API.
Desswegen gibts ja Indy und Konsorten.

lg. Astat

[sirius]

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

@TE
Du musst die ein Fenster erstellen. Entweder nonvcl oder mit allocateHwnd aus der Unit Classes.

Aber vielleicht kommst du hier auch ohne AsyncSelect aus. Wenn du nur einen simplen Client ohne Userinteraktion hast, kannst du deinen Socket doch blockierend lassen.

[sirius]

Zitat:

Zitat von Assertor

Zitat:

Zitat von Luckie

Achtung. Die Indys brauchen das Application-Objekt.

:shock: 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:

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 :lol:

[mjustin]

Zitat:

Zitat von sirius

Zitat:

Zitat von Assertor

Zitat:

Zitat von Luckie

Achtung. Die Indys brauchen das Application-Objekt.

:shock: 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 :wall: 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 :oops:

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

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:

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:

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.

[QuickAndDirty]

Doch brauchst du, nur kein Formular. So wie ich das verstanden habe solltest du dir ein Windowhandle kreieren.

[sirius]

Zitat:

Zitat von QuickAndDirty

Doch brauchst du, nur kein Formular. So wie ich das verstanden habe solltest du dir ein Windowhandle kreieren.

Achja,. Ok so kann man es auch verstehen. Allerdings hat ein Windowhandle immer etwas mit einem Fenster zu tun. Dieses kann man aber auch unsichtbar / "virtuell" machen.

[jokerfacehro]

Zitat:

Zitat von 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.

also EventSelect hört sich da ganz verführerisch an, allerdings hab ich dazu nix gefunden

[SirThornberry]

Bitte kommt nicht vom eigentlichen Thema ab. Es ging darum wie man eine non-vcl-Anwendung schreibt.
Inzwischen geht es schon darum wie man die Sockets etc. verwendet. Das ist definitiv ein neues Thema und dafür sollte auch ein neues Thema angelegt werden. :)
Ansonsten wird es irgendwann ein riesen Durcheinander weil niemand mehr durchsieht welche Antwort zu welcher Frage gehört. Und auch über die Suche wird dann niemand mit dem gleichen Problem später einmal die Lösung finden.
Daher: Neue Frage -> neues Thema erstellen.

[sirius]

Ich glaube, du musst dir erst einmal klar werden, was dein Programm überhaupt alles machen soll und wie es arbeiten soll. Ansonsten bringt das alles nichts.

[jokerfacehro]

ich weiß schon was es machen soll.
ne tcp verbindung aufbauen und einfache befehle abarbeiten die ankommen.