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)