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

[Chemiker]

Hallo,

ich habe ein Programm das seit ca. 12 Jahren mit kleineren Anpassungen läuft. Jetzt ist der Wunsch geäußert worden das Programm auf WIN 7 / 8.1 anzupassen, es soll diesmal auch eine Modernisierung der Benutzeroberfläche durchgeführt werden.

Jetzt ist die Frage soll es mit der VCL / gekaufte Komponenten, oder mit FireMonkey die Benutzeroberfläche erstellt werden?

Welche Vor- und Nachteile hat die eine oder andere Wahl?

Ich will das hier einfach mal zur Diskussion stellen.

Bis bald Chemiker

[Insider2004]

Du kannst Die Frage mal anders herum stellen: Wie viele FMX Programme gibt es in der freien Wildbahn? Ich würde das Verhältnis auf 99.9 zu 0.1 schätzen.

[Bernhard Geyer]

Definiere erst mal Modernisierung! Was stellst du dir unter eine (für deinen Anwendungsfall) moderne Anwendung vor?

[Bernhard Geyer]

Zitat:

Zitat von Insider2004 (Beitrag 1252082)

Du kannst Die Frage mal anders herum stellen: Wie viele FMX Programme gibt es in der freien Wildbahn? Ich würde das Verhältnis auf 99.9 zu 0.1 schätzen.

Was hast deine Frage mit der anderen Frage zu tun? Versteh jetzt nicht den Zusammenhang zwischen Verbreitungsgrad und "moderne" Anwendung?

[Chemiker]

Hallo,

zurzeit besteht Benutzeroberfläche aus einen Win 2000 Style. Es sollen 2 Varianten geben 32 / 64 Bit Versionen je nach Betriebssystem.

Bis bald
Chemiker

[Bernhard Geyer]

Wenn du "nur" Moderne Farben und Buttons haben willst reicht jede Delphi-Version seit D7 indem du das Theming aktivierst.
Mit neueren Versionen hast du mit den VCL-Styles auch relativ Einfach die Möglichkeit eingen Farbschemen in der Anwendung zu verwenden. Ein Wechsel auf FMX ist hier nicht nötig.

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

[Uwe Raabe]

Zitat:

Zitat von Insider2004 (Beitrag 1252082)

Du kannst Die Frage mal anders herum stellen: Wie viele FMX Programme gibt es in der freien Wildbahn? Ich würde das Verhältnis auf 99.9 zu 0.1 schätzen.

Da fehlt die Vergleichgröße. Bei einem Verhältnis stellt man zwei Werte in Vergleich. Der eine (welcher?) ist wohl die Anzahl ("Wie viele") der FMX-Programme in freiere Wildbahn. Was ist die andere? Vielleicht die Anzahl aller Programme in freier Wildbahn? Wie ist freie Wildbahn definiert?

Wenn man für "freie Wildbahn" den Samples-Ordner von XE5 ansetzt, dann ist das Verhältnis FMX:VCL ca. 196:110 (35 haben kein Framework angegeben).

[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:

Zitat von Insider2004 (Beitrag 1252096)

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.

[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

[mkinzler]

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

[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:

Zitat von Chemiker (Beitrag 1252099)

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:

Zitat von Chemiker (Beitrag 1252099)

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:

Zitat von Insider2004 (Beitrag 1252096)

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?

[Phoenix]

Zitat:

Zitat von Chemiker (Beitrag 1252080)

Jetzt ist die Frage soll es mit der VCL / gekaufte Komponenten, oder mit FireMonkey die Benutzeroberfläche erstellt werden?

Welche Vor- und Nachteile hat die eine oder andere Wahl?

Was ist das für eine Anwendung?
Könnte die Anwendung möglicherweise von Sehbehinderten genutzt werden, die entweder eine Farben-, Kontrastschwäche haben oder ggf. sogar komplett Blind sind und auf eine Braille-Zeile angewiesen sind?

Könnte da auch nur ein "möglicherweise" kommen, ist Firemonkey schon raus. Es passt sich nicht problemlos an alle OS-Einstellungen für Sehbehinderte an und da es keine Systemnativen Darstellungen sind können auch Screenreader nicht auf deren Inhalte zugreifen und diese auf Braille ausgeben oder vorlesen.

[Chemiker]

Hallo,

Das Programm läuft in einem Industrieumfeld, dort arbeiten Menschen bis jetzt ohne körperliche Einschränkungen.

Bis bald Chemiker

[creed steiger]

Citrix/Thin Clients o.ä. sollte man bedenken.
Da könnte es mit FM auch Probleme geben.