Delphi .NET - Unterschied zwischen Windows-Forms und VCL

[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).