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 ;)

[Hansa]

Wie es aussieht, trifft meine Vermutung zu : bei größeren Sachen kommt man an der VCL sowieso nicht vorbei. Und wegen des Code-Overheads der erzeugt wird, ist es egal, sofern man nur an einziger Stelle etwas aus der VCL braucht. Gut, wenn man eine Combo-Box braucht und den Rest mit nonVCL macht, das dürfte was ausmachen. Ich habe mal mein Programm compiliert und die Zeilenzähl-Funktion eingeschaltet. Es sind 10.000. Werden die DFM-Zeilen eigentlich auch mitgezählt ? Egal, das ist sowieso nur ein Teil, da ich alles zerlegt habe. Vermute mal, bei den Größenordnungen spielt die nonVCL absolut keine Rolle mehr, zumindest wegen Speicherplatz usw.

Mit einer großen und wichtigen Ausnahme:
Die VCL kann nicht alles ! Mir ist es z.B. nicht gelungen, damit einen farbigen Button herzustellen. Irgendwas hat da gefehlt. D.h. in solchen Fällen muß man die WinAPI nutzen.

[-Amazeroth-]

Dann nimm TSpeedButton, die WinAPI (@tommie-lie, ich kann mich ja anpassen ... WinAPI ... :mrgreen:) kann auch keine farbigen Pushbuttons erzeugen! Dazu muß der Button OwnerDraw sein ... oder man erzeugt sich gleich seine eigenen Controls

[Hansa]

Zitat:

Zitat von -Amazeroth-

Dann nimm TSpeedButton, die WinAPI (@tommie-lie, ich kann mich ja anpassen ... WinAPI ... :mrgreen:) kann auch keine farbigen Pushbuttons erzeugen!

War ja nur ein Beispiel. Irgendwie ging es letztenendes dann auch mit TButton. :mrgreen: Aber wie gesagt, für so nen Firlefanz kommt man an der WinAPI nicht drum rum. Und wer weiß wozu man sie noch so braucht.

Da fällt mir noch was gutes ein: Laplink und Co. wären ohne WinAPI total aufgeschmissen. Mit der VCL würden die sich besser einen Strick holen, genauso wie ich, wenn ich darauf verzichten würde. :bouncing4:

[negaH]

Ich sehe es ein bißchen anders. Man kann nonVCL = API und VCL = High Level nicht vergleichen. Die VCL setzt ja auf's API auf. Somit ist es so das die VCL nur eine höher angelegte Schnittstelle ist auf die zugrundeliegende API. Also so wie auch das API auf Treiberebene auf VXD/ SYS und Services aufsetzt. Wenn man schon die VCL mit irgendwas vergleichen wollte dann wäre das mit COM/COM+/MFC ein besserer Vergleich.

Da nun API und VCL zwei andere Abstraktionsebenen der gleichen Sache sind fragt sich wo der Unterschied besteht. Der besteht hauptsächlich in der Zielsetzung. API nutzt man wenn man den Overhead der VCL nicht möchte, egal warum. Oder man nutzt es wenn die VCL spezielle Ziele nicht erfüllen kann, weil sie keine Unterstützung des speziellen oder auch neueren API's hat.
Die VCL nutzt man weil sie einem Arbeit abnimmt. Nicht unbedingt Lern-&Denkarbeit, aber im besonderen Wartungs-/&Supportarbeiten. Die VCL ermöglicht es auf einfache Weise dem Entwickler Zusatzkomponenten von Drittanbiertern zu verwenden. Dadurch leistet dieser Drittanbieter Supportarbeiten und Fehlerbeseitungen an seinen Komponenten, was es dem Anwender ermöglicht sich auf sein eigentliches Problem zu stürtzen.


Ein guter VCL Coder ist auch ein Coder der das API, die Konstruktionsweise der Machinen mit denen er arbeitet und somit auch Assembler beherrscht.

Am besten vergleichbar ist die VCL mit der MFC, und da wird wohl keiner bestreiten das die VCL besser und wesentlich effizienter ist. In eienr EXE wird die VCL ca. 250-500 Kb ausmachen. Die MFC DLL's sind ca. 1-2 Mb groß.

Gruß Hagen

[Hansa]

Was ist MFC :?:

[-Amazeroth-]

MFC = Microsoft Foundation Classes
(Das VCL-Pendant von MS, ist bei Visual C dabei).

@Hagen: Recht hast du mit der Aussage, daß die VCL auch eine "API" nur auf höherem Level ist. Leider ist die VCL TThread-Klasse nich annähernd vergleichbar mit CThread. Sie ist "unter aller Sau"!

Zitat:

Ein guter VCL Coder ist auch ein Coder der das API, die Konstruktionsweise der Machinen mit denen er arbeitet und somit auch Assembler beherrscht.

Da kann ich nur sagen ... wo sind dann die ganzen Leute, die von ASM und API und VCL Ahnung haben? Man sieht sie nur selten ;) Ich diskutiere grad mit einem :mrgreen:

Ein echter VCLer sollte zwar, da bin ich ganz deiner Meinung, auch mit API und ASM umgehen können. Andererseits sieht man grade, daß viele Leute sich einfach der Komponenten anderer bedienen, diese aber nichtmal dann bedienen (oder gar anpassen) können, wenn der Source vorhanden ist.

Da kann man echt nur sagen, hier gehts zum Download

[negaH]

Zitat:

@Hagen: Recht hast du mit der Aussage, daß die VCL auch eine "API" nur auf höherem Level ist. Leider ist die VCL TThread-Klasse nich annähernd vergleichbar mit CThread. Sie ist "unter aller Sau"!

Da gebe ich dir Recht. Allerdings gerade in diesem Detail ist ein Vergleich ein bischen unfair. Aus Sicht der neueren VCL kann die MFC nicht unter Linux verwendet werden. Aus Sicht der MFC kann diese sich enorm stark auf die Fähigkeiten des Windows API's verlassen. Dadurch sind die Threadfähigleiten unter Windows bei der MFC besser aber unter Linux existieren diese Fähigleiten nicht für die MFC. Es ist also eine Frage der Zielsetzung :)

Zitat:

Ein echter VCLer sollte zwar, da bin ich ganz deiner Meinung, auch mit API und ASM umgehen können. Andererseits sieht man grade, daß viele Leute sich einfach der Komponenten anderer bedienen, diese aber nichtmal dann bedienen (oder gar anpassen) können, wenn der Source vorhanden ist.

Das empfinde ich nicht als schlimm. Ich meinte unter "VCL-Coder" ein Programmierer der neue Komponenten für die VCL schreibt. Man muß also nochmals differenzieren. Programmierer die Komponenten für die VCL entwicklen können, müssen auch das API beherrschen. VCL Anwednungsprogrammierer wiederum benötigen kein API Wissen und müssen nur in der Lage sein die VCL-Komponenten anzuwenden. Genau diese Abstrahierbarkeit ist der entscheidende Vorteil der VCL.

Mir als Anwendungsentwickler wäre es am liebsten wenn ich alles per Drag&Drop coden könnte ohne eine einzigste Sourcezeile schreiben zu müssen. Sollte es so eine VCL geben würde mein Entwicklungsaufwand drastisch reduzieren. Allerdings verlange ich von so einem Tool viel mehr als das was man momentan auf dem Markt findet. Trotzdem programmiere ich gerne weiterhin auf API und Assembler, aber eben mit andere Aufgabenstellung.

Gruß Hagen

[neolithos]

Ich misch mich mal ein?

MFC heißt Microsoft Foundation Class!
und stellt meineserachtens eine Primitive Kapslung der API dar welche nicht mit der VCL vergleichbar ist, da sie einen anderen Weg verfolgt.

in hier sind zu gut wie alle API-Funktionen in Klassen verpackt!

Bsp:
Um den Titel eines Fesnter's zu setzen
VCL: Caption := 'Neu';
MFC (meineserachtens nur in MS C++ möglich):
m_hWnd->SetWindowText("Neu");
API: SetWindowText(hwndWindow, 'Neu');

MFC bietet aber einige Ausgefeilte Dokument-Ansicht-Strukturen.
Vorsicht:
manchmal etwas anfällig bei Speicherlöchern und Abstürzen
relativ Kompliziert
ODBC-Interface ist schlampig
Viele automatismen kann man schlecht beeinflussen

---

Übrigens VCL und API kann man rühig mischen solangen wie man das intiligent in Klassen unterbringt (Fenster-Handles mittels TWinControl verwalten). Ergo Controls selber bauen!!!


Und ein reines API-Programm würde ich nur Schreiben, wenn nur ich ein oder zwei einfache Fenster benötige.

unter reinen API-Programm verstehe ich Programme, die nur die Units SysUtils, Windows, Messages, (Classes) verwenden.

Grosse Projekte mit komplizierten Fenster nur mit VCL.

[negaH]

Zitat:

und stellt meineserachtens eine Primitive Kapslung der API dar welche nicht mit der VCL vergleichbar ist, da sie einen anderen Weg verfolgt.

Was macht die VCL anderes im TWinControl/TEvent/TThread usw. als das API zu kapseln ?? Beide, MFC und VCL kapslen das API in einen Object Orientierten Ansatz. Das die Qualität und der technische Weg dahin ein anderer ist muß logisch sein. Es handelt sich einerseits um PASCAL, was bekanntlich sozusagen die OOP erfunden hat, und C++ in der MFC.

Vom technischen Ziel kann man MFC und VCL also schon vergleichen, deren qualitative Umsetzung ist nur ein Merkmal.
Natürlich erhebt die VCL den zusätzlichen Anspruch das teilweise verworrene API zu vereintheitlichen. Dies ist eine der wesentlichsten Vorzüge der VCL.

Gruß Hagen

[tommie-lie]

Den gesamten Thread lese ich gleich, aber ich will mal was zur Qualität der VCL einbringen:
Wer mal einfach ein popeliges Fenster hat, keine Buttons, nix, und dieses kompiliert und mit MemProof startet, merkt man gleich, wie sehr es Borland bei der Entwicklung mit der Korrektheit seines Quellcodes gehalten hat.
Das gleiche popelige Fenster in einer nonVCL-Anwendung natürlich vollkommen fehlerfrei (vorausgesetzt man hat fehlerfrei programmiert natürlich *g*).
Andere Tücken treten auf, sobald man versucht Popupmenüs ohne sichtbares Fenster zu öffnen, bei nonVCL kein wirkliches Problem.

[neolithos]

nicht nur vereinheitlich sondern auch vereinfachen