Ohne VCL, nur mit std. Komponenten programmieren

[rayj]

Hallo
Ich habe mich im Internet ein bisschen umgesehen, warum die Dateien in Delphi so gross werden.
Daran ist ja VCL schuld.

Kann man nicht irgendwie ohne VCL arbeiten, und trotzdem die grundlegenden Komponenten benutzen?
Ich hab z.B. KOL (http://bonanzas.rinet.ru/)

Aber damit komm ich irgendwie nicht klar also ich weiss nicht wie ich es benutzen kann
MfG

[mkinzler]

Suche hier im Forum nach non-vcl, da wirst du einiges zur "low-level" Windowsprogrammierung in Delphi finden.

[Bernhard Geyer]

Zitat von rayj:

Ich habe mich im Internet ein bisschen umgesehen, warum die Dateien in Delphi so gross werden.
Daran ist ja VCL schuld.

Man kann auch Laufzeitpackages verwenden und dann werden die Dateien auch ganz klein.

Zitat von rayj:

Kann man nicht irgendwie ohne VCL arbeiten, und trotzdem die grundlegenden Komponenten benutzen?
Ich hab z.B. KOL (http://bonanzas.rinet.ru/)

Nein. Alle visuellen Komponenten für Delphi basieren nun mal auf den grundlegenden Mechanismen der VCL.

[Elvis]

Ich habe mal vor einer Weile etwas mit KOL gespielt. Es gab sog. Mirror components, die dir die Möglichkeit gaben den VCL Designer zu benutzen.
Die Binaries selbst sind damit absolut winzig. Aber erwarte nicht dass du dort den Hintern mit sanftem 10-lagigem Papier abgewischt bekommst wie in der VCL oder .Net.

[jim_raynor]

Nun mkinzler hat schon das richtige Stichwort genannt. Allerdings sollte jeder für sich entscheiden, ob sich der Aufwand lohnt. Denn nonVCL bedeutet, alles, was dir Delphi abnimmt (Events/Fenster verwaltung und sehr viel mehr) selbst zu machen.

Empfehlenswert zum Einstieg sind glaube die nonVCL Tutorials von Luckie.

Laufzeitpackages sind auch nicht unbedingt die Lösung, da dann wieder diese Packages mit ausgelieftert werden müssen.

[Bernhard Geyer]

Zitat von jim_raynor:

Laufzeitpackages sind auch nicht unbedingt die Lösung, da dann wieder diese Packages mit ausgelieftert werden müssen.

Diesen "Trick" benutzt ja Visual C++ und VB auch. Jedoch hat MS den Vorteil das es einfach diese DLL's gleich mit dem Betriebssystem mitliefern

[Thanatos81]

Zitat von Bernhard Geyer:

Zitat von jim_raynor:

Laufzeitpackages sind auch nicht unbedingt die Lösung, da dann wieder diese Packages mit ausgelieftert werden müssen.

Diesen "Trick" benutzt ja Visual C++ und VB auch. Jedoch hat MS den Vorteil das es einfach diese DLL's gleich mit dem Betriebssystem mitliefern

Stimmt schon. Aber bei einem Kunden, der mehrere in Delphi geschrieben Programme nutzt, lohnt das schon. Alleine wegen der Dateigröße und der damit verbundenen Reduzierung des Zeitaufwands/Bandbreitenverbrauchs bei automatischen Updates

[Luckie]

Zitat von Thanatos81:

Aber bei einem Kunden, der mehrere in Delphi geschrieben Programme nutzt, lohnt das schon.

Und dann hast du im Windowsverzeichnis dutzende von bpl-Dateien rumliegen, weil jede Delphi Version seine eigenen bpl-Dateien braucht und die nicht kompatibel sind.

Zitat:

Alleine wegen der Dateigröße und der damit verbundenen Reduzierung des Zeitaufwands/Bandbreitenverbrauchs bei automatischen Updates

Aha, die Firma geht mir ihren 25 Rechnern noch über ein 28 KB Modem ins Internet? Ab DSL spielt die Exe Größe, die Delphi produziert, keine Rolle mehr.

[Thanatos81]

Zitat von Luckie:

Zitat von Thanatos81:

Aber bei einem Kunden, der mehrere in Delphi geschrieben Programme nutzt, lohnt das schon.

Und dann hast du im Windowsverzeichnis dutzende von bpl-Dateien rumliegen, weil jede Delphi Version seine eigenen bpl-Dateien braucht und die nicht kompatibel sind.

Man könnte das natürlich auch übersichtlicher lösen und ein Bibliotheksverzeichniss anlegen, welches in die Environment-Variable PATH aufgenommen wird

Zitat von Luckie:

Zitat:

Alleine wegen der Dateigröße und der damit verbundenen Reduzierung des Zeitaufwands/Bandbreitenverbrauchs bei automatischen Updates

Aha, die Firma geht mir ihren 25 Rechnern noch über ein 28 KB Modem ins Internet? Ab DSL spielt die Exe Größe, die Delphi produziert, keine Rolle mehr.

Nur weil die Leitung schnell genug ist, muss man ja trotzdem ein Netzwerk nicht stärker belasten, als nötig, oder?

// Edit:
Allerdings werden wir doch ziemlich OT. Können das gerne in einem anderen Thread weiter diskutieren, falls INteresse besteht

[RavenIV]

ob sich der Aufwand für nonVCL rentiert, ist sehr gut zu prüfen.

Was bringen Dir ein paar KiloByte oder MegaByte an Dateigrösse, wenn Du nur alle paar Wochen übertragen musst?
Du hast allerdings einen viel viel grösseren Programmieraufwand.

Und ob Du deine Routinen so performat hinbekommst, wie das die VCL (zum Teil) hat, sei bezweifelt.

Also ich bleibe bei der VCL, wenn sie auch manchmal nicht so toll ist...