Windows Form Application .NET vs VCL.NET Application

[RogerRabbit]

Hallo,

ich war bis vor kurzen begeisterter Delphi 5 Entwickler.
Nun haben setzen wir Delphi 2005 ein.
Nun stehe ich vor einigen offenen Fragen:

Auf welche Weise sollte man neu eine Application machen ?
zu Auswahl steht bei mir VCL.NET oder Windows Forms .NET.

Wieso frage ich dies. Habe gestern die Komponente SandDock ausprobiert und die ist super genial, jedoch nur in Windows .NET brauchbar.

doch VCL.NET bietet mir die bekanntere Umgebung wie auch bessere Hilfe

Beispiel: Ein Panel auf der Form. Nun soll es dieselbe Grösse haben wie die Form
VCL.NET : panel1.Align := clClient
Windows Forms .NET := alles manuell machen.

Also vom arbeiten her würde ich VCL.NET vorziehen, doch gibt es für VCL.NET auch gute Komponenten ?
Sowie SandDock?

Oder werden kommende .NET Komponenten nur noch so geschrieben, dass man sie nur in Windows Forms .NET gebrauchen kann ?

Einerseits will ich viele Komonenten nutzen können, will aber auch schnell und gut entwickeln, und ich will einen Applicationstyp wählen, welcher nicht in 1 Jahr auf dem Abstellgeleise steht.

Was meint ihr dazu?

Was zieht ihr vor? VCL.NET oder Windows Forms .NET ?
Habt ihr Links zu guten VCL.NET / WiFrm .NET Komponenten ?

Besten dank für eure Meinungen.

Roger Sollberger

[MathiasSimmack]

Zitat:

Zitat von RogerRabbit

Beispiel: Ein Panel auf der Form. Nun soll es dieselbe Grösse haben wie die Form
VCL.NET : panel1.Align := clClient
Windows Forms .NET := alles manuell machen.

Delphi-Quellcode:

Dock = DockStyle.Fill

Geht auch im Eigenschafteneditor ;) Wobei ich zugebe, dass es ein bisschen gewöhnungsbedürftig ist, die Controls so anzuordnen, dass sie dahin sollen, wo man das gern möchte. Ich meine gelesen zu haben, das wäre ein Fehler in .NET, mit dem alle IDEs zurzeit zu kämpfen haben? :gruebel: Jedenfalls musste ich bei meinem Programm mit dem Panel/Control beginnen, das die komplette Fläche (alClient) ausfüllt, und erst danach konnte ich die Toolbar (alTop bzw. DockStyle.Top) einfügen, usw.

[Bernhard Geyer]

Zitat:

Zitat von RogerRabbit

Was zieht ihr vor? VCL.NET oder Windows Forms .NET ?

Falls .NET nicht benötigt wird, so kannst Du ja immer noch VCL.Win32 nehmen.
Falls Du "Altanwendungen" einen .NET-Anstrich geben willst, so kommt Du schneller mit VCL.NET ans ziel.
Wenn Du Anwendungen neu entwickelst und diese nicht ohne .NET laufen sollen (also auch als "alte" Win32-Anwendung kompilieren willst), so nimm FCL / WinForms.

Du kannst z.B. mit Managed VCL Extensions .NET-Komponenten auch unter Win32 verwenden bzw. mittels VCL2NET VCL und FCL-Komponenten auf einem Formular mischen.

[RogerRabbit]

Hallo zusammen,

danke für die antworten.
Wo liegt den die zukunft von GUI entwicklungen ?
Liegt sie in VCL .NET oder FCL .NET ?
Ist z.b VCL .NET auf einem nebengeleise und bald niemand entwickelt mehr Komponenten für VCL .NET ?
oder ist der Trend umgekehrt.

Was meint ihr dazu ?

Gruss Roger

[malo]

VCL.Net wurde imho nur entwickelt, um alte win32-Projekte mit Delphi.NET öffnen zu können, also für die Kompatibilität. FCL.NET (WinForms) sind daher zukunftsicherer, da auch alle anderen .NET-Sprachen damit arbeiten ;)

[Speedmaster]

Winforms sind aber 100% nicht Platformübergreifend, obwohl das IMHO im Moment eh noch schwer ist, eine Platformübergreifende Anwendung zu machen!

[MathiasSimmack]

Was habt ihr nur immer mit diesem "Es ist nicht Plattform übergreifend"-Argument?

Microsoft hat es in erster Linie für die Windows-Plattform konzipiert, und damit ist es sehr wohl Plattform übergreifend. Allerdings steht unter einigen Systemen eben nicht der volle Funktionsumfang zur Verfügung, weil es bspw. einige optische Gimmicks (Transparenz, usw.) nur ab bestimmten Windows-Versionen gibt.

Außerdem arbeiten externe Gruppen an Umsetzungen für Linux und Co., und damit wird es wirklich Plattform übergreifend. Und erst kürzlich hat Phoenix geschrieben, seine .NET-Programme laufen bereits erfolgreich auf Linux- und Mac-Rechnern.

[Michael_Bayer]

Bevor .NET 2.0 UND ein Update nicht da sind, ist .NET eh noch nicht reif.

[MathiasSimmack]

Das sagten die Entwickler sicher damals auch, als sie darüber diskutiert haben, ob es sinnvoll sei, für dieses neumodische grafische System namens "Windows" zu entwickeln. :mrgreen:

[RogerRabbit]

Hi,

Bei Delphi hatte ich Raize, ElPack und sonstige Komponenten. Gibt es etwas vergleichbares in FCL .NET ?
Gibt es gute, sehr gute Komponenten Packages?


Gruss Roger

[Bernhard Geyer]

Zitat:

Zitat von RogerRabbit

Wo liegt den die zukunft von GUI entwicklungen ?

Solche Aussagen können nur Hellseher durchführen.
Vor 10 Jahren hies es: Alles wird Java
Vor 8 Jahren: Alles läuft nur noch im Browser
Vor 6 Jahren: Alles läuft mit XML
....

Du solltest dich lieber selbst ein paar Fragen stellen:
- Ist Win32 für dich noch relevant (.NET erfordert installiertes Framework und diverse BS-Updates)
- Wo soll dein Programm/dein System laufen? PC/PocketPC/Handheld/Embedded?
- Portierbarkeit (Linux/Mac/...)?
- Verteilung (Automatisch, Lauffähig von CD, ...)?

Evtl. ist ja Java noch viel mehr geeigent als VCL oder FCL.

Borland wird es mit der VCL schwer haben, jedoch ist der .NET-Zug auch noch nicht mit der Geschwindigkeit unterwegs die M$ (Marketing) uns glauben gemacht hat. Nach den Aussagen dürfte es ja nur noch .NET geben.
Mit Delphi 2005 und entsprechenden Zusatzkomponenten ist es ja möglich FCL und VCL-Komponenten in einem Formular zu mischen. Auch ist der Zugriff von Win32 (mit Zusatzkomponenten) ohne installierte COM-Wrapper auf .NET-Komponenten möglich.

[RogerRabbit]

Zitat:

- Ist Win32 für dich noch relevant (.NET erfordert installiertes Framework und diverse BS-Updates)
- Wo soll dein Programm/dein System laufen? PC/PocketPC/Handheld/Embedded?
- Portierbarkeit (Linux/Mac/...)?
- Verteilung (Automatisch, Lauffähig von CD, ...)?

Lauffähig unter Windows oder Simbian. Es soll laufen auf dem PC.
Später aber auch auf den anderen Medien.
Das GUI ist ein kleinerer Teil der Applikation. Das look and feel muss siher stimmen
zudem wollen wir nicht VCL .NET einsetzen, wenn es immer wie schwerer wird, dort anständige
Komponenten zu finden.
Evt. Gibt es aber genausogut Argumente gegen FCL .NET. Vorteil von FCL .NET Komponenten ist sicherlich,
dass man sie auch in Visual Studio gebrauchen kann wie auch in delphi.

Java kommt nicht in Frage, das kann ausgeschlossen werden.
Es soll eine .NET Applikation werden, da wir Remoting einsetzen wollen.

Gruss roger

[Michael_Bayer]

Zitat:

Zitat von RogerRabbit

Java kommt nicht in Frage, das kann ausgeschlossen werden.
Es soll eine .NET Applikation werden, da wir Remoting einsetzen wollen.

Gruss roger

Was ist Remoting?

[RogerRabbit]

Hi,

.NET bietet dieses Remoting an.
grob gesagt.
Du hast 2 Rechner, Server/Client. Nun anstatt dass du eine Server applikation machst und eine client,
machst du nur eine Applikation und brauchst Remoting dafür.

Auf dem Server kreierst du ein object client (z.b) und arbeitest auf dem server mit diesem client objekt.
doch alle Aktionen die du machst, werden auf dem client ausgeführt und nicht auf dem server.

z.b clientObj.Shutdown;

Nun wird der client runtergefahren und nicht der Server.

Hmm muss mal die genaue Definition heraussuchen. Ich kenne es auch noch nicht so super genau.


gruss Roger

[jbg]

Zitat:

Zitat von Speedmaster

Winforms sind aber 100% nicht Platformübergreifend

Also WinForms funktioniert schon zum Teil unter Linux mit Mono.
Aber WinForms ist zu 100% obsolute, da .NET 2.0 das WinFX einführt und WinForms schon bevor es herauskam, als Zwischenlösung gedacht war.

[Bernhard Geyer]

Zitat:

Zitat von RogerRabbit

Java kommt nicht in Frage, das kann ausgeschlossen werden.
Es soll eine .NET Applikation werden, da wir Remoting einsetzen wollen.

Remoting auf Basis von Standards (SOAP). Dann ist ja Java eigentlich nicht ausgeschlossen, da es dafür ja auch eine SOAP-Schnittstelle gibt.

[UweR]

@Michael_Bayer

Zitat:

Was ist Remoting?

REMOTING ist quasi die .NET-Version von COM/DCOM

@Bernhard Geyer

Zitat:

Remoting auf Basis von Standards (SOAP). Dann ist ja Java eigentlich nicht ausgeschlossen, da es dafür ja auch eine SOAP-Schnittstelle gibt.

Also wenn schon kein .NET und Java, dann würde ich statt REMOTING Webservices nehmen wenn irgend möglich