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

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