Delphi .NET - Unterschied zwischen Windows-Forms und VCL

[Matze]

Hallo zusammen!

Ab Delphi 2005 kann man ja diese tollen .NET Anwendungen coden. :love: Ich dachte immer, da komme ich um C# nicht herum.


Man kann auswählen, ob man eine Windows Forms-Anwendung oder eine VCL-Formularanwendung erstellen möchte.

In der Delphi-Hilfe habe ich dazu nichts gefunden, aber vielleicht liegt es auch daran, da ich mich an diese noch nicht gewöhnt habe.

Unterschiede sehe ich in der Bestückung der Komponenten. Windows-Formularanwendungen nutzen wohl keine VCL, weshalb die Komponenten eher spärlich ausfallen im Gegensatz zur VCL Formularanwendung.

Die Komponenten für eine Windows-Form-Anwendung gefallen mir nicht sonderlich und handhaben sich ganz anders als die der VCL.

Am liebsten würde ich weiterhin mit der VCL arbeiten.

- Gibt es da Einschränkungen, was die Kompatibilität zu den Frameworks betrifft?
- Gibt es andere Vor- / Nachteile?
- Wieso gibt es diese 2 Optionen?

Vielleicht ist es für einige von euch klar, aber mit .NET habe ich so gut wie noch gar nichts gemacht. ;)

[Sanchez]

Hallo,

Die VCL.NET solltest du wirklich maximal zu Übergangszwecken verwenden (z.B. bestehende Anwendungen portieren, ...). Sie greift über P/Invokes weiterhin auf die WinAPI zu. Das macht die Anwendung langsam und unportierbar.
Möglicherweise hilft sie dir beim Einstieg in .NET aber du solltest so bald wie möglich auf WinForms umsteigen.

Der Entwickler hat dazu einen interessanten Onlineartikel: http://www.derentwickler.de/itr/onli...nodeid,56.html

grüße, daniel

[Matze]

Der Artikel ist genau das, was ich gesucht habe, danke.

Schade, dachte, ich könnte die VCL weiterverwenden, naja, dann muss ich mich eben langsam umstellen. ;)

[Bernhard Geyer]

Zitat:

Zitat von Matze

Schade, dachte, ich könnte die VCL weiterverwenden, naja, dann muss ich mich eben langsam umstellen. ;)

Solange Du nicht gezwungen bist würde ich es nicht machen. WinForms sind ja auch schon wieder Deprecated, da mit .NET 2.0 mit Avalon ein Vektoransatz kommen wird. Kein Kunde (falls zu Kommerzielle SW machst) wird die den Aufwand bezahlen, wenn nach einer portierung zwar ein .NET-Programm herauskommt, aber erstmal keine einzigartigen Features.

Du kannst z.B. mit Managed Extensions for VCL auch unter Win32 .NET-Controls verwenden ohne den Umweg über COM-Wrapper zu gehen.

[Matze]

Zitat:

Zitat von Bernhard Geyer

Solange Du nicht gezwungen bist würde ich es nicht machen.

Ok, schade, die leitet mich direkt dazu, sie zu verwenden. ;)

Zitat:

Zitat von Bernhard Geyer

WinForms sind ja auch schon wieder Deprecated, da mit .NET 2.0 mit Avalon ein Vektoransatz kommen wird.

Heißt das, man sollte eher nochmal ganz abwarten, bis Microsoft ein endgültiges Realease des Frameworks zusammengestellt hat? Denn so ändert sich das ja ständig.

[Bernhard Geyer]

Zitat:

Zitat von Matze

Heißt das, man sollte eher nochmal ganz abwarten, bis Microsoft ein endgültiges Realease des Frameworks zusammengestellt hat? Denn so ändert sich das ja ständig.

Wenn Du etwas neu entwickelst und aus dem .NET-Framework Vorteile ziehen kannst brauchst Du nicht zu warten. Aber im Bereich Oberflächen hat .NET in der FCL nunmal nichts Weltbewegend neues zu bieten. Alle Features (bis auf CF-Unterstützung) kann ich auch mit Delphi-VCL-Controls erledigen. Und ein Zeitrahmen von 5 Jahren zwischen Version 1.0 und 2.0 ist ja auch keine ständige Änderung.

[Matze]

Achso, danke. Und wieso würdest du nicht mit der VCL arbeiten? Greift sie wirklich auf die WinAPI zu?

[Robert_G]

Ich muss da mal kurz einschreiten...
Mir würde es nie in den Sinn kommen auch nur irgendwas mit der VCL zu lösen, wenn ich auch nur den Hauch einer Chance hätte, es mit der FCL zu lösen.
Mir wäre es dabei auch total Bohne ob Winforms übermorgen zusammen mit der VCL stirbt. Sterben eben beide... :P
In der Zwischenzeit kann man aber mit WinForms und der FCL einfach hübscher, schneller und eleganter entwickeln. (zumindest IMHO ;) )

@Matze
Wie du auf die Idee kommst, dass die VCL.Net mehr Klassen als WinForms enthält kapier' ich jetzt nicht wirklich... :gruebel:
StiNo WinForms/FCL Komponenten gibt es wohl ein Vielfaches als StiNo Borland-VCL Komponenten.
Wenn du was anderes suchst, dürften GotDotNet, CodeProject und msdn.microsoft.com ein paar mögliche Anlaufstellen sein. ;)

[Matze]

Zitat:

Zitat von Robert_G

Wie du auf die Idee kommst, dass die VCL.Net mehr Klassen als WinForms enthält kapier' ich jetzt nicht wirklich... :gruebel:

Also in Delphi 2005 (Personal) gibt es deutlich weniger WinForms-Komponenten, als VCL-Komponenten, das meinte ich.

[Hansa]

Zitat:

Zitat von Robert_G

...In der Zwischenzeit kann man aber mit WinForms und der FCL einfach hübscher, schneller und eleganter entwickeln. (zumindest IMHO ;) )...

Genau das ist eben der Unterschied zwischen Theorie und Praxis. Es geht um die Zwischenzeit ! Und dafür ist die VCL.NET gedacht. Solange .NET nicht vollständig ist, kann ich nicht in einer undefinierten Zwischenzeit mit Sachen arbeiten, die es noch gar nicht gibt und keiner weiß, wann es sie gibt. Ergo : die Winapi ist momentan nur halbtot, das Begräbnis ist aber bereits vorbereitet. Der Termin aber nicht. Siehe Papst : der ist schon weiter und der Termin steht fest. :mrgreen:

Borland hat das alles auch oft genug gesagt. Deshalb empfiehlt es sich bei einem neuen Programm, dieses vielleicht als VCL.NET Application zu entwickeln. Sofern man Sachen braucht, die in .NET noch gar nicht verfügbar sind. Dann geht es mit FCL nämlich gar nicht. Zumindest ist das besser, als jetzt noch eine auf WinApi basierende zu bauen. Für bestehende Sachen ist es vielleicht auch besser, sie schnell auf VCL.NET zu portieren und in einem zweiten schnellen Schritt dann noch auf WinForms. Schnell heißt übrigens nur so und wird schon lange dauern.

Folgende Faustformel gilt mindestens seit D7 : Finger weg von direkten WinApi Aufrufen ! Wer das nicht macht, der hat die meiste Arbeit am Hals, die keiner sieht und auch keiner freiwillig bezahlen wird. 8)

[Matze]

Zitat:

Zitat von Hansa

Deshalb empfiehlt es sich bei einem neuen Programm, dieses vielleicht als VCL.NET Application zu entwickeln.

Ich dachte, genau das Gegenteil wäre der Fall. :gruebel:

[Bernhard Geyer]

Zitat:

Zitat von Robert_G

Mir würde es nie in den Sinn kommen auch nur irgendwas mit der VCL zu lösen, wenn ich auch nur den Hauch einer Chance hätte, es mit der FCL zu lösen.

Da habe ich einen anderen Sinn :-)
Es kommt halt darauf an welche Rahmenbedingungen man hat.
Meine Programme z.B. müssen auch von CD auf alten System laufen. Und da kann man .NET nicht vorrausetzen bzw. den Kunden nicht zwingen alle Möglichen Updates/Installer (IE min 5.01, COM-Updates, Framework-Installer, ...) zu installieren. Und hast du schon mal probiert ein .NET-Programm (ohne vorgeschalteten Installer) auf einem System zu starten ohne installierten .NET-Framework. Da gab's schon bessere Lösungen von M$ (Umstieg DOS/Windows, Win16/32)[/quote]

Zitat:

Zitat von Robert_G

In der Zwischenzeit kann man aber mit WinForms und der FCL einfach hübscher, schneller und eleganter entwickeln. (zumindest IMHO ;) )

Und was findest Du bei FCL hübscher, schneller und eleganter (vor allem Bezüglich Oberflächenentwicklung).

Zitat:

Zitat von Robert_G

Wie du auf die Idee kommst, dass die VCL.Net mehr Klassen als WinForms enthält kapier' ich jetzt nicht wirklich... :gruebel:

Stimmt. Es werden nur bei Delphi mehr VCL als FCL-Controls mitgeliefert. Man muß sich halt im Internet auf die Suche machen.

[Hansa]

Zitat:

Zitat von Matze

Zitat:

Zitat von Hansa

Deshalb empfiehlt es sich bei einem neuen Programm, dieses vielleicht als VCL.NET Application zu entwickeln.

Ich dachte, genau das Gegenteil wäre der Fall. :gruebel:

Du mußt genau lesen : da steht "vielleicht". Wenn Dir die momentan vorhandenen .NET Sachen reichen, dann brauchst du die VCL.NET nicht. Allerdings brauchst du dann auch keine Angst zu haben, ein Win32 Programm zu portieren auf .NET. Bei größeren Programmen sieht es aber ganz anders aus. Da muß jetzt was getan werden und zwar schnell ! Ansonsten wird man nämlich nicht fertig.

Insofern kann man nicht auf Mickysoft warten, bis die ihr .NET endlich fertig haben. VCL.NET ist eben eine Abkürzung. Es ist nicht möglich, alles auf einmal zu machen, aber es besteht die Möglichkeit, einen unvermeidlichen Umstieg selber sinnvoll vorzubereiten und durchzuziehen. Und nur darum geht es.

Die Reihenfolge ist : D7 -> alle Warnungen ausmerzen (unsicherer Code usw.), WinApi ausschalten, dann ist schon vieles weg -> VCL.NET -> Winforms.

In kleineren nicht zu sehr spezialisierten Programmen läßt sich der Zwischenschritt VCL.NET eventuell überspringen.

[Matze]

Zitat:

Zitat von Hansa

Du mußt genau lesen : da steht "vielleicht".

Vielleicht heißt doch soviel, dass der, der es geschrieben hat, auch nicht so Recht bescheid weiß, denke ich immer. :mrgreen: ;)

Naja, ich benutze es einfach nicht, wird schon passen, dann nehme ich die WinForms-Projekte.

[Hansa]

Matze, ist das denn so schwer ? Vielleicht heißt nicht, daß ich nicht weiß von was ich rede. Zum 834. mal : das .Net Framework ist noch nicht vollständig. Wie und woher soll ich denn wissen, wann was geht ? Soll ich jetzt darauf warten, daß alles komplett ist und dann erst mit der Arbeit anfangen ? :shock:

Ich verstehe die ganze Diskussion sowieso nicht. Jeder hatte 2 Jahre Zeit, sich mit der Problematik zu befassen und jetzt erst kommen die Fragen. 8) Alle Compiler-Warnungen wurden leichtfertig in den Wind geschlagen. Hauptsache es geht, oder es sieht zumindest so aus. Dann werden noch munter WinApi Prozeduren geschrieben, warum auch immer.

Borland bietet deshalb als Alternative die VCL.NET als Mischmasch an, bis M$ endlich fertig ist. Und auch das hier nochmals :

1. WinApi komplett eliminieren, solange mit D7 nachgucken bis keine Warnug mehr kommt
2. Portierung auf VCL.NET, bis das .NET fertig ist
3. Umstellung auf WinForms

Alles andere ist unrealistisch oder dauert zu lange. Wer Glück hat, der findet jetzt schon in einem WinForms-Programm alles was er braucht. Das müßte dann aber schon ein Mini-Programm sein.

[Bernhard Geyer]

Zitat:

Zitat von Hansa

das .Net Framework ist noch nicht vollständig.

Es ist genauso "vollständig" wie die VCL. In FCL und VCL muß man hin und wieder auf Win32-API "hinabsteigen", aber das sollte ja kein Problem darstellen. Keine vernünftige Anwendung wird im GUI-Design für "normale" PC's und PocketPC's/Smartphones das gleiche GUI verwenden. Aber man kann den Nicht-GUI-Teil in weiten Teilen gleich halten.

Bei passender Kapslung (sowohl bei VCL als auch FCL) kann man bei vorhandensein einer passenden Klasse in neueren Framework-Versionen relativ einfach auf diese umstellen. Der komplette WinForms-Teil basiert auf Win32. Mit dem nächsten VS.NET und den dort vorhandenen erweiterten Oberflächencontrols wird MS sehr viel auf Ownerdraw-Basis ergänzen ähnlich wie man auch bei VCL-Controls vorgeht: Nimm die Basisklasse (TWinControl <-> Control) für Oberflächencontrols und zeichne alles selbst.

[Martin]

An der Stelle will ich mal einen Link in die Runde werfen. Titel: "Warum VCL für .NET?" von Borland-Entwickler Danny Thorpe.

[steph-7]

Hi!

Da mich dieses Thema auch interessiert, hab ich mir mal diesen Thread durchgelesen...
aber irgendwie ist noch kein richtiges Ergebnis bei rumgekommen, oder!?

Wenn ich jetzt ein neues Projekt starten möchten, habe ich ja die Auswahl zwischen:
1. Delphi-Projekte -> VCL
2. Delphi für .NET-Projekte -> VCL (.NET)
3. Delphi für .NET-Projekte -> Windows Forms

Für was sollte man sich entscheiden, wenn man davon ausgeht, dass es weder eine Anwendung für alte PCs wird noch eine "Mini-Anwendung" wird?

[Bernhard Geyer]

Zitat:

Zitat von Sanchez

Die VCL.NET solltest du wirklich maximal zu Übergangszwecken verwenden (z.B. bestehende Anwendungen portieren, ...). Sie greift über P/Invokes weiterhin auf die WinAPI zu. Das macht die Anwendung langsam und unportierbar.
Möglicherweise hilft sie dir beim Einstieg in .NET aber du solltest so bald wie möglich auf WinForms umsteigen.

Einspruch!

Auch WinForms Anwendungen machen sehr viel gebrauch von P/Invoke. Da ist WinForms nicht besser als VCL.NET. Was aber MS mit WinForms besser machen kann ist die entsprechenden P/Invoke-Zugriffe im .NET-Redistributable-DLL's zu verpacken und und diese als "sichere" DLL's einen schnelleren P/Invoke-Mechanismus zukommen zu lassen. Borland-VCL-Dll's oder in die Exe gelinkte P/Invoke-Aufrufe werden vom .NET niemals so weitreichendes Vertrauen bekommen wie die eigentlichen .NET-DLL's.

Was mit Sicherheit auch besser bei WinForms ist das es weniger Altlasten gibt. WinForms setzt als minimum ein Win98 mit IE 5 vorraus. VCL(.NET) basiert im Kern immer noch auf die erst Win16-Version.

WinForms-Controls unter .NET 1.1 sind auch nur "simple" Wrapper um den im BS vorhanden Win32-Controls. Erst mit .NET 2.0 fängt MS an CustomControls komplett in .NET zu entwickeln mit nur minimalen Win32-Abhänigkeiten (Es ist immer noch ein Windows-Handle nötig).