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