Delphi-PRAXiS - Delphi XE3?

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)

- Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)

- - Delphi XE3? (https://www.delphipraxis.net/167008-delphi-xe3.html)

Zitat:

Zitat von Insider2004 (Beitrag 1179995)

Zitat:

Zitat von jaenicke (Beitrag 1179986)

Zitat:

Zitat von Insider2004 (Beitrag 1179975)

Das ganze Delphi-Konzept beruht darauf, dass GUI und Code stark verdrahtet sind. Deine Betrachtung ist rein theoretisch und mit Delphi nicht zu vereinbaren. Das geht vielleicht in der MFC von MS.

Das geht auch mit Delphi sehr gut. Ich mache das mit Delphi auch. Der GUI-Layer lässt sich so komplett gegen einen anderen Layer austauschen.
Natürlich hat der auch ein gewisses Maß an Logik drin. Aber eben nur so viel wie die GUI benötigt, nichts zu den Daten an sich.

Kannst Du da mal ein Beispiel anhand einer Procedure geben? Kann ich mir nicht vorstellen, wie man den GUI-Layer einfach so austauschen kann.

Wie sollte ein solches Beispiel anhand einer Procedure denn aussehen? Das hat ja nichts mit irgendwelchen Methoden zu tun, sondern mit dem generellen Programmaufbau. Nimm z.B. eine Datenbankanwendung und verlagere die Datenzugriffskomponenten und deren Ereignisse in ein Datenmodul. Nun ist es ein Leichtes, je ein VCL- und FMC-Form zu erstellen, das die Daten in seinen entsprechenden Controls darstellt.

Das Ganze lässt sich auch noch weiter abstrahieren und auf andere Fälle anwenden. Man muss nur konsequent die Programmlogik von der GUI trennen, dann ist ein Austausch der GUI kein Problem.

Da FMX ab XE3 auch Actions unteerstützt, wird ein solches Vorhaben noch einfacher.

Ein Beispiel wäre nett. Gibts kein Opensource-Programm wo das verwirklicht wurde?

Zitat:

Zitat von mkinzler (Beitrag 1180004)

https://radstudiodemos.svn.sourcefor...y/ActionsDemo/

Bräuchte man nur XE3 ;-). Scheinen aber einige hier zu haben (Vermutung).

@MEissing: Ich weiß das ist sicher der falsche Thread, aber ich versuch es dennoch: Das große Problem bei FMX ist wohl die Performance. Ich denke, nachdem ich den FMX Code überflogen habe (mehr als überfliegen ist aufgrund des Umfangs eh nicht drin) ist das Grundproblem die Tatsache das da alle Komponenten über das Canvas gerendert werden. An und für sich mache ich das bei unseren (DirectX) Anwendungen auch, aber ich verstehe die unterirdische Performance nicht. Es ist absolut ein Unding, dass eine simple Listbox bei einem Scrollvorgang dermaßen horrende CPU Auslastungen verursacht. Ein Kernproblem (zumindest bei MacOS) liegt im Rendern von Text. Ohne einen Rasterizer wird das sicherlich nicht besser werden. Ist denn in Zukunft geplant etwas an der Geschwindigkeit zu verbessern?

In Lazarus haben sie das Performance-Problem nicht.

Firemonkey unter Lazarus?

Jetzt kommen wir doch endlich mal zum Kern. Ich finde den Weg, den EMBA geht, richtig und gut. Aber für mich sind LiveBindings und Win8 Support nur halb so wichtig, Mit XE2 wurde mir etwas versprochen, was nicht 100% funktioniert (= FM), Nun folgt XE3 und plötzlich wird aus einem Produkt (iOS Support, wie in XE2 halbherzig integriert) zwei Produkte. Kann ich Delphi selbst noch mit einer SA oder für 500 EUR für das Upgrade abdecken, kommt nun plötzlich ein zweites Produkt mit ins Spiel. Das sieht für mich wirklich nach Schnupperversion in XE2 aus, das ist nicht korrekt, auch wenn das bei EMBA wahrscheinlich niemanden ernsthaft interessiert. Ich kann nur hoffen, dass die Performance von FM2 endlich auf ein halbwegs akzeptables Niveau angehoben wird und die peinlichen Bugs verschwinden ,dann wird das was. Ansonsten könnte es echt peinlich werden. Es ist fast unmöglich mit FM eine Mac Anwendung zu erstellen der man nicht ansieht, dass sie mit Delphi entwickelt wurde. Es ist wie damals VisualBasic: Nicht performant und eher eine Lachnummer. Und ich mag Delphi!

Aber letztendlich kann man nur abwarten was kommt, es dauert ja nicht mehr lange und vielleicht werden wir ja alle eines besseren belehrt.

Zitat:

Zitat von cookie22 (Beitrag 1179952)

Das Problem an FMX ist einfach, dass die Programme weder unter Windows noch unter OS X aussehen wie native Programme.

Ist das nicht mittlerweile irrelevant? Vor allem auf Windows ist das doch mittlerweile sch*** egal. Viele erfolgreiche Programme sind deshalb so erfolgreich weil sie sich nicht strikt an (sich alle 2 Jahre ändernde) GUI-Styleguids halten. Mittlerweile brechen doch praktisch 100% alle Webbrowser z.B. dem dem Styleguid bezüglich Menu/TabControl-Layout.

Zitat:

Zitat von cookie22 (Beitrag 1179952)

Zweitens weiß man leider, wie schnell hochgelobte Technologienen bei Delphi wieder abgeschossen werden. Das haben wir einfach schon viel zu oft erlebt.

Das stimmt leider. CLX/VCL.NET oder generell der Nicht-Oxygen-Pascal-Port.

Zitat:

Zitat von Insider2004 (Beitrag 1179943)

Leider laufen VCLs nicht in FMX. Das Interface ist unnötigerweise völlig inkompatibel. ... das teilweise OnShow oder OnClick events fehlen bei manchen Komponenten.

WOW. 2 Fehlende Events bedeuten völlig inkompatibel.

Zitat:

Zitat von Insider2004 (Beitrag 1179943)

Es ist unmöglich seinen VCL code da irgendwie zu portieren.

WEnn du allein schon bei solchen Kleinigkeiten scheiterst ist m.E. der Beruf eines SW-Ingenieurs/Entwicklers eine falsche Wahl.

Zitat:

Zitat von Insider2004 (Beitrag 1179943)

Ein anderes Beispiel ist z.b. dass aus .Caption plötzlich .Text wurde.

Solche Änderung ist doch gut. Endlich hat man eine einheitliche Bezeichung für so ein Element und muss bei generischer Implementierung nicht Ständig zwischen Caption/Text und wer weiß sonst noch unterscheiden. Und man muss nicht jedesmal umstellen wenn man auch mit der .NET oder Java-Welt zu tun hat.