VCL <-> WinAPI : Vorzüge, Nachteile

[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 ... ) kann auch keine farbigen Pushbuttons erzeugen! Dazu muß der Button OwnerDraw sein ... oder man erzeugt sich gleich seine eigenen Controls

[Hansa]

Zitat von -Amazeroth-:

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

War ja nur ein Beispiel. Irgendwie ging es letztenendes dann auch mit TButton. 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.

[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

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.