Neuer Blog über FireMonkey Entwicklung eröffnet

[Harry Stahl]

Hoffe hier ist die richtige Stelle, um die Nachricht los zu werden, dass ich nun auch einen Blog zur FireMonkey Entwicklung (Vorranging Cross-Plattform Entwicklung) auf meiner devpage eröffnet habe. Wer Lust hat, ist herzlichst eingeladen, hier einmal vorbei zu schauen:

http://www.devpage.de/blog/firemonkey.htm

[Daniel]

Ich habe dieses Thema wieder hervorgeholt, da ich deutschsprachige Ressourcen zu Delphi und FireMonkey absolut begrüße. Neben seinem Blog hat Harry ein derzeit 180 Seiten umfassendes Buch geschrieben, welches das FireMonkey-Framework intensiv behandelt und auch Einsteigern gerecht werden sollte.

Das Blog selbst erlaubt zwar keine Kommentare von Außenstehenden, aber eine konstruktive Diskussion lässt sich ggf. auch hier oder an anderen Stellen führen.



//Anmerkung: Das Thema wurde ursprünglich als "Werbung" klassifiziert und entfernt, was grundsätzlich korrekt ist. Aus nahe liegenden Gründen bestehe ich auf eine kurze Rücksprache, die mittlerweile erfolgt ist. :-)

[greenmile]

Danke für den Hinweis.

[stahli]

Hallo Harry,

trotz Namensgleichheit bewerte ich FMX leider (noch?) etwas anders.

Den Grundsatz der Windowsunabhängigkeit (sowohl von den Controls als auch den Nachrichten) und die Skalierbarkeit finde ich super.

Leider funktionieren viele Dinge nicht richtig wenn man mehr tun will als einige Controls in ein Formular zu setzen.
Es werden in nicht nachvollziehbarer Form einfach Änderungen von Controls nicht richtig auf dem Formular dargestellt (der Canvas nicht sichtbar aktualisiert) oder Styles plötzlich nicht verwendet.
In der Beziehung besteht noch viel Nachbesserungsbedarf, auf dessen Realisierung ich aber noch hoffe.

Die LiveBindings (eigentlich unter FMX ja unverzichtbar - sofern man keine Alternative nutzen kann) kann man im Grunde komplett vergessen. So steht man letztlich praktisch im nativen FMX ohne datengebundene Controls da.

Die Styles finde ich inzwischen im Ansatz auch nicht sinnvoll. Styles wären m.E. sinnvoll um der GUI ein einheitliches Aussehen zu verleihen (im Sinne eines Skinnings: Rahmen und Flächen sollten eben einheitlich dargestellt werden).
Auf die Funktionalität eines Controls sollte ein Style aber keinen Einfluß haben. Ich verstehe die Sinnhaftigkeit des Konzeptes nicht.
Ändert man einen Style hat eine Komponente plötzlich andere Bestandteile?
Zu einer übersichtlichen und effektiven Arbeitsweise trägt das nicht bei.

Mein Wunsch: Konzept der Styles überarbeiten (und auf ein Skinning beschränken), Fehler bei der Darstellung im Formular bereinigen, Komponentenpalette ergänzen/optimieren ... dann könnte der Affe richtig brennen.

Die angesprochenen Punkte (insbesondere das Style-Konzept) würde ich auch gern ausführlicher diskutieren. Ich vermute aber leider nicht, dass Emba sich da aktiv einbringen würde (wäre cool, wenn es einen deutschen FMX-Ansprechpartner gäbe, so dass angesprochene Punkte nicht in der QC versickern).
(An einer Alternative zu den Livebindings versuche ich mich ja schon selbst.)

[Harry Stahl]

Hallo Stahli,

ich stimme Dir zu, dass in der Tat noch einiges an Nachbesserungsbedarf an dem ganzen FireMonkey-Framework besteht.

Was mich aber daran fasziniert ist die Tatsache, dass man damit schon jetzt relativ leicht Programme für den MAC schreiben kann. Die Aussicht, es bald auch für IOS-Geräte (wieder mit MobileStudio) und dann hoffentlich bald auch für Android machen zu können, finde ich vielversprechend. Und die Marktmacht dieser Stores finde ich schon sehr attraktiv, vor allem wenn man Einzelentwickler ist oder KMU. Und Apple und die ganze Entwicklung zu OS X hin sollte man nicht unterschätzen. Als das wertvollste Unternehmen der Welt (bzw. gerade im Wechsel mit Exxon) werden die noch einiges tun, um die MAC Basis zu erweitern. Auch geht viel Nutzung vom PC weg hin zur Tablet-Nutzung. Da ist es dann nicht verkehrt, Angebote für die Anwender zu haben.

Livebindings finde ich in einigen Fällen ganz praktisch, z.B. um in einem ImageViewer und mit einer Trackbar in das Bild rein- und rauszoomen zu können, oder ähnlich einfache Konstruktionen. Man braucht da keine einzige Zeile Code zu schreiben. Wenn es um umfangreiche Datenbankanbindungen geht, kann ich dazu leider nicht viel sagen, weil ich in dieser Hinsicht Delphi vielleicht eher ein wenig atypisch nutze (also ohne die ganzen Datenbankfunktionen; nichts desto trotz habe ich aber ein netzwerkfähiges, sogar über das Internet nutzbares Datenbank-Programm in meinem Portfolio, so wie ich das derzeit sehe, werde ich das auch für den MAC umsetzen können).

Die IDE zur Bearbeitung der Styles finde ich auch noch verbesserungswürdig und auch an der Funktionalität kann man noch was schrauben. Es wird auch wohl so sein, dass man derzeit nicht alles, was unter Windows machbar ist, auch unter FM machen kann. Ich denke aber, das wird nach und nach möglich sein. Ich verfolge hier z.B. derzeit auch die Strategie, zunächst einfachere Programme (wie z.B. wie jetzt mit Copy Backup mit 50.000 Programmzeilen geschehen) auf FM umzusetzen und dann die komplexeren Programme folgen zu lassen.

Mein Ziel ist ja auch, mit dem eBook Lösungen zu bieten, um mit der jeweils aktuellen Delphi-Version bestmöglich Cross-Platform Programme schreiben zu können. Man muss halt auch schon mal mit Workarounds leben oder die Funktionalität schrittweise erweitern. Ich lerne da momentan selber noch dazu. Was noch ein wenig Arbeit in der Entwicklung machen wird, ist (nicht für alle, aber für viele Programme) die Apple Sandbox-Funktion für den App-Store. Das wird auch mein nächstes Blog-Thema sein.

Harry Stahl

[Harry Stahl]

Und jetzt nur kurz die Info, dass der angekündigte Blogbeitrag zum Sandboxing mit Delphi nun online ist (http://www.devpage.de/blog/firemonkey.htm)

[Harry Stahl]

FireMonkey Blog, Teil 3 ist nun online: Delphi mit MAC API's (POSIX, CORE F. und COCOA) verwenden

Hier also kurz die Info, dass ich gerade den 3. Teil gepostet habe. Im Blogbeitrag wird beschrieben, wofür die einzelnen API-Layer stehen und wie sie sich generell unterscheiden. Auch wird für jeden API-Bereich an Hand eines Beispiels gezeigt, wie man entsprechende API-Funktionen in Delphi einbindet.

Viel Spaß beim Lesen

Harry Stahl
http://www.devpage.de/blog/firemonkey.htm

[greenmile]

Danke für die Info.

[greenmile]

So langsam wird das eBook interessant, ich favorisiere jedoch PDF. Hast Du es nur im Kindle Shop oder auch als PDF?

[Harry Stahl]

Ganz am Ende der Info-Seite zum E-Book auf der Devpage Seite ist auch eine alternative Möglichkeit, das Buch als PDF-Datei zu erwerben (http://www.devpage.de/firemonkey-del...nt-mac-osx.htm)

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

[Harry Stahl]

Gerade habe ich einen neuen Blogbeitrag hochgeladen, der beschreibt, wie man FireMonkey–Funktionen von einer VCL-Anwendung aus per FMX-DLL nutzen kann.

Es wird gezeigt, wie man z.B. ein Bitmap aus seiner VCL-Anwendung an den FireMonkey-DLL Dialog übergibt und mit Hilfe des PaperSketch-Effekts verändert und dann wieder an die VCL-Anwendung zurück gibt: http://www.devpage.de/blog/firemonkey.htm.

Im Blogbeitrag ist auch ein Link auf mein YouTube-PixPower-Kanal, wo man sich die Funktion direkt in Aktion ansehen kann.

Viel Spaß damit.

[stahli]

etwas OT...

Das Pix-Power ist ja (dem ersten Eindruck nach) der Hammer. :thumb:
Das werde ich mir mal die nächsten Tage näher ansehen.

Nutzt Du da DirectX, OpenGL oder o.ä. und lässt jetzt FMX extern Effekte berechnen?

[mkinzler]

Es werden wohl die Filtereffekte von FMX verwendet ( Dll verwendet FMX und gibt die Bilder über Memorystream an VCL Anwendung), wie er vorgeht beschreibt er in dem genannten Blogeintrag.

[stahli]

Ok, habe Mittag mal schnell drüber gelesen. Ich dachte nur nicht, dass das bisher reine VCL war. Ich bin jedenfalls beeindruckt. :)

[Harry Stahl]

Zitat:

Zitat von stahli (Beitrag 1247703)

etwas OT...
Das PixPower ist ja (dem ersten Eindruck nach) der Hammer. :thumb:

Danke! Von einem Entwicklerkollegen so ein Kompliment zu hören, freut mich natürlich riesig.:-D

Zitat:

Zitat von stahli (Beitrag 1247703)

etwas OT...
Nutzt Du da DirectX, OpenGL oder o.ä. und lässt jetzt FMX extern Effekte berechnen?

FMX ist mit dem im Blog gezeigten Beitrag erstmals mit der DLL zu dieser VCL-Anwendung dazu gekommen und macht derzeit wirklich nur diesen PaperSketch-Effekt. Ansonsten ist alles VCL und Windows-API bzw. eigene optimierte Grafikbearbeitungsroutinen.

An Drittkomponenten nutze ich nur ImageEn, um die Photoshop-Datei einzulesen und später wieder zu speichern, die ganze Ebenenverwaltung, Zeichnung, Auswahlen etc. mache ich selber.

Aber ich plane noch eine Reihe von Dingen über die DLL-Lösung in das VCL-Programm zu integrieren, bevor ich eine reine FMX-Anwendung daraus mache. Einige Funktionen unter FMX sind besser und schneller, als unter (Standard-)Windows möglich.

[Sir Rufo]

Mal eine bescheidene Frage:

Hast du das wirklich so in einer realen Anwendung drin?

Delphi-Quellcode:

function ShowBitmapFromStream (ms: TMemoryStream; fn: shortString): ShortString; 
var 
  Filter: FMX.Filter.TFilter; 
begin 
  Filter := TFilterManager.FilterByName('PaperSketch'); 

  try 
    F_Filters := TF_Filters.Create(Application); 
    F_Filters.ImageViewer1.bitmap.LoadFromStream(ms); 

    if F_Filters.ShowModal = mrOK then begin 

      Filter.ValuesAsBitmap['Input'] := F_Filters.ImageViewer1.bitmap; 
      Filter.ValuesAsFloat ['BrushSize'] := F_Filters.TrackBar1.Value; 
      F_Filters.ImageViewer1.bitmap := TBitmap (Filter.ValuesAsBitmap['Output']); 

      F_Filters.ImageViewer1.bitmap.SaveToFile (fn); 

      Result := fn; 
   end else begin 
     Result := ''; 
  end; 

  finally 
    F_Filters.Free; 
  end; 
end;

Da fallen mir so ein paar Dinge auf, die ich so nicht machen würde:

• den Dateinamen würde ich per
  Delphi-Quellcode:

  WideString

  übergeben
• den Stream würde ich per
  Delphi-Quellcode:

  IStream

  übergeben
• ich würde überhaupt keinen Dateinamen übergeben und den Austausch auch nicht über eine Datei machen, sondern per
  Delphi-Quellcode:

  IStream

  zurückliefern

[Harry Stahl]

Also die tatsächliche Implementierung hat natürlich noch ein paar Sicherheitsprüfungen an verschiedenen Stellen dazu, die ich aber zur besseren Lesbarkeit des Source-Codes hier weggelassen habe.

Zu IStream kann ich nicht viel sagen, da ich bislang damit noch nichts zu tun hatte.

Aber ich lerne gerne dazu.
Warum würdest Du also IStream hier verwenden?
Und gibt es das überhaupt für FireMonkey?

Weshalb ich einen Shortstring verwende, habe ich ja im Blogbeitrag beschrieben.
Warum würdest Du statt dessen lieber Widestring verwenden?

Ich stimme Dir zu, die Rückgabe eines Bitmap-Streams wäre eleganter (und noch ein wenig performanter). Habe ich ja selber im Blogbeitrag beschrieben, dass ich es mir ein wenig bequem mache. Es war letztlich aber nicht nur Bequemlichkeit.

Wenn ich einen FireMonkey-Bitmap-Memorystream (oder IStream?) wieder auf VCL-Seite annehmen würde, müsste ich dort wieder notgedrungen einige FMX-Units aufnehmen, um über eine Firemonkey-TBitmap eine Konvertierung in eine VCL-TBitmap vorzunehmen. Was grundsätzlich geht, aber es wären einfach eine Reihe zusätzlicher Randbedingungen in meinem Source-Code zu ändern gewesen, so dass ich eben die Lösung mit der temporären Datei gewählt habe.

Und die Empfehlung von EMBA, VCL-Code und FMX-Code nicht zu mischen, macht für mich auch grundsätzlich Sinn.

Jedenfalls funktioniert es in meiner Anwendung tadellos.

[Sir Rufo]

Die Funktionalität will ich deiner Umsetzung gar nicht absprechen, sie ist nur unschön.

• Delphi-Quellcode:

  WideString

  kann auch Unicode und ist somit in der Lage wirklich alle Dateinamen zu transportieren
• IStream ist ein Stream-Interface von Microsoft und hat nichts mit FMX oder VCL zu tun. Das Interface ist in Winapi.ActiveX zu finden und mit einem System.Classes.TStreamAdapter kannst du dir so einen
  Delphi-Quellcode:

  IStream

  von einem normalen
  Delphi-Quellcode:

  TStream

  holen.

Der ganze Aufruf sieht dann mit einem

Delphi-Quellcode:

IStream

so aus (die Rückgabe erfolgt im gleichen Stream ;)):

Delphi-Quellcode:

function ProcessBitmap( ABitmap : TBitmap ):Boolean
var
  LStream : TStream;
begin
  LStream := TMemoryStream.Create;
  try
    ABitmap.SaveToStream( LStream );
    if ShowBitmapFromStream( TStreamAdapter.Create( LStream, soReference ) ) then
    begin
      LStream.Seek( 0, soFromBeginning );
      ABitmap.LoadFromStream( LStream );
    end;
  finally
    LStream.Free;
  end; 
end;

BTW:

Ich habe gerade die Vorlage für deinen Code entdeckt
http://blogs.embarcadero.com/stephen...l-application/

Nun ja, die Beispiele sind von denen halt auch nicht so der Brüller.

Und den Grund für die Rückgabe als Datei habe ich auch entdeckt (ein echter Schenkelklopfer):

FMX.Graphics.TBitmap.LoadFromStream analysiert den Stream und erkennt das Grafikformat - sehr löblich.

FMX.Graphics.TBitmap.SaveToStream speichert das Bild stumpf als PNG in den Stream :shock:
FMX.Graphics.TBitmap.SaveToFile speichert das Bild in dem Format ab, was von der Dateiendung erkannt wird.

Schaut man sich den Code von

Delphi-Quellcode:

TBitmap.SaveToStream

an, dann sieht man aber auch sofort, wie man das abändern kann ;)

[Harry Stahl]

Vielen Dank für Deine Erläuterungen:

* Für Widestring müsste man wieder die ShareMem-Interface-Unit einbinden und zusätzlich die BORLNDMM.DLL weitergeben.
Warum sollte ich das machen, wenn ich bei der gezeigten Implementation gar keine Unicodenamen brauche? Wenn ich es doch brauchen sollte, verwende ich PChar, so kann ich Unicode verwenden, brauche aber die erwähnte Unit und DLL nicht.

* Ich hatte zuvor für mich schon einmal die Rückgabe mit dem TMemoryStream implementiert. Die Rückgabe funktionierte genau so, wie die hier von Dir vorgeschlagene Lösung mit dem IStream. Beides mal kommen für sich gesehen auch gültige Streams an. Das habe ich insofern getestet, als dass ich den Stream als Bitmap-Datei gespeichert habe und mit einer FireMonkey-Applikation konnte man diese Bitmap-Datei dann einlesen.

Aber auch bei Deiner Lösung wird das einlesen des Streams in die VCL-Bitmap mit der Fehlermeldung quitiert, dass die Bitmap ungültig sei.

Grund ist der, dass ja ein Stream für eine FireMonkey-Bitmap zurückgeliefert wird und den kann ich nun mal nicht in eine VCL-Bitmap einlesen, weil die eben nicht kompatibel sind.

Insofern funktioniert der von Dir vorgeschlagene Weg mit dem IStream als "schönere" Lösung hier leider auch nicht.

[Harry Stahl]

Oh, da hat sich Deine ergänzende Antwort mit meiner überschnitten.

In

Delphi-Quellcode:

procedure TBitmap.SaveToStream(Stream: TStream);
var
  Surf: TBitmapSurface;
begin
  Surf := TBitmapSurface.Create;
  try
    Surf.Assign(Self);
    TBitmapCodecManager.SaveToStream(Stream, Surf, '.png');
  finally
    Surf.Free;
  end;
end;

hatte ich natürlich auch schon reingesehen, aber jetzt durch Deinen Hinweis, dass man es "sofort sehen würde, was man abändern kann", habe ich nun auch gesehen, dass der Stream im PNG-Format gespeichert wird. OK. Das sollte man in der Tat ändern können, muss mal sehen, wie ich das am Besten mache. Dann sollte auch der Weg über einen Stream insgesamt gehen.

Aber heute nicht mehr, morgen mach ich weiter...

Jedenfalls Danke für Deine Hinweise, es freut mich immer wieder, wenn am Ende eine neue Erkenntnis steht.

[Sir Rufo]

Da ein WideString von Windows verwaltet wird, benötigt man eben kein ShareMem.

Die Verwendung von

Delphi-Quellcode:

IStream

ermöglicht es zudem, diese DLL nicht nur von Delphi Anwendungen benutzen zu können.

[Harry Stahl]

Zitat:

Zitat von Sir Rufo (Beitrag 1247804)

Da ein WideString von Windows verwaltet wird, benötigt man eben kein ShareMem.

Na schon wieder was dazu gerlernt.:oops:
Wir sollten uns vielleicht öfter mal unterhalten...

Zitat:

Zitat von Sir Rufo (Beitrag 1247804)

Die Verwendung von

Delphi-Quellcode:

IStream

ermöglicht es zudem, diese DLL nicht nur von Delphi Anwendungen benutzen zu können.

OK, das hatte ich schon vermutet. Hatte aber für mich in der gezeigten Umsetzung keine Relevanz, da die DLL ja nur von meinem Programm genutzt und das Beispiel einfach gehalten werden sollte. Im Wesentlichen ging es ja um die FMX-DLL zu VCL-Nutzung. Ist aber insgesamt ein berechtigter Hinweis von Dir. Ich werde meinen Blogeintrag noch mal überarbeiten und eine entsprechende Info aufnehmen. Aber wie gesagt, erst morgen (Abend) wieder...

[Harry Stahl]

So, ich habe den Blogbeitrag nun aktualisiert, auch die Rückgabe des Bitmaps geht nun per Stream, eine temporäre Datei wird nicht mehr benötigt.

Ich habe am Ende des Blogbeitrags auch einen Download-Link des Demos hinzugefügt, so spart man sich das tippen (evt. mal F5 zur Browser-Aktualisierung drücken). Den Source-Code könnt Ihr natürlich frei verwenden.

Vielen Dank noch mal an Sir Rufo, durch seine Hinweise konnte die Sache deutlich verbessert werden.

[Harry Stahl]

Ich habe den letzten Blogbeitrag noch um einen Link auf ein Youtube-Video ergänzt. Dort zeige ich, wie man die FMX-Form für die DLL, welche in der VCL-Anwendung genutzt wird, so modifiziert, so dass man sie auch direkt (also ohne DLL) in einer Firemonkey-Anwendung einbinden und verwenden kann.

Hier ist der Link zu diesem Beitrag aus meinem neuen FireMonkey Videoblog (FMX = RAD ++).:thumb:

Ich werde in den nächsten Tagen noch weitere Videos produzieren und hochladen, wer da Interesse hat, kann meinen Kanal ja abonnieren, dann erhält er eine automatische Benachrichtigung, wenn es was neues gibt.

Tipp zum Video: In voller Bildschirmauflösung und bei 720 DPI ansehen.

[Harry Stahl]

Heute mal kein schriftlicher Blogbeitrag, sondern ein kleines Video.

Video zeigt, wie man ganz schnell eine VCL-Form in eine FMX-Form umwandeln kann.

HINWEIS: Mir ist bei der Demonstration leider ein kleiner Fehler unterlaufen, ich hätte vor der Hinzufügung des konvertierten Formulars zum FMX-Projekt noch den Suchpfad zum MIDA-Pack angeben müssten, daher funktionierte die Image-Konvertierung nicht. Also, in Wirklichkeit funktioniert es also noch etwas besser, als hier gezeigt;-))

Hier der Link.

[Harry Stahl]

Noch ein kleiner Nachtrag:

Ich habe noch 2 ergänzende Videos hochgeladen, Teil 2 zeigt den Stand nach 5-6 Stunden Arbeit an dem zu konvertierenden Programm und Teil 3 gibt noch ein paar Tipps zum MIDA-Converter.

Hier Teil 2: http://youtu.be/i0sJ5XhYQEA

Hier Teil 3: http://youtu.be/kg5GsF5j1W8

Auch hier am besten in Vollauflösung und 720 DPI ansehen.

[Harry Stahl]

Erfreulicherweise hat das MIDA-Team meine Vorschläge zur Erweiterung des MIDA-Converters aufgenommen.

Es handelte sich dabei um die Option, nach der Umwandlung erst mal in den einzelnen Funktionen und Prozeduren den Source-Code auszukommentieren. Dadurch hat man erst mal eine funktionierende Form / Programm und kann dann einzelne Stellen schrittweise bearbeiten.

Der zweite Vorschlag betraff die Option, bei TSpeedButton und TBittBtn die Images als Childcontrol in den Button zu übernehmen. Bislang gingen diese Grafiken einfach verloren (es sei denn, man ließ den TSpeedButton in einen TMIDAImageSpeedButton umwandeln, das hatte aber andere Nachteile).

Insgesamt tolle Erweiterungen, die den Konvertierungsprozess noch einmal deutlich beschleunigen.

Ich habe ein kleines Video hierzu in meinem FireMonkey-Video-Blog erstellt, dass Ihr Euch hier ansehen könnt:

Hier Teil 4: http://youtu.be/QhPgiXZsHwI

[Harry Stahl]

Ich habe mal wieder einen neuen Beitrag in meinem FireMonkey-Blog veröffentlicht.

Diesmal geht es um das mixen von VCL und FMX-Komponenten in einer Form, konkret die Einbindung der VCL-PDF-Komponenten von Gnostice in eine Windows-FMX-Anwendung.

Beschrieben wird die Lösung unter Verwendung der Hydra-Komponenten von Rem Objects.

Hier geht es direkt zum Blogbeitrag:http://www.devpage.de/blog/firemonkey.htm

Hier zu einem Video, das ich dazu auf YouTube gepostet habe: http://youtu.be/0K8mEzDmlaM

Wer an dem Beitrag näher interessiert ist, sollte auch die ergänzenden Erläuterungen zum Video lesen.

Der Beitrag könnte aber auch für reine VCL-Anwender von Interesse sein (ist er für mich auch sehr), da man mit Hydra z.B. seine Delphi 2007-Anwendung mit den Neuerungen der letzten Delphi-Versionen ergänzen kann und das alles innerhalb der bestehenden Anwendung.

[Stevie]

Ja, Hydra ist toll, aber... warum?

Man baut doch keine FMX Anwendung und zieht sich dann für $499 selbst die Crossplatform Beine weg, indem man ne VCL DLL rein läd. :shock:

[bernau]

Zitat:

Zitat von Stevie (Beitrag 1273717)

Ja, Hydra ist toll, aber... warum?

Man baut doch keine FMX Anwendung und zieht sich dann für $499 selbst die Crossplatform Beine weg, indem man ne VCL DLL rein läd. :shock:

FMX bedeutet ja nicht unbedingt Mobile. Er hat doch klar gesagt, daß er diese für eine Windows-Anwendung zeigt.