Business-Anwendung mit FireMonkey erstellen

[Union]

Und nun zu etwas ganz anderem - dem eigentlichen Thema. Harry schrieb:

Zitat:

Zitat von Harry Stahl (Beitrag 1253887)

Das Programm unterstützt

* DDE zwischen VCL und FMX-Anwendung (direkt, ohne Umweg über VCL-DLL)
* Allgemeine Kommunikation zwischen VCL und FMX
* Explorer-Zwischenablage
* Exportfunktionen (EXCEL, CSV)
* PDF-Anzeige (ADOBE Reader muss installiert sein)
* PDF-Erstellung (über Einbindung eines PDF-Treibers)
* Zwischenablage-Funktionen (Kopieren, Einfangen von Text bei Änderung der ZW-Ablage).
* Dokumente per Scanner einscannen
* Umfangreiche grafische und bilanzielle Auswertungen (Chartfunktionen)

Ich würde es eher begrüßen, wenn Harry hier zu den einzelnen Punkten was sagen könnte.

Wie erfolgt die DB-Anbindung? Wird bereits FireDAC eingesetzt?.

Wo lagen die besonderen Schwierigkeiten der Umsetzung? Wie wurden diese beseitigt? Sind die seit Beginn der Arbeiten bzw. der Umstellung von der VCL-Version inzwischen durch Embarcadero gefixt? Gibt es QC-Einträge - nicht umsonst hat er ja vor einiger Zeit darüber geblogged.

Wurde schon so vorausschauend programmiert dass die Umstellung auf OSX nicht wieder alles über den Haufen wirft? Fragen über Fragen, die mich jedenfalls interessieren würden.

[Bernhard Geyer]

Zitat:

Zitat von rweinzierl (Beitrag 1254239)

...
Ich habe auf dem Rechner in einer VM-Ware eine Testversion installiert und war von der Firemonkey Optik begeistert.
Daraufhin habe ich die erstellte .exe auf dem Laptop direkt gestartet ==> Absturz (und zwar jede Testanwendung)

Ich habe gerade das Rechnungsprogramm auspobiert ==> Das meiste läuft aber wenn ich z.B. links unten mit der Maus über die Schaltfläche fahre dann bekomme ich "Gleitkommadivision durch Null" das gleiche bei neuer Rechnung mit Maus im Register "2 Artikel" über die Combobox "Gleitkommadivision durch Null" ==> Ich vermute es liegt irgendwie an meiner Grafikkarte
==> Bin ich der einzige mit solchen Problemen ?, ich hätte mit FMX im professionellen Einsatz einfach Angst das Kunden mit solchen Effekten anrufen und ich kann nur sagen ==> Sorry kauft euch einen neuen Rechner.

Grafikkartentreiber sind schon ein Gräul. Wir haben hier auch Komponten im Einsatz die 5stellige Lizenzkosten verursachen. Und was man da immer im Bezug auf 3D (Hier primär OpenGL-Schnittstelle) erlegen muss geht auf keine Kuhhaut. Ein Modell ansehen und hunderte GDI/Userobjekte gehen verlustig.
Und wenn's darauf ankommt dann hört man wirklich solche Aussagen wie: "Ihre Grafikkarte ist offiziell nicht unterstützt - Pech gehabt". Und das sind keine "kleine" SW-Firmen wie Emba sondern Mrd-$ Unternehmen.
Oberfläche mit 3D Beschleunigen ist schon eine gute Idee - Aber Frameworkhersteller müssen hier sehr viel Zeit investieren die Bugs der Treiber zu umschiffen.

[Harry Stahl]

Zitat:

Zitat von Union (Beitrag 1254243)

Ich würde es eher begrüßen, wenn Harry hier zu den einzelnen Punkten was sagen könnte.

Wie erfolgt die DB-Anbindung? Wird bereits FireDAC eingesetzt?.

Wo lagen die besonderen Schwierigkeiten der Umsetzung? Wie wurden diese beseitigt? Sind die seit Beginn der Arbeiten bzw. der Umstellung von der VCL-Version inzwischen durch Embarcadero gefixt? Gibt es QC-Einträge - nicht umsonst hat er ja vor einiger Zeit darüber geblogged.

Wurde schon so vorausschauend programmiert dass die Umstellung auf OSX nicht wieder alles über den Haufen wirft? Fragen über Fragen, die mich jedenfalls interessieren würden.

Ich glaube, ich habe irgendwo schon erwähnt, dass ich im Laufe der Woche einen Beitrag in meinem FireMonkey-Blog machen will, quasi als Erfahrungsbericht. Das geht mit meinem Webbearbeitungsprogramm deutlich einfacher, als hier in diesem kleinen Editierfenster (das für sich schon viele tolle Möglichkeiten bietet, aber längerer Text ist etwas anstrengend).

Aber vorab schon mal kurz zu Deinen Fragen (später detaillierter):

* DB ist eine eigene Lösung, es ist einfach eine eigene CSV-Datenbank, die ich z.B. auch in meinem Datenbankprogramm PC-Database verwende (mit zusätzlichen Verwaltungsmöglichkeiten), alle Daten werden in den Arbeitsspeicher geladen.

* Habe am 02.03. mit der Umsetzung angefangen. In der Zeit gab es keine Bugfixes von EMBA, Probleme musste ich leider alle selber mit Workarounds lösen (insbesondere das Tab-Order-Problem, die Alt+Tastenkombination-Problematik und das Aufpoppen von Popup-Menüs oder Dropdownlisten auf dem falschen Monitor auf Multimonitor-Systemen, bzw. jetzt noch nach Euren Hinweisen das Zeichnen der Unterstriche in den Buttons). Ausstehend sind noch die Hints. Ich musste also für 2 Workarounds die Original-FMX.Forms.pas in das Projektverzeichnis kopieren und den FMX-Original-Source-Code ändern. Das hat so gesehen noch verhältnismäßig viel Zeit gekostet. Ich werde die Lösungen dann im Blogbeitrag frei posten.

Das Umwandeln selber ist mehr oder weniger einfach nur "Fließband-Arbeit". Da ist der MIDA-Converter eine große Hilfe, insbesondere, beim Umwandeln erst mal den Source-Code auskommentieren zu lassen, da kann man dann Schritt für Schritt vorangehen und das Programm läuft zu jeder Zeit.

* Ja, ich habe zwischendurch immer mal MAC kompiliert, aber mir gewisse Dinge da noch ausgespart. Lösungen (etwa PDF-Anzeige auf MAC) liegen hier fast alle schon vor, muss ich einfach nur noch implementieren. Habe aber immer an den Stellen, wo ich weiß, da ist Plattform-Code erforderlich, alles mit $IFDEFS versehen. Muss da dann den MAC-Zweig entsprechend ergänzen. Also ja, schon Vorausschauend.

* Was ich jetzt schon sagen kann (ich hatte es befürchtet, wollte es aber mit den EMBA-Grids einfach mal durchziehen): Werde die Grids, wo viele Datensätze drin sind, durch TMS-Grids ersetzen. Die EMBA-Grids sind auf dem MAC einfach zu langsam (Windows geht). TMS-Grids gehen gut und schnell, wenn man die nur virtuell nutzt (mache ich übrigens seit je her nur so) und auch Suche, Filterung und Sortierung selbst übernimmt. Das sollte nicht lange dauern, habe schon Erfahrungen mit dem TMS-Grid unter VCL gesammelt und auch die FMX-Variante schon in meinem Copy Backup-Programm benutzt. Mehr als 4-5 Stunden sollte das Austauschen nicht dauern.

Mehr folgt später...

[rweinzierl]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1254250)

Grafikkartentreiber sind schon ein Gräul. .......
Oberfläche mit 3D Beschleunigen ist schon eine gute Idee - Aber Frameworkhersteller müssen hier sehr viel Zeit investieren die Bugs der Treiber zu umschiffen.

So schön das auch aussieht ==> für mich ist es im Moment das Risiko einfach nicht wert.

Für Plattformunabhängigkeit gehe ich Richtung HTML5 ==> Da hat man zwar auch Probleme aber zumindest kämpfe ich nicht gegen einzelne Grafikkarten.

mfg

Reinhold

[mquadrat]

Vor allem profitiert man bei HTML 5 ungemein von der riesigen Community. Bei FMX ist das ja sehr übersichtlich (gibts überhaupt eine?)

[arnof]

Zitat:

Zitat von mquadrat (Beitrag 1254348)

Vor allem profitiert man bei HTML 5 ungemein von der riesigen Community. Bei FMX ist das ja sehr übersichtlich (gibts überhaupt eine?)

Ja hier.

HTML5 ist schön und gut aber Businessanwendungen ich weiß nicht ob das die richtige Plattform dafür ist. Ja es gibt ein paar Beispiele, die basieren aber auf ASPX oder PHP im Hintergrund nur HTML5 wird wohl nicht reichen!

[Union]

Ich hatte vor ein paar Tagen mal eine Gegenüberstellung verschiedener Möglichkeiten zur Crossplatform-Entwicklung gesehen. Der hatte da auch Screenshots nebeneinander. Die HTML5 sah ziemlich bescheiden aus. Farben stimmten nicht, Buttons waren rund wo sie eckig sein sollten und umgekehrt etc. Da sind die Style-Entgleisungen bei FMX noch ein Lacher.

[nachti1505]

Erstmal Hut ab vor deinem Vorreiterversuch, der anscheinend sogar sehr erfolgreich gelaufen ist (y).

Zitat:

Zitat von Harry Stahl (Beitrag 1254253)

TMS-Grids gehen gut und schnell, wenn man die nur virtuell nutzt (mache ich übrigens seit je her nur so)

Wie ist das gemeint? Wie nutzt man die Grids nur virtuell?

[Union]

Zitat:

Zitat von nachti1505 (Beitrag 1254364)

Wie ist das gemeint? Wie nutzt man die Grids nur virtuell?

Sicher indem man kein DB-Variante verwendet.

[rweinzierl]

Zitat:

Zitat von Union (Beitrag 1254359)

Ich hatte vor ein paar Tagen mal eine Gegenüberstellung verschiedener Möglichkeiten zur Crossplatform-Entwicklung gesehen. Der hatte da auch Screenshots nebeneinander. Die HTML5 sah ziemlich bescheiden aus. Farben stimmten nicht, Buttons waren rund wo sie eckig sein sollten und umgekehrt etc. Da sind die Style-Entgleisungen bei FMX noch ein Lacher.

Hallo

Ein paar Style entgleisungen ==> Damit kann ich irgendwie leben. Gleitkommadivision durch null nur weil ich einen Glimmeffekt auf einer Combobox haben will nicht. (Abhängig von der Grafikkarte)

Ich habe gestern einfach mal Firemonkey und Floating point division by Zero gesucht.
Ich bin offensichtlich nicht der erste mit diesem Problem.

mfg

Reinhold

[Bernhard Geyer]

Zitat:

Zitat von rweinzierl (Beitrag 1254260)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1254250)

Grafikkartentreiber sind schon ein Gräul. .......
Oberfläche mit 3D Beschleunigen ist schon eine gute Idee - Aber Frameworkhersteller müssen hier sehr viel Zeit investieren die Bugs der Treiber zu umschiffen.

So schön das auch aussieht ==> für mich ist es im Moment das Risiko einfach nicht wert.

Für Plattformunabhängigkeit gehe ich Richtung HTML5 ==> Da hat man zwar auch Probleme aber zumindest kämpfe ich nicht gegen einzelne Grafikkarten.

Eigentlich auch. Der IE setzt ja auch auf Grafikbeschleunigung.
Aber das Hauptproblem bei HTML5 ist natürlich die unterschiedlichen Implementierung. Also Chrome, Firefox, IE/Normal, IE/Metro