Neuer Blog über FireMonkey Entwicklung eröffnet

[Harry Stahl]

Gerade habe ich einen neuen Blogbeitrag zur Grafikbearbeitung mit FireMonkey (für MAC OS X) hochgeladen (http://www.devpage.de/blog/firemonkey.htm).

Mit dem Erscheinen von Delphi XE4 ist das eBook-Projekt zu Delphi XE3 nun auch abgeschlossen, d.h. die heutige Aktualisierung stellt nun das letzte Update des Buches dar.
Soweit ich das im Moment überblicken kann, haben die Ausführungen zu Delphi XE3 aber weiterhin Gültigkeit auch für Delphi XE4.

Derzeit ist noch unklar, ob ich ein neues Buch für Delphi XE4 schreiben werde. Falls ja, werde ich dies in diesem Forum bekannt geben.

Den Blog werde ich aber auf jeden Fall weiterführen.

Viel Erfolg mit FireMonkey und Delphi!

[greenmile]

Schnell noch bestellt, habe völlig übersehen dass ich Kindl ja mit der Amazon-App auf dem Galaxy Tab lesen kann.
Würde mich freuen wenn es mit XE4 weitergeht, gerade in Sachen Mobile könnte das sehr interessant werden.

[Harry Stahl]

Wollte hier mal wieder den Hinweis los werden, dass ich - nach längerer Pause - gerade einen neuen Blog-Beitrag zu Delphi-XE5 und FireMonkey (weiterhin in Bezug auf Crossplatform Windows / MAC OS X) veröffentlich habe.

Da finden sich auch erste Hinweise und Workarounds für die Übernahme von älteren MAC OS X FireMonkey-XE3-Projekten nach XE5 und eine Möglichkeit, wie man ein eigenes Menü mit eigenen Einträgen als MAC OS-System-Menü verwenden kann.

Link steht unten.

[Harry Stahl]

Und wieder der Hinweis, dass es in meinem Blog einen neuen Beitrag zu FireMonkey gibt.

Diesmal geht es um die FireMonkey-Styles. Anhand des Buttonstyle wird einmal erklärt, wie auf unterschiedlichen Wegen ein Button gezeichnet werden kann und welche Unterschiede dabei zwischen Delphi XE3/XE4 und XE5 bestehen.

Ferner auch ein Tipp, wie man das Standard-Styles Bitmap (Windows 7style.png) ändert, um so einen eigenen Farbstil zu erzeugen.

Hier geht's zum Beitrag: http://www.devpage.de/blog/firemonkey.htm

[stahli]

Hi Harry,

mich überzeugt das Konzept der Styles nicht wirklich.

Wenn man sich eine Komponente (MyComponent) + "Styleanweisungen" (mycomponentsyle) unter irgendeinem Style bastelt und später einen anderen Style lädt, dann wird die Komponente nicht gezeichnet da in dem neuen Style keine "Styleanweisungen" für diese Komponente gefunden werden.
Ich muss also für mein Projekt alle Styles anpassen, die ich bereitstellen will, nur weil ich eine eigene Komponente einsetze.

Wäre es nicht besser, allgemeinere Bausteine zu definieren (Rahmen_links_erhöht, Rahmen_links_flach, Rahmen_links_vertieft, Hintergrund, Ecke_Links_unten_rund_erhöht...), aus denen dann zu Projektstart die Abbilder erzeugt werden?
Ich hätte jedenfalls gedacht, dass man Styles am besten so aufbaut.

Vielleicht ist mein beschriebenes Problem ja aber (inzwischen?) auch gar nicht (mehr?) vorhanden. Das würde mich freuen.

[Harry Stahl]

Bin leider kein Fachmann für Komponentenentwicklung. Muss gestehen, dass ich eine Vorliebe für Programmentwicklung habe.

Aber vielleicht findest Du hier mehr Infos:

http://docwiki.embarcadero.com/RADSt...mponents_Guide

Zitat:

Wenn man sich eine Komponente (MyComponent) + "Styleanweisungen" (mycomponentsyle) unter irgendeinem Style bastelt und später einen anderen Style lädt, dann wird die Komponente nicht gezeichnet da in dem neuen Style keine "Styleanweisungen" für diese Komponente gefunden werden.
Ich muss also für mein Projekt alle Styles anpassen, die ich bereitstellen will, nur weil ich eine eigene Komponente einsetze.

Ohne das Projekt konkret vor Augen zu haben, ist es natürlich schwer, da etwas hilfreiches sagen zu können.

Aber wie wäre es mit einer Alternative, zur einzelnen Anpassung der Style-Dateien? Z.B. könntest Du andere Style-Dateien, bevor Du sie vollständig lädst, um diesen Style zuzuweisen, on the fly mit Deinen Style-Informationen für Deine Komponente ergänzen?

Also z.B. so:

Schritt1: Style-Datei z.B. in eine TStringlist laden.
Schritt2: Diese StringList mit Style-Informationen für Deine Komponente ergänzen.
Schritt3: Diese StringList in einen Stream schreiben.
Schritt4: Nun den Stream in ein Stylebook laden.

[stahli]

Bei einem kurzen schnellen Blick auf die Hilfe fühle ich mich bestätigt (siehe vor allem letzter Absatz):

Zitat:

Suchreihenfolge für Stilressourcen

Ein Steuerelement sucht nach einem Stil anhand der folgenden (näherungsweisen) Suchsequenz und hält bei der ersten Übereinstimmung an:
1. Wenn die Eigenschaft StyleBook des Formulars festgelegt ist, wird dieses TStyleBook anhand zweier Namen durchsucht: 1. Der Eigenschaft StyleLookup des Steuerelements, sofern festgelegt.
2. Eines Standardnamens, der aus dem Klassennamen des Steuerelements gebildet wird: 1. Der erste Buchstabe (das Präfix 'T' im Standardschema zur Klassenbenennung) wird weggelassen.
2.'style' wird hinzugefügt.


2. Die fest codierten Standardstile werden anhand von drei Namen gesucht: 1. Der Eigenschaft StyleLookup des Steuerelements, sofern festgelegt.
2. Des Standardnamens, der aus dem Klassennamen des Steuerelements gebildet wird.
3. Eines Standardnamens, der aus dem Klassennamen des übergeordneten Steuerelements nach demselben Muster gebildet wird.


Zum Beispiel lauten die Standardnamen für TPanel "Panelstyle" und "Controlstyle". Für TCalloutPanel lauten die Standardnamen "CalloutPanelstyle" und "Panelstyle".

Bei dem Namensabgleich wird die Groß-/Kleinschreibung nicht berücksichtigt. Wenn keine Übereinstimmung gefunden wird, hat das Steuerelement keinen Inhalt und ist eigentlich nicht sichtbar. Code, der vom Auffinden von Unterkomponenten abhängt, schlägt fehl. (Dies dürfte nur bei unvollständigen oder inkorrekt zusammengestellten, benutzerdefinierten Steuerelementen vorkommen, weil alle integrierten Steuerelemente über zugehörige fest codierte Stile verfügen. Direkte Nachkommen von integrierten Klassen hätten den Inhalt ihrer Basisklasse; Nachkommen der zweiten Generation wären leer.)

Wenn ich also einen Style "MyComponentstyle" für "TMyComponent" deklariere und der Anwender einen anderen Style in die Anwendung lädt (das kann man ja so vorsehen) ist MyComponent nicht mehr sichtbar. Ähnlich läuft es wenn man von TEdit mal TBasedEdit und davon wieder TMyEdit ableitet und dieses benutzt.

Man mag für das eine oder andere Problem Notlösungen finden, aber das Konzept würde ich aus meinem derzeitigen Blickwinkel als halbgar bezeichnen.

Lieber würde ich hinterlegen, wie die Hintergründe der Controls gefüllt werden sollen (Holzmuster, Aluminium, Farbverlauf, grau, halbtransparent usw) wie die Rahmen aussehen sollen (jeweils für erhöht, flach und vertieft), welche Textfarbe und Textart genutzt werden soll usw.
Dann könnte ich meiner TMyPanel einfach sagen dass sie einen abgerundeten Rahmen haben soll, dass sie erhaben, flach oder eingedrückt sein soll und das tatsächliche Abbild wird dann zum Programmstart oder bei Größenänderungen (nicht bei Verschiebungen von Komponenten) neu zusammengestellt.
Dann müssten die Styles nur alle Bausteine (Schnippsel) enthalten, mit denen Komponenten zusammengebaut werden können und nicht mehr alle Komponentenabbilder selbst.
Die Zusammensetzung der Schnipsel könnte sozusagen im Create jeder Komponente erfolgen - also per Quelltext. Oder man könnte dies auch über einen grafischen Editor und eine Ressource lösen, die dann in die Komponente integriert wird.
Die Style-Dateien würden dann nur noch allgemein gültige Bausteine (Schnippsel) enthalten, die beim Zeichnen der Komponenten genutzt werden können.
Dann wären alle Stiele für alle Projekte verwendbar und man müsste nicht befürchten, dass bestimmte Komponenten nicht oder völlig falsch dargestellt werden.

Mich nervt eben, dass ein völlig neues Framework auf den Markt geworfen wurde, das ein wirklich hohes Potential hat, das dieses aber leider in großen Teilen verschenkt.
Ich würde mich gern eines besseren belehren lassen - bin ja selbst nur Quereinsteiger - aber ich denke, so falsch liege ich da leider nicht.


Für kleine 08/15-Anwendungen oder kleine Apps mag FMX ja funktionieren, aber für größere Projekte sehe ich schwarz. Jedenfalls kann man dann nur die Basics verwenden damit alles stabil läuft und muss sich in den eigenen Möglichkeiten selbst beschneiden.
Das war sicherlich mal anders angedacht - jedenfalls haben das die Werbevideos von Emba suggeriert.

[greenmile]

Hallo Harry,

wie immer vielen Dank für Deinen Eintrag, Dein Blog hilft, zumindest ein wenig Licht in's Dunkel zu bringen. Leider sind die Styles für mich uninteressant, da ich mich nach XE2/XE3/XE4 gegen einen Großteil der Firemonkey Controls und damit gegen Styles entschieden habe. Leider hat man mit jeder neuen XE-Version das Gefühl, dass ein neuer Entwickler eingestellt wurde, der dann umgehend wieder alles ändern muss (Profilierungsbedarf?). Daher muss ich das nehmen, was fast immer gleich ist: Die Grundform. Ansonsten nehme ich mittlerweile, wo immer es geht, TMS. Die sehen native aus, verhalten sich native und ich bekomme Controls, die das können was ich benötige.

Da das, wenn ich es recht beobachte, viele betrifft, würde ich mich über Einträge bzgl. Plattform-Unabhängigkeit freuen. Was muss ich wie tun, ob meine App in den Store zu bekommen? Zertifikat beantragen, Codesign usw. Wie teste ich es effektiv? Mac, Android etc.? Ich denke, hier sind noch viele Fragen offen. Mittlerweile habe ich mein Projekt für den Mac signiert, aber bitte frag mich nicht, wie ich das gemacht habe, war ein Try-and-Error. Allerdings lehnt der AppStore es jedesmal ab, zumindest der Uploader. Wieso weiß ich nicht. Der Spaß wird mit Windows RT weitergehen und Android habe ich noch nicht angefangen.

[Harry Stahl]

Zitat:

Zitat von stahli (Beitrag 1239866)

Wenn ich also einen Style "MyComponentstyle" für "TMyComponent" deklariere und der Anwender einen anderen Style in die Anwendung lädt (das kann man ja so vorsehen) ist MyComponent nicht mehr sichtbar. Ähnlich läuft es wenn man von TEdit mal TBasedEdit und davon wieder TMyEdit ableitet und dieses benutzt.

Wie gesagt, bin leider kein Profi in Sachen Komponentenentwicklung. Vielleicht hilft ja auch noch dieser Link:

http://docwiki.embarcadero.com/RADSt...ponentendesign

So wie ich es verstehe, basiert auch bei der Komponentenentwicklung die Zeichnung der Komponenten auf Stilvereinbarungen. Deswegen könnte ich mir vorstellen, dass man eine neue Komponente auf der Basis von bestehenden Standard-Komponenten / Standard-Stilvereinbarungen entwickelt, dann müsste die Komponente auch gezeichnet werden, wenn ein anderer Stil geladen wird.

Wenn Du Dir z.B. einmal von TMS die TMSFMXGrid Komponente ansiehst. Da kann man auch einen anderen Stil für die Form laden, trotzdem wird das Grid weiterhin angezeigt. Es sollte also ein Weg existieren.

Vielleicht hat ja auch noch jemand aus diesem Forum einen Tipp für Dich, der selber schon mal eine Komponente entwickelt hat.

Zitat:

Für kleine 08/15-Anwendungen oder kleine Apps mag FMX ja funktionieren, aber für größere Projekte sehe ich schwarz. Jedenfalls kann man dann nur die Basics verwenden damit alles stabil läuft und muss sich in den eigenen Möglichkeiten selbst beschneiden.
Das war sicherlich mal anders angedacht - jedenfalls haben das die Werbevideos von Emba suggeriert.

Na, da würde ich aber mal ganz forsch das Gegenteil behaupten. Wobei ich natürlich (nur) aus eigener Erfahrung sprechen kann. Aber meine Anwendung CopyBackup 3.01 für MAC und Windows, die noch mit XE3 erstellt wurde, ist m.E. schon mehr als nur eine 08/15 Anwendung / kleine App (bei Interesse siehe hier: http://hastasoft.de/CopyBack-info.htm).

Die anderen bislang von mir entwickelten FireMonkey-Anwendungen fallen eher in die 08/15 Kategorie, aber auch damit lässt sich Geld verdienen (neuestes, gerade in den App-Store aufgenommenes Produkt ist das MultiScreenShot-Programm, siehe hier: http://hastasoft.de/MultiScreenShot-MAC.htm).

Ich habe gerade begonnen, mein kommerziell bislang erfolgreichstes Produkt (PC-Adreßzz!) auf FireMonkey umzustellen, denn nur so werde ich der immer stärker werdenden Nachfrage nach IOS- und Android-Apps gerecht werden können.

Hier werde ich aber erst in einigen Monaten mehr zu sagen können...

[Harry Stahl]

Zitat:

Zitat von greenmile (Beitrag 1240083)

Hallo Harry,
wie immer vielen Dank für Deinen Eintrag, Dein Blog hilft, zumindest ein wenig Licht in's Dunkel zu bringen.

Danke für die Rückmeldung. Styles sind in der Tat auch kein einfaches Thema.

Zitat:

Leider hat man mit jeder neuen XE-Version das Gefühl, dass ein neuer Entwickler eingestellt wurde, der dann umgehend wieder alles ändern muss (Profilierungsbedarf?).

Nein, ich würde es eher wirklich der großen Dynamik zuschreiben, die da noch im Gange ist. Bedenke: Mit XE2 wurde zunächst MAC/Windows und IOS bedient, basierend auf der FPC-Einbindung. So sehr ich Lazarus und die FPC auch schätze, so ganz im Grünen Bereich war das - zumindest zum damaligen Zeitpunkt - noch nicht. Dass man daher auf eine eigene Lösung setzte, ist daher vielleicht nachzuvollziehen. Aber klar, dass es dann auch Umbrüche und radikale Änderungen der Framework-Ansätze geben musste.

Mit XE4 wurde dann auch IOS wieder auf der neuen Basis unterstützt und dann mit XE5 auch Android. Man muss sich doch nur mal vorstellen, welche wahnsinnige Arbeit es sein muss, für diese 4 Megaplattformen (Windows / MAC / IOS / Android) Schnittstellen zu generieren, so dass eine Komponente auf allen Plattformen funktioniert. Und diese Plattformen selber haben ja auch wieder eine irre Dynamik und die nehmen auch nicht unbedingt Rücksicht auf Compiler-Hersteller.

Zitat:

Daher muss ich das nehmen, was fast immer gleich ist: Die Grundform.

Das ist durchaus eine gute Strategie, wobei ich nur ahnen kann, was Du genau mit Grundform meinst.

Zitat:

Ansonsten nehme ich mittlerweile, wo immer es geht, TMS. Die sehen native aus, verhalten sich native und ich bekomme Controls, die das können was ich benötige.

Ja, das ist sicher auch eine Alternative. Werde ich mir demnächst auch mal genauer ansehen. Tedenziell versuche ich aber mit dem auszukommen, was mir Delphi bietet, da dann relativ sicher ist, dass ich die gewünschten Plattformen auch dann weiterhin bedienen kann, wenn sich Delphi oder die Plattformen ändern. Zusätzliche Komponenten führen natürlich auch weitere Risisken ein. Die VCL-TMS-Komponenten nutze ich schon seit Jahren und ich schätze sie sehr. Jedoch ist bei jedem Update der Komponenten oder von Delphi die Gefahr verbunden, dass das eine oder andere nicht mehr funktioniert. Habe ich alles schon erlebt (mit FireMonkey nutze ich aber die TMSFMXGrid-Komponente und den TMSFMXBitmapContainer).

Zitat:

Da das, wenn ich es recht beobachte, viele betrifft, würde ich mich über Einträge bzgl. Plattform-Unabhängigkeit freuen. Was muss ich wie tun, ob meine App in den Store zu bekommen? Zertifikat beantragen, Codesign usw.

Zum Thema, "Wie bringe ich meine App in den Store", habe ich ja in meinen Büchern schon einiges geschrieben. Im Blog habe ich das aber (noch) nicht aufgegriffen, weil ich das zwar für die Bücher der Vollständigkeit halber dazugehörend empfand, für einen Blog aber weniger, da es dazu ja schon einiges im Internet gibt (auch Videos).

Aber die Anregung, noch ein wenig mehr das Thema "Plattform-Unabhängigkeit" zu fokussieren, nehme ich gerne auf.

Zitat:

Mittlerweile habe ich mein Projekt für den Mac signiert, aber bitte frag mich nicht, wie ich das gemacht habe, war ein Try-and-Error. Allerdings lehnt der AppStore es jedesmal ab, zumindest der Uploader.

Dann sollte Dir der Uploader eine Fehlermeldung auswerfen. Auch solltest Du u.U. eine Mail von Apple erhalten, wo das Problem noch mal berichtet wird.

Wichtig ist auch, dass Du den aktuellsten Uploader benutzt.

Wenn Du hier die Fehlermeldung preis gibst, kann ich evtl. mehr dazu sagen.