Business-Anwendung mit FireMonkey erstellen

**Uwe Raabe**

Ok man kann dann auch OSX für Desktop Anwendungen. Aber die sehen weder unter Win noch Mac so aus wie sie sollten. Keine acceleratoren auf den Buttons, falsche Fonts, falsches Verhalten, nicht behinderten gerecht, laufen nicht gut unter Terminalserver etc.

Delphi 7 Anwendungen laufen soweit ich weiß gar nicht unter OSX.

Ich verstehe überhaupt nicht, warum man hier krampfhaft versucht, Harry's Leistung klein zu reden oder sogar als kontraproduktiv zu deklassieren. Immerhin hat er aus eigener Kraft deutlich mehr geschafft als so manch anderer

**stahli**

Kleinreden will ich die Leistung keinesfalls (ich finde das Ergebnis bewundernswert) und kontraproduktiv muss ich vielleicht begründen:

Ich denke, Harrys Leistung trägt dazu bei, dass sich Emba auf dem aktuellen Stand noch eher ausruht und FMX als Super-Framework lobpreist.

Harrys Leistung ist beeindruckend, keine Frage. Aber der Weg zum Ziel ist lange nicht so unkompliziert wie das mit Einführung von FMX suggeriert wurde. Die inakzeptable Preispolitik kommt hinzu.

Fazit für mich: Auch wenn man mit Klimmzügen zu einem durchaus respektablen Ziel kommt führt das für mich nicht mehr dazu, dass ich die Entwicklungsumgebung wirklich ernst nehmen kann.

Besser wäre gewesen, Emba hätte sich die Zeit genommen, das Ganze nochmal neu und mit ordentlicher Qualität anzugehen.

**Harry Stahl**

Lieber Uwe, erst mal danke für Deinen Beistand hier.

Aber keine Sorge, ich habe Stahli (oder einen anderen) nicht so verstanden, dass er meine Leistung schmälern wollte. Stahli hat ja auch jetzt noch mal genauer erklärt, wie er es meinte.

Ich muss Stahli aber entgegnen, dass die Lösungen EUCH helfen sollen oder sagen wir mal, den Leuten, die in einer ähnlichen Situation sind wie ich und praxistaugliche Cross-Plattform-Lösungen abliefern müssen. Ich glaube auch nicht, dass sich EMBA wegen MIR bzw. der Workarounds weniger anstrengen wird, das Produkt zu verbessern.

Ich finde auch die Hinweise von Union wichtig in dem Sinne, dass man die Probleme kennt und dann daran arbeiten kann. Wäre ja auch nicht so gut, wenn erst der Kunde mir etwas berichtet, was nicht geht.

Noch etwas wichtiger finde ich aber, dass man sich dann auch um Lösungen kümmert. Am Ende möchte ich hören, WIE ES GEHT und nicht immer nur, dass etwas nicht geht.

**Harry Stahl**

Zitat von Union:

Ok man kann dann auch OSX für Desktop Anwendungen.

Sagen wir mal so: Kein geringerer als der Hersteller von OSX selber, also

Apple sagt: "Ja" FMX Anwendungen gehen für den MAC-Desktop.

Denn Apple hat sowohl meine und die FMX-Anwendungen von anderen Herstellern in den App-Store genommen.

**Stevie**

Zitat von Harry Stahl:

Zitat von Union:

Ist das Programm auch mit der Tastatur bedienbar?

Hmmh, seltsame Frage. Kann man natürlich nur mit "Ja" beantworten, würde nie auf die Idee kommen, ein Programm zu vertreiben, wo das nicht so wäre.

Dem muss ich mal widersprechen. Wenn ich Alt drücke, komme ich nicht ins Menü wie unter Windows üblich. Außerdem haben die einzelnen Menüeinträge keine Mnemonics. Ob das ein FMX Makel ist oder von dir nicht berücksichtigt, weiß ich nicht. Auch in den einzelnen Eingabefenstern kann ich nicht mit nem Shortcut eine Seite weiter oder sowas (fehlende Accelerators auf den Buttons bzw fehlende Shortcuts auf den Actions dahinter).

Zitat von Harry Stahl:

mit FireMonkey auch echte Business-Anwendungen erstellen kann, bin ich so frei und poste hier mal einen Video-Link auf mein soeben veröffentlichtes Rechnungsprogramm PC-Rechnung 3.0. Ich denke, ein Rechnungsprogramm kann man ja wohl als klassische Business-Anwendung bezeichnen.

Hier möchte ich hinzufügen, dass wir uns hier eher am unteren Ende der Business-Anwendungen befinden. Die Anwendung ist in ihren Funktionen doch sehr überschaubar. Ob du noch so von FMX begeistern wärst, wenn du mal ne große ERP oder sowas damit bauen müsstest, weiß ich nicht. Auch kann ich ohne erstmal stundenlang irgendwelche Artikel und Rechnungen ins System zu tippern nicht sagen, wie die Anwendung sich mit vielen Daten verhält. Denn genau da liegt oft der Hase im Pfeffer - ok, ohne LiveBindings wirst du immerhin nicht das Problem haben, dass du nur 300 Datensätze durchscrollen kannst, was wir hier in einem anderen Thread hatten. Und auch das träge Scrollen einiger Controls mit vielen Daten.

Zitat von Uwe Raabe:

Ich verstehe überhaupt nicht, warum man hier krampfhaft versucht, Harry's Leistung klein zu reden oder sogar als kontraproduktiv zu deklassieren. Immerhin hat er aus eigener Kraft deutlich mehr geschafft als so manch anderer

Harry ist der MacGuyver des FireMonkey - mit nem Kaugummi, ner Büroklammer und nem Schweizer Taschenmesser bekommt er es zum Laufen.

Aber mal im Ernst, wenn man erst noch sämtliche Bugs im Framework ausbügeln oder Workarounds anwenden muss, ist das wohl kaum "rapid". Und schon gar nich ++.

Übrigens noch nen kleiner Bugreport: Wenn ich im Rechnungsfenster nur einen Namen eingebe und dann auf Weiter klicke, kommt "Listenindex überschreitet das Maximum (-1)" was an der nicht ausgefüllten Bestellart Combobox liegt. Außerdem aktivieren sich die Fertig Buttons, wenn ich oben auf das Tab Angebot wechsle.

**bernau**

>Livebindings<

Hier muss ich mal wieder meinen Senf dazu geben. So viel ich auch darüber nachdenke, ich kann damit nichts anfangen. Das einzige was ich visuell mache, sind Komponenten auf der Form oder dem Frame plazieren, die man zur Laufzeit auch sieht. Alles andere "programmiere" ich. Ob es Dialoge sind, Datenbankkomponenten, Internetsachen oder sonstige "nicht Visuelle" Komponenten. Alles wird bei mir "created" und "destroyed". Ich finde Quellcode viel übersichtlicher als den Objektinspektor.

Warum sollte ich Livebindings verwenden? Bei 4-5 Tabellen kann man vieleicht noch die Zuordnungen erkennen. Bei richtig komplexen Dingen verliert man doch total den Überblick. Oder?

Ich muss immer wieder den Kopf schütteln, wenn ich bei den Delphitagen zum Hundertsten mal von David.I oder sonstigen Emba-Leuten zu hören bekomme, was alles mit "einer einzigen Zeile Quellcode" gemacht wurde. Klar, der Rest wurde geklickt und nimmt auch Zeit in Anspruch. Was ist daran so schlimm, auch mal 10 oder 20 Zeilen zu schreiben und dafür weniger zu klicken. Ich bin doch Programmierer und kein Klicker.

Das musste mal gesagt werden.

**mkinzler**

Nichtsdestotrotz sollten LiveBindings aber funktionieren; was sie leider nicht richtig tun.

Man sieht, dass FMX grundsätzlich für "richtige" Anwendungen verwendbar ist, wenn auch noch viele Stolpersteine und Unzulänglichkeiten bestehen.

Btw. finde ich es nicht "kontraproduktiv" eigene Fehlerbereinigungen/Alternativlösungen zu schaffen!
Auh wird dies in keinster Weise beeinflussen, ob und welche Fehler von EMBT ignoriert/korrigiert oder als as-designed betrachtet werden.

**Stevie**

Zitat von bernau:

>Livebindings<

Hier muss ich mal wieder meinen Senf dazu geben. So viel ich auch darüber nachdenke, ich kann damit nichts anfangen. Das einzige was ich visuell mache, sind Komponenten auf der Form oder dem Frame plazieren, die man zur Laufzeit auch sieht. Alles andere "programmiere" ich. Ob es Dialoge sind, Datenbankkomponenten, Internetsachen oder sonstige "nicht Visuelle" Komponenten. Alles wird bei mir "created" und "destroyed". Ich finde Quellcode viel übersichtlicher als den Objektinspektor.

Warum sollte ich Livebindings verwenden? Bei 4-5 Tabellen kann man vieleicht noch die Zuordnungen erkennen. Bei richtig komplexen Dingen verliert man doch total den Überblick. Oder?

Ich muss immer wieder den Kopf schütteln, wenn ich bei den Delphitagen zum Hundertsten mal von David.I oder sonstigen Emba-Leuten zu hören bekomme, was alles mit "einer einzigen Zeile Quellcode" gemacht wurde. Klar, der Rest wurde geklickt und nimmt auch Zeit in Anspruch. Was ist daran so schlimm, auch mal 10 oder 20 Zeilen zu schreiben und dafür weniger zu klicken. Ich bin doch Programmierer und kein Klicker.

Das musste mal gesagt werden.

Livebindings sind mMn einfach falsch designed - das liegt daber nunmal daran, dass in Delphi irgendwie immer alles RAD sein muss, Komponente auffe Form, klick klack, bämm, F9, läuft. Dass das aber auch anders geht, weiß jeder, der schonmal eine WPF Anwendung erstellt hat. Da macht man halt weniger klick klack, sondern mehr tipp tipp im XAML Code aber das läuft auch - mit dem schönen Zusatz, dass dir der Compiler direkt den Finger zeigt, wenn du da Grütze zusammen gebunden hast und nicht erst zur Laufzeit einfach nix oder was falsches angezeigt wird.

**Harry Stahl**

Zitat von Stevie:

Dem muss ich mal widersprechen. Wenn ich Alt drücke, komme ich nicht ins Menü wie unter Windows üblich. Außerdem haben die einzelnen Menüeinträge keine Mnemonics. Ob das ein FMX Makel ist oder von dir nicht berücksichtigt, weiß ich nicht. Auch in den einzelnen Eingabefenstern kann ich nicht mit nem Shortcut eine Seite weiter oder sowas (fehlende Accelerators auf den Buttons bzw fehlende Shortcuts auf den Actions dahinter).
...

Oh no! Hatte hier gerade eine ausführliche Antwort zu Deinem posting formuliert, plötzlich irgendwie alles verschwunden.

Daher jetzt in Anbetracht der Uhrzeit nur noch mal kurz in Stichworten:

* Menüs, Accelerator, wie von Dir angesprochen, sollten in der Tat noch verbessert werden.

* Wenn Grid oder TStringGrid nicht reichen, besteht Alternative des TMS StringGrid, das ist schnell und gut, auch mit vielen 100.000 Datensätzen drin.

* Deinen MacGuyver-Vergleich finde ich ganz witzig und irgendwo auch zutreffend, so komme ich mir in der Tat gerade vor.

* Was ich mit Rapid und ++ meine, zeige ich demnächst mal in einem kleinen Video, es gibt nämlich in der Tat ein paar Sachen, die im Vergleich zur VCL viele Stunden Entwicklungsarbeit sparen.

* Danke für den Bugreport

, den Listenindex-Fehler habe ich behoben (das aktivieren der Buttons ist kein Problem, es kommt eine Meldung, wenn nicht alles richtig ausgefüllt ist).

**arnof**

In Sachen TMS Grid und Geschwindigkeit muss ich Dir leider widersprechen. In VCL habe ich es erst rausgeworfen, da es mit vielen Datensätzen unerträglich langsam ist. Dort habe ich die TMS eigene Suche aktiviert. Bei vielen Datensätzen ist es unerträglich (pro Tastendruck 30 sec und länger). Auch die TMS eigenen Bugs (die man nicht immer gleich merkt) machen mich echt Wahnsinnig (zum FMX Grid hatte ich hier auch mal eine Lösung gepostet, da TMS immer behauptete da währe kein Bug) …

XE5 und Mac OS, hier gehen echte Oberbasics einfach nicht: Beispiel ich habe eine App im Appstore und bekomme mind. pro Woche eine Beschwerde, das die User nicht speichern können!. Die haben ältere Mac OSx was ich leider nicht mehr habe (10.6,10.7), da funktionieren die Savedialoge einfach nicht!

Lösung einen selbst Programmieren

Nächstes Problem, wenn eine Anwendung mal ein paar mehr User hat, so bekommt man auch User die Barierefreiheit benötigen (z.B. Sehschwäche). Die Betriebssysteme bieten hierfür Tools, die aber natürlich mit FMX nicht gehen.

PS: ich werde es aber weiterhin versuchen was zu veröffentlichen: zum Thema Fastreport, den bekommt man aber nur durch den Review in dem man diesen vor dem Reviewer versteckt.