Win32 oder .NET; VCL.NET oder WinForms ?

**tommikko**

Hallo,
wir besitzen in unserem Betrieb Delphi2005. Ich beginne gerade ein neues Projekt und bin ziemlich ratlos mit welcher Delphi-Variante ich nun dieses Projekt entwickeln soll.
Soll ich weiterhin bei dem alt-vertrauten Delphi2005 für Win32 bleiben (dort habe ich alles, was ich unter Delphi7 auch hatte, ich muss nichts neues dazulernen)?
Oder soll ich auf Delphi.NET umsatteln? Hier ist einiges anders, andere Komponenten mit anderen Namen/Eigenschaften usw. Angeblich soll es aber doch die Zukunft sein, da Windows Vista auch auf .NET aufbauen wird. Allerdings finde ich, insbesondere, wenn ich WinForms verwende, nur noch grundlegende Komponenten wieder und längst nicht mehr die reiche Auswahl, die ich in Win32 hatte. Oder soll ich dann VCL.NET verwenden, hier sind wieder einige Komponenten mehr zu finden.

Werden Programme, die jetzt mit Delphi Win32 entwickelt werden, auch in zukünftigen Windows-Versionen (VISTA) laufen? Könnte ich demnach ohne Bedenken bei Win32 bleiben (was mir am liebsten wäre)?

Eine Menge Fragen. Ich bin ziemlich ratlos und stehe hier vor der Qual der Wahl.
Ich wäre Euch dankbar wenn dazu Tipps/Ratschläge habt.
Vielen Dank im voraus.
Herzliche Grüße
Tommikko

**RWarnecke**

Hallo und ein herzliches Willkommen in der Delphi-Praxis.

Nun zu Deinem anliegen. Ich habe auch schon einen kleinen Ausflug in die Welt von .NET gemacht. Es ist vieles anders. Ich persönlich mach es im Moment davon abhängig, was ich programmieren will. Ist es ein Programm, was nicht allzu viele Komponenten braucht, dann probiere ich es in .NET zuschreiben. Das hat bis jetzt nie so richtig geklappt, da ich nie genügend Zeit hatte. Deshalb schreibe ich bis jetzt immer noch meine Programme im alten bewährten Stil. Meine persönliche Meinung zu .NET ist, es ist noch nicht so weit verbreitet und noch nicht ganz ausgereift. Desweiteren solltest Du immer dabei bedenken, dass Du auf jedem Rechner der Dein .NET-Programm ausführen soll, das .NET Framework Redistributable (ca. 25 MB Speicherplatz) oder sogar das .NET Framework SDK (so um die 100MB Speicherplatz) brauchst. Das alles hält mich im Moment noch davon ab, komplett auf .NET umzusteigen.

**Phoenix**

Zitat von tommikko:

Werden Programme, die jetzt mit Delphi Win32 entwickelt werden, auch in zukünftigen Windows-Versionen (VISTA) laufen?

Vista: Sehr Wahrscheinlich ja, aber nicht zwingend garantiert.
Spätere Windows-Versionen: Wahrscheinlich (oder mit ziemlicher Sicherheit) nicht.

Da für die VCL.NET angekündigt wurde, dass diese später auch für Avalon (Windows Presentation Foundation) verfügbar sein wird ist anzunehmen, dass für neue Applikationen, die auch über Jahre hinaus gewartet werden müssen, die VCL.NET Stand Jetzt die richtige Entscheidung ist.

**hanspeter**

Zitat:

RWarnecke schrieb:
Meine persönliche Meinung zu .NET ist, es ist noch nicht so weit verbreitet und noch nicht ganz ausgereift.

Das ist so natürlich nicht richtig.
Was nicht ausgereift ist, ist D2005/D2006.
Der technologische Rückstand von mehr als einem Jahr zwingt Delphientwicklern das Netframework 1.1 auf.
Dafür mag die Aussage stimmen.
Stand der Technik ist Net2.0 und mit den dafür geeigneten Werkzeugen macht das ganze schon einen ausgereiften Eindruck.
(Wenn Delphi dann 2.0 kann, wird 3.0 in der Einführungsphase sein.)

Win32 wird so schnell nicht verschwinden. (Siehe DOS)
Zumindest nicht im nächsten und übernächsten Windows.
Wenn MS anfängt seine Flagschiffe Word,Access,Excel auf Net umzustellen, dann kann man ebenfalls über eine Umstellung nachdenken.
Dafür sollten wohl > 5 Jahre ins Land gehen.
WinFX wird wohl ebenfalls ein Umstellungsgrund sein.
Mein Vorschlag: Wenn es ein kleineres oder kein langlebiges Programm ist, dann auf Delphi Win32 aufsetzen.
Ebenso, wenn es nur betriebsintern genutzt wird.
Soll es ein größeres Projekt, mit einen zu erwartenden längeren Einsatzeitraum werden, dann würde ich entweder bis Mitte des Jahres abwarten, wie es mit Delphi überhaupt weitergeht und ob es hier überhaupt eine professionelle Alternative ist.

Ist diese Zeit nicht vorhanden, dann würde ich auf Net2.0 aufsetzen. Hier ist allerdings der Wechsel des Entwicklungssystems angesagt.
Meine Erfahrungen mit VS2005.
Etwas träger als Delphi. Macht aber einen weniger buggigen Eindruck. Ist vollständiger und bringt mehr Funktionalität
für das gleiche Geld.
Und der wichtigste Vorteil von VS2005: ES HAT EINE FUNKTIONIERENDE HILFE!

Gruß Peter

**RWarnecke**

Zitat von hanspeter:

Das ist so natürlich nicht richtig.
Was nicht ausgereift ist, ist D2005/D2006.
Der technologische Rückstand von mehr als einem Jahr zwingt Delphientwicklern das Netframework 1.1 auf.
Dafür mag die Aussage stimmen.

So meinte ich das auch. Mit 2.0 habe ich noch nicht richtig gearbeitet.

Zitat von hanspeter:

Ist diese Zeit nicht vorhanden, dann würde ich auf Net2.0 aufsetzen. Hier ist allerdings der Wechsel des Entwicklungssystems angesagt.
Meine Erfahrungen mit VS2005.
Etwas träger als Delphi. Macht aber einen weniger buggigen Eindruck. Ist vollständiger und bringt mehr Funktionalität
für das gleiche Geld.
Und der wichtigste Vorteil von VS2005: ES HAT EINE FUNKTIONIERENDE HILFE!

Nur hier fehlen mir irgendwie die ganzen Komponenten, die ich auch unter Delphi habe. Ich habe zwar nur die VS2005 ExpressEdition. Ich weiß nicht wie es bei einer anderen Version aussieht. Denn ich stehe im Moment vor der Entscheidung, stecke ich das Geld in eine Delphi 2006 Version oder nehme ich eine andere. Mit C# habe ich schon ein bisschen programmiert und fand es eigentlich recht leicht zu lernen, wenn man vieeeellll Zeit reinsteckt. Nur möchte ich keine Freeware anbieten, wo ich dem User erstmal den Download von NET Framework 1.1 oder 2.0 anmuten muss.

Was würdet Ihr machen ? Euch eine neue BD2006 kaufen oder eine VS2005 ?

**hanspeter**

Zitat:

Was würdet Ihr machen ? Euch eine neue BD2006 kaufen oder eine VS2005 ?

Das ist wie die berühmte Frage, was war eher da "die Henne oder das Ei".

Ich würde die Frage einzig und allein an den vorhandenen Altlasten aufhängen.
In meinem Fall sieht es z.B. so aus, dass ich eine Unmenge "alten" Code habe und ein produktives Programm von über 1 Mio.
Quellzeilen pflege. Das stellt man nicht so ohne weiteres eben mal auf Net um.
Hier werde ich wohl noch eine Weile bei Delphi bleiben. Dazu reichen aber auch die Möglichkeiten von Delphi 7 respektive D2006.
Neuentwicklungen setze ich aber nicht mehr in Delphi auf.

Wer sich das Net-Framework anschaut sieht eigentlich deutlich das VCL und Net den gleichen Vater haben.
Schaut man in die Vergangenheit, so stagniert die Delphientwicklung eigentlich seit dem Ausscheiden von Anders Hejlsberg.
Ich hatte das schon mal geschrieben. NET ist die Neuentwicklung der VCL ohne alte Zöpfe und mit einem moderneren Sprachkonzept.
Also entscheide selbst, NET dürfte aber insgesamt zukunftsicherer sein und mit VS läufst du nicht jeder Entwicklung um etwa ein Jahr hinterher.
Neben C# ist übrigens VB auch eine interessante Sprache.
Sie hat nicht mehr viel mit der "alten Frickelsprache" VB gemeinsam.
SUN hat übrigens gerade angekündigt, VB für Java zu öffnen und Java Bytecode zu erzeugen.
Mit Mono ist der Weg nach Linux offen.
ASP ist so gut geworden, das es langfristig PHP oder ähnliches an den Rand drängen kann.
Wobei ich davon ausgehe, das es bezüglich der Lauffähigkeit von W32 Programmen unter nachfolgenden Betriebssystemen für die
nächsten 5 bis 10 Jahre kaum Probleme geben wird.
Sie werden lediglich etwas altbacken aussehen, da modernere Verfahren nicht nutzbar sind.
Das haben wir aber mit Delphi heute schon. Viele Komponenten wirken etwas altbacken und angestaubt und interessieren sich z.B. für XP-Themes oder Unicode überhaupt nicht.

Gruß Peter

**Elvis**

Zitat von hanspeter:

Ich hatte das schon mal geschrieben. NET ist die Neuentwicklung der VCL ohne alte Zöpfe und mit einem moderneren Sprachkonzept.
...
Wer sich das Net-Framework anschaut sieht eigentlich deutlich das VCL und Net den gleichen Vater haben.
Schaut man in die Vergangenheit, so stagniert die Delphientwicklung eigentlich seit dem Ausscheiden von Anders Hejlsberg.

Dass Autos runde Räer haben ist keine Hommage an Eckbert, den trickreichen Nendertaler[1], es ist einfach ein Design, das sich praktisch aufdrängt.
Das gleiche gilt für BCL/FCL vs. Delphi RTL/VCL. Es gibt nunmal bestimmte Widgets in der Win32 API, und das ein Fenster einen Text, ListBox/ComboBox Strings als Items und ListView mehrere Spalten, Icons und Ansichten hat dürfte wohl auch schon jeder gemerkt haben.
Außerdem hat Hejlberg nach der VCL die MFC verbrochen, demnach...
Wo SWF/WPF und die VCL auseinandergehen ist die Architektur hinter dem "Drag'nDrop-uff'm Designer-Geklicke".
Die VCL steht technisch noch da wo sie in der Uraufführung stand: Sie ist immer noch nicht interface basiert.
SWF/WPF/ASPX teilen sich eine Menge Interfaces, die entweder den Designer (IExtenderProvider,IComponent,IContainer), oder das extrem mächtige und (mit krüppligen DataSets) oftmals extrem unterschätzte DataBinding aufmöbeln.
Für DataBinding gibt es Dinge wie

IEditableObject
IChangeTracking
ICancelAddNew
INotifyPropertyChange
IDataError
IBindableComponent
IListSource (sehr interessant für alle, die DataModules hinterhertrauern )
IBindinglist

Die Liste ist keinefalls vollständig sonder nur das womit ich oft zu tun habe.
Was ist an interface-basierter API anders?
Du kannst jede beliebige Klasse hernehmen und sie zu einer Komponente machen, die du auf einen Designer werfen kannst (auf alle 3 GUI Frameworks UND auf WebServices/WinServices/Komponenten).
Du kannst jede Klasse zu einer Datenquelle aufbohren, die ihrerseits mehrere Datenquellen veröffentlicht (IListSource) und du kannst die UI über Änderungen deiner Daten informieren (INotifyPropertyChange), Fehler direkt an Ort und Stelle melden (IDataError) oder auf ein [Esc] reagieren (ICancelAddNew/IEditableObject).
Wer in .Net noch irgendwelche ChangeEvents irgendwelcher Controls abfängt um sein Model mit dem View zu synchronisieren (und vice versa) hat entweder einen wirklich trifftigen Grund dafür oder er reduziert DataBinding auf "krüppelige DataSets"(TM).

Man darf aber auch nicht die Kehrseite der Medaille vergessen: SWF basiert auf GDI+.
GDI+ mag eine sehr mächtige und einfache API sein um schöne Dinge wie Gradienten, Transparenzen & Co auf den Schirm zu zaubern, ABER GDI+ hat fast keinen Hardware support.

Die Folge ist, dass man jedem SWF Fenster beinahe zusehen kann, wie es sich auf den Schirm zeichnet.[2]
Ehrlich gesagt bin ich deshalb fast jedesmal wenn ich eine meiner Apps öffne, ein kleines bisschen mehr angepisst...

Zitat:

Neben C# ist übrigens VB auch eine interessante Sprache.

Na pfui Deivel aber auch!

Zitat:

Sie hat nicht mehr viel mit der "alten Frickelsprache" VB gemeinsam.

Richtig, wenn man einer Sprache, die absolut ungeeignet für OO ist OO aufquetscht bekommt man eine "neue, bessere Frickelsprache". VB.Net gehört zu den widerlichten Dingen, die MS in den letzten 10 Jahren angestellt hat.
Dieses Biest unterläuft die statische Typensicherheit, die Pascalisti seit jeher zu schätzen wussten (und die seit C#/Java auch den c-ischen Sprachen zugute kommt) auf eine so kranke Weise, dass man ernsthaft am Geisteszustand der Erschaffer zweifeln muss.
In VbNet kannst du stets und ständig late binding benutzten. Wer den kleinen Fakt kennt, dass dynamic invokes so ziemlich das langsamste sind, dass .Net zu bieten hat, bekommt wohl jedesmal Panikzustände, wenn der den IL Code eine typischen Vb.Net-Fricklers lesen muss.

Es gibt für's VS zumindest eine weitere Sprache, die ich als sehr nett empfinde. Aber da muss ich wohl nicht genauer werden.

[1] ihr wisst schon, der der das Rad erfand...

[2]einfach mal ein Fenster vor einem SWF Fenster Fenster bewegen. Besonders krass wird's wenn du dort einen DataGridView hast.

puh.. genug philosülziert für heute....:tupid:

**hanspeter**

Zitat von Elvis:

Außerdem hat Hejlberg nach der VCL die MFC verbrochen, demnach...

Sorry aber das halte ich für ein übles Gerücht.
Es wurde versucht Java für MS Zwecke zu inhalieren.
Nachdem Sun einen Prozess gewonnen hatte, hat MS Net aufgelegt.
Zu Zeiten von Delphi 1 bzw. Turbopascal für Windows habe ich mich mal mächtig über die MFC geärgert.
Damals habe ich den Betrieb gewechselt.

Gruß Peter

**SvB**

Hi,

vielleicht ist auch die "Erweiterung" Chrome

http://www.chromesville.com für VS etwas. Man muss dann wenigstens von der Sprache her nicht viel umlernen. Habe zwar noch nichts damit gemacht, bin aber auch im Moment am überlegen, wie ich meine zukünftigen Projekte entwickeln will. Zur Zeit habe ich das Problem, dass ich die .NET Componente Transport von ComponentScience testen will und diese in Delphi 2006 einen Fehler verursachen, wenn ich sie auf ein Formular ziehen will, bzw. hat mit Sicherheit Delphi das Problem. Ich denke in VS gibts die Probleme nicht.

Grüße
Sven

**Luckie**

Zitat von Phoenix:

Vista: Sehr Wahrscheinlich ja, aber nicht zwingend garantiert.

Nicht sehr wahrscheinliuch, sondern ganz bestimmt. Microsoft könnte es sich nie leisten native Win32 Programme nicht mehr zu unterstützen.

Zitat:

Spätere Windows-Versionen: Wahrscheinlich (oder mit ziemlicher Sicherheit) nicht.

Wie viele Windows Versionen später? 16-Bit Programme leifen noch unter 95, 98, ME, NT, 2000, XP also noch rund 20 Jahre nach deren Einführung. 32-Bit Programme werden bestimmt noch unter nächsten Windows Version unterstützt.