VCL <-> WinAPI : Vorzüge, Nachteile

[Hansa]

Hi,

von der WinAPI habe ich nicht den großen Plan. Es geht mir um folgendes: Ist es möglich bzw. sinnvoll die VCL zu ersetzen :?: Bei einem kleinen Programm dürfte es Sinn machen, aber je komplexer das ganze wird, kommt man da überhaupt an der VCL vorbei ?

Ich gehe mal von Fremdkomponenten aus, die man nicht selber umprogrammieren kann. Angenommen, da ist ein VCL-Edit - Feld drin. Soweit ich weiß, ist es dann eben mit eincompiliert. Also ist die nonVCL - Programmierung für die :cat: Nutze ich nun noch 200 dieser Edit-Felder, so dürfte es wohl egal sein, oder ?

[Chewie]

Na ja, du hast keine großen Code-Änderungen ob du eins oder 200 Edit-Felder benutzst. Der Grund-VCL-Code, der jedes Mal mitkompiliert wird, ist halt so um die 250k, die Erstellung der Objektinstanzen ist bei sowohl VCL als auch nonVCL etwa gleich viel Code (OK, bei VCL etwas mehr durch die DFM-Resourcen).
Nur hast du massenhaft Arbeit, wenn du 200 Editfelder nonVCL verwalten willst...

Delphi-Quellcode:

if uMsg = EN_CHANGE then
begin
  case lParam of
    hEdt1:
    hEdt2:
    hEdt3:
    hEdt4:
    hEdt5:
    hEdt6:
    hEdt7:
    hEdt8:
    hEdt9:
    hEdt10:
    hEdt11:
    hEdt12:
    hEdt13:
    hEdt14:
    hEdt15:
    hEdt16:
    hEdt17:
    hEdt18:
    hEdt19:
    hEdt20:

usw. :wink:

[-Amazeroth-]

Korrekt bemerkt. Ich zitiere mich mal selber aus dem Thread aus dem du diesen abgeleitet hast:

Zitat:

@TimmA: Die Größe ist wahrscheinlich eines der Hauptargumente. Dennoch würde kein nonVCL-Freak versuchen ein riesiges Datenbankprogramm oder gar ein halbes Betriebssystem, einen Wordprozessor oder ähnliches in nonVCL zu schreiben. Dann benutzt man immer etwas wie die VCL, CLX o.ä..

Es ist müßig über Riesen-Projekte zu streiten. nonVCL hat auch was mit sauberer Programmierung zu tun. Denn bei solchen Programmen muß man sauber Programmieren. Bei der VCL ist alles "viel weiter weg" ... du bist vom eigentlichen Kern abgeschnitten. Es ist also nicht mehr nötig auf alles zu achten. Ich bin der Auffassung, daß jeder der für Windows Programme schreibt (mit Delphi) zumindest mal in nonVCL reingeschnuppert haben sollte und in der Lage sein sollte die Beispiele aus zB Luckies Tutorials ohne weiteres nachzuvollziehen. Es gibt eben immernoch einiges, was die VCL nicht direkt anbieten kann ... spätestens dann sieht man auch bei VCLern das Abfangen von Fensternachrichten etc pp. Und darum geht es bei nonVCL. Verständnis der darunterliegenden Mechanismen.

Ich halte zB mein EDA (Preview nur als EXE) oder LoggedOn2 (neue nicht veröffentlichte Version) schon für ein großes Projekt, aber dort benutze ich auch Klassen, nur eben nicht die VCL.

Ein Substitut für die VCL ist bspw die KOL.

@Chewie: Dann fehlt dir noch einiges an Verständnis in nonVCL. Du kannst zB mit EnumChildWindows durch alle EDITs gehen und sonstwas machen. Und ich habe genug VCL-Code gesehen, der ähnlich aussah wie dein Beispiel. Nämlich Spaghetti-Code. Dazu ist allerdings die VCL förderlich, weil niemand auf die Idee kommt zB ein Array von Controlhandles zu nehmen und weil man eben nicht so einfach die Enum-Funktionen einsetzen kann. Das meine ich mit "sauber Programmieren".

[MathiasSimmack]

Zitat:

Zitat von Hansa

Ist es möglich bzw. sinnvoll die VCL zu ersetzen :?:

Der Sinn von Borland war IMHO eigentlich genau umgekehrt. :) Sonst würden wir heute immer noch im Stil von TPW programmieren.

Zitat:

Bei einem kleinen Programm dürfte es Sinn machen, aber je komplexer das ganze wird, kommt man da überhaupt an der VCL vorbei ?

I don't think so. Würde ich auch nicht versuchen.

Letzten Endes hängt es aber auch vom eigenen Erfahrungsschatz ab. Ohne das List-View-Tutorial vom Kollegen Luckie hätte ich wahrscheinlich gar nicht erst versucht, Sachen wie meinen UIS (UnInstall Secrets) oder HED (Hosts Editor) ohne VCL zu schreiben.
Und mittlerweile weiß ich sogar, wie man die Original-Symbole von Dateien in der LV anzeigen kann. (Achtung Werbung! Wird in der nächsten Tut-Version dabei sein.) Vom dem ganzen WinXP-Kram, den ich mir mühsam selbst erarbeiten musste (das PSDK schweigt sich zu Gruppenbildung und Tile-View der LV aus) ganz zu schweigen. Und darauf bin ich tatsächlich stolz, dass ich das hinbekommen habe.

Schade, dass Assarbad nicht mehr da ist ... *hüstel* ... der könnte erzählen, was für Sprünge ich beim Rebar-Control (VCL = TCoolbar) machen musste, um den Chevron anzuzeigen, bzw. die nicht sichtbaren Buttons einer Toolbar dann im Popupmenü des Chevrons auftauchen zu lassen. Auch dazu fehlen IMHO Infos im PSDK.

Aber es gibt halt auch Sachen, dafür würde ich die VCL um keinen Preis missen wollen.

[Hansa]

Die Frage war nicht konkret genug. :mrgreen: Es geht mir um "einmal VCL, immer VCL ?" Also, nützt es was, die WinAPI zu verwenden, sofern nur ein einziges Feld aus der VCL kommt ? Wenn ich mich nicht irre baut der Compiler eine Einsprungadresse zusammen, an der das Programm jedesmal landet, sofern etwas ähnliches angesprochen wird, ähhm also so in der RIchtung. 8) Also dürfte es wohl egal sein, ob ein Editfeld, Listbox usw. verwendet wird, 200, 500 oder nicht, oder doch ?

Ich will darauf hinaus, daß die VCL Programme von Anfang an halt größer sind, aber nicht in dem Maße wachsen, somit wäre es bei einem großen Programm eher unsinnig die WinAPI direkt anzusprechen.

[jbg]

Das Programme mit der VCL so groß sind, liegt nur daran, dass der Linker vieles nicht entfernen kann. Dies liegt darin begründet, dass z.B. Classes und Forms/Controls einen initialization/finalization Abschnitt haben, die so einiges machen. Wenn man da die Funktionsaufrufe entfernen würde, die nicht benötigt werden, würde sich die Exe-Dateigröße sehr stark minimieren. (Vergleiche OWL Programme). Das macht nur keiner, da man die RTL/VCL neu kompilieren müsste, was sich nur wenige trauen und bereits kompilierte Komponenten nicht mehr funktionieren könnten.

[jbg]

Zitat:

Zitat von Hansa

Es geht mir um "einmal VCL, immer VCL ?" Also, nützt es was, die WinAPI zu verwenden, sofern nur ein einziges Feld aus der VCL kommt ?

Dann hast du den VCL Overhead bereits. Also rendiert sich nonVCL nicht mehr wirklich.

[-Amazeroth-]

Hatten wir doch schon, Hansa, es lohnt sich dann nicht mehr, sobald das erste Stückchen VCL im Code ist. Dann ist die gesamte RTTI drin etc pp :)

Kleiner Test zum Nachmachen:

• Benutze in einem Konsolenprogramm mal MMFs, mal einen TStream (unit Classes) :)
• Nimm ein anderes leeres Projekt (Konsole, also ohne VCl, nur Windows.pas) und binde die Sysutils-Unit ein ... du wirst einen Größenunterschied von einigen kB bemerken.

... der Rest ist gesagt zB von jbg!

[jbg]

Zitat:

Zitat von -Amazeroth-

RTTI

Du meinst RTL/VCL, denn RTTI = RunTime Type Information und kann über die Unit TypInfo angesprochen werden.

Und damit sind wir wieder bei dem Dateigrößen, wobei mir wieder einfällt, dass VC++ Programm ja immer kleiner sind, als VCL Programme. Woran das nur liegt? :roll: - Ach is weiß schon. Man addiere Exe-Dateigröße, MFC42.DLL, MSVCRT*.dll und noch ein paar weitere "kleine" DLLs.

[-Amazeroth-]

RTTI wird mit abgespeichert. Beispielsweise gehören default-Werte von Properties dazu. Deshalb meine ich schon RTTI :)

Un die bläht alles auf. Die KOL verzichtet drauf und siehe da ... es ist viel kleiner. Allerdings, ohne RTTI auch kein Designen in der IDE ;)

LOL, wenn du das RT-Package (von Delphi) nicht mit einkompilierst, dann ist die (VCL)Anwendung auch sehr viel kleiner. Und um ehrlich zu sein, kenne ich keine MFC-Programme die kleiner sind und mindestens genausoviel bieten wie ein vergleichbare (nur-API) nonVCL-Programm!

Bei VB ist es im übrigen sehr ähnlich. Da sind programme allerdings oft wirklich so klein wie ein nonVCL-Prog. Nur leider müssen die VBler auf Inkompatibilitäten Rücksicht nehmen und deshalb immer die passenden (nur wenige MB großen) DLLs zum Download mit anbieten ;)