Win 7 / Win 8 Entwicklung mit VCL oder mit FireMonkey?

[jaenicke]

Die Frage ist eher was das für ein Programm ist. Denn wenn man nur Standardkomponenten und nur Windows benötigt, braucht man Firemonkey auch nicht um eine schöne Oberfläche zu bauen.
Wenn es aber darum geht etwas zu visualisieren usw., kann man mit Firemonkey sehr viel machen, das mit der VCL nicht so einfach geht.

Ansonsten ist es bei einem guten UI Design eher wichtig sich an den Designrichtlinien zu orientieren usw., so dass die Anwendung nicht wie ein Fremdkörper wirkt.

[Harry Stahl]

Wenn die Aktualisierung wirklich nur für Windows sein soll und Dein Programm nicht irgendwelche speziellen Features benötigt, die man DEUTLICH besser oder NUR mit FireMonkey machen könnte, dann solltest Du bei der VCL bleiben.

Denn die Umwandlung von VCL zu FMX ist gar nicht so einfach, wenn man mit FMX gerade die ersten Erfahrungen sammelt. Wenn man das ein paar mal gemacht hat, dann geht es zwar flott (mal als Richtschnur: z.B. ein 100.000 Zeilen Programm mit 50 Formularen in einer Woche auf FMX umstellen), aber als Einsteiger ist es erst mal ein ziemlicher Aufwand. Und ohne Mehrwert (MAC oder mobile Plattformen) würde ich mir das nicht antun (bei aller Liebe zu FMX ).

Und mit den aktuellen Delphi-Versionen kannst Du auch attraktive VCL-Oberflächen mit Nutzung von Styles schaffen.

Davon unabhängig würde ich mich aber mit FMX vertraut machen, denn das ist die Öffnung für andere Märkte (MAC, mobile Plattformen) und gerade der Trend zu mobilen Anwendungen ist ungebrochen.

[fred.ahrens]

Ohne Erfahrungen mit FMX bereits zu haben, würde ich keine bestehende Anwendung darauf umstellen. Sobald man die auf FMX umgestellte Anwendung im Markt hat, kann der Supportaufwand sehr schnell recht hoch werden - vor allem wenn es eine Anwendung ist, die auch auf älteren Systemen zum Einsatz kommt. FMX-Anwendungen neigen leider manchmal zu Grafikfehlern in der Oberfläche. In der Regel kann man solchen Fehlern dann nur auf die Spur kommen, wenn man die Fehleranalyse direkt beim Kunden durchführen kann. Ein Nachstellen dieser Fehler ist auf den eigenen Testsystemen in vielen Fällen leider kaum möglich. Mit etwas Erfahrung kann man diese Fehler vermeiden, aber diese Erfahrung muss man erst einmal sammeln.

Wenn die Anwendung nur im Windowsumfeld zum Einsatz kommen soll, gibt es aber auch mit der VCL viele sichere und erprobte Verfahren und Komponenten, mit denen man eine vorhandene Anwendung modernisieren kann. Wir fühlen uns z.B. mit dem Einsatz der Komponenten von DevExpress immer auf der sicheren Seite.

Es darf auch nicht der Aufwand unterschätzt werden, den die Umstellung einer normalen (VCL)-Anwendung auf Windows 7/8-Kompatibilität darstellen kann. Allein wenn es darum geht, die Dateien nur noch in den Verzeichnissen abzulegen, in denen man auch als normaler Nicht-Admin damit arbeiten kann, muss man hier schon einige Zeit investieren.

Wenn langfristig die Anwendung auch auf anderen Systemen angeboten werden soll, dann geht das nur über FireMonkey. In einer idealen Welt würde man vorher in der Anwendung eine saubere Trennung von Code und Oberfläche vornehmen - im ersten Schritt mit der VCL eine verkaufsfähige modernere Variante entwickeln und parallel dazu mit FireMonkey eine zweite Oberfläche, die dann später auch für andere Betriebssysteme genutzt werden kann. Wenn FireMonkey dann sauber läuft, kann man sich von der VCL verabschieden, ohne den bisherigen Windowsmarkt zu verlieren.

Fred

[Insider2004]

Kann mir mal jemand bitte erklären, wie dieses viel besungene Trennen von Code und Oberfläche geht? Ist ja schon blöd, wenn man nicht mehr sieht, was der Code ausgerechnet hat (Spass). Sollen die Events jetzt per Rauchzeichen den Code triggern?

[Bernhard Geyer]

Zitat von Insider2004:

Kann mir mal jemand bitte erklären, wie dieses viel besungene Trennen von Code und Oberfläche geht? Ist ja schon blöd, wenn man nicht mehr sieht, was der Code ausgerechnet hat (Spass). Sollen die Events jetzt per Rauchzeichen den Code triggern?

Bitte nicht hier Diskutieren!
Diese Trennung der Programmlogik und GUI wirde gefühlt 2-3* pro Woche in einer Diskussion ausführlich behandelt. Wenn du Fragen dazu hast stelle sie als eigene Thread oder schau in den anderen Thread nach.

[mkinzler]

Denn der Sinn der Trennung besteht egal ob man VCL, FMX, WinAPI (nonVCL), CLX oder etwas anderes verwendet.

[Chemiker]

Hallo,

das Programm wird nur für Windows entwickelt, für ein anderes Betriebssystem sehe ich zurzeit kein Bedarf.

Und wenn ich die Antworten jetzt grob zusammenfasse, ist bei einer reinen Windows Umgebung immer noch die VCL erste Wahl.

Bis bald
Chemiker

[michaelthuma]

Dann bleibe bei der VCL. FMX wenn er wesentlich besser funktioniert als jetzt möglw. noch spannend für GUI Anwendungen die neu geschrieben werden.

Zitat von Chemiker:

Hallo,

das Programm wird nur für Windows entwickelt, für ein anderes Betriebssystem sehe ich zurzeit kein Bedarf.

Und wenn ich die Antworten jetzt grob zusammenfasse, ist bei einer reinen Windows Umgebung immer noch die VCL erste Wahl.

Bis bald
Chemiker

[Bernhard Geyer]

Zitat von Chemiker:

Und wenn ich die Antworten jetzt grob zusammenfasse, ist bei einer reinen Windows Umgebung immer noch die VCL erste Wahl.

Sagen wir so: Du hast bestehende Anwendung. Diese soll primär nur "Aufgehübscht" werden. Eine "Aufhübschung" auf Basis des schon verwendeten GUI-Frameworks wird um Welten einfacher sein als jetzt ein anderes GUI-Framework einzusetzen.

[michaelthuma]

Nein. Aber der Code in den Eventhandlern sollte übersichtlich bleiben und nicht zu lange werden. Ein handvoll Zeilen aus denen klar hervorgeht was passiert. Klassen eignen sich an sich recht gut die Daten zu kapseln. Ich persönlich arbeite sehr viel Bottom Up.

Ich habe sehr selten verwendet Data Binding. Mein Ansinnen war einfach die reinen Windows Controls zu verwenden.

Einfach Collections aufgebaut oder ein respräsentatives Objekt über einen Dataset gelegt. Das bedingt die Generierung des Data Access Layers. Aber auch nicht mehr. Man fängt damit Datenfehler sehr bald und man kommt mit einem TQuery Objekt durch. Damit macht das Rumpfrimmeln in den Eventhandlern kaum Sinn. Damit bügelt man so 95% der lästigen unerwarteten Fehler. Das ganze geht noch dazu ganz gut in Funktionen. Wenn man sich viel an Funktionen hält bekommt man relativ sauberen Code. Der hat keine Side Effekts. Ein Funktion weiß an sich vom Form nichts aber auch gar nichts. Prozedurtypen als Parameter sind genausowenig verboten.

Ich kann mir jetzt mal für diese Art von Applikation nicht den wirklichen Nutzen von einem reinen MVC vorstellen. Ich kann mir den Nutzen bei vielen anderen Anwendungsfällen vorstellen, das Wohl.

Zitat von Insider2004:

Kann mir mal jemand bitte erklären, wie dieses viel besungene Trennen von Code und Oberfläche geht? Ist ja schon blöd, wenn man nicht mehr sieht, was der Code ausgerechnet hat (Spass). Sollen die Events jetzt per Rauchzeichen den Code triggern?