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 :oops:
MfG

[mkinzler]

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

[Bernhard Geyer]

Zitat:

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:

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:

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:

Zitat von Bernhard Geyer

Zitat:

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:

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:

Zitat von Luckie

Zitat:

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:

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

[Daniel G]

Eigentlich müsstest du auf der KOL - Website genug Beispiele mit Quelltext finden...


P.S.:
In meinen Augen eignet sich Non - VCL Programmierung eher dafür, die Arbeitsweise von Windows (im Prinzip gibt es nur Fenster...; Die Nachrichtenschleife) besser kennen zu lernen und nebenbei noch "Unwissende" zu beeindrucken... ("Is' dat gepackt?" - "Nope.." - "Boah!"). Für größere Programme bleibe ich lieber bei der VCL...

[rayj]

Zitat:

Zitat von Bernhard Geyer

Zitat:

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

Naja dort werden die Dateien aber immernoch halb so gross wenn man alles mitreinpackt. Bei C++ mein ich.
VB ist klar dass die so extrem klein sind, da fehlt aber meistens dann die Hälfte der DLLs.

Ihr habt aber recht, es lohnt sich für mich nicht ohne vcl zu coden.
Schliesslich würd ich mit C++ auch nie WinAPI Programmieren, das wär zuviel des Guten ;)

Wir sind sowieso dabei, langsam auf C# umzusteigen dann gibts das Problem mit der Dateigrösse nicht mehr.

[Bernhard Geyer]

Zitat:

Zitat von rayj

Wir sind sowieso dabei, langsam auf C# umzusteigen dann gibts das Problem mit der Dateigrösse nicht mehr.

Da hast Du ja das Framework welche letztendlich auch Konzepte der Delphi-Packages aufnimmt, jedoch mit einigen mehr an Möglichkeiten und ohne der Probleme der Delphi-Packages (z.B. Versionsprobleme bei Delphi-Fixes).