FMX - Kenne die Fehler für ein einfacheres Arbeiten.

[Mavarik]

Vielleicht sollten wir einfach mal sammeln worauf man achten muss...(Die Kommentare in einem anderen Thread posten, weil hier ja viele verschiede Themen zusammen kommen werden?)

Beispiel:
Button in XE8 mit den neuen XE8 Styles (ja, da gab es eine Änderung, weil die Styles nicht mehr unbedingt das Icon vorgeben, sondern aus einer ImageList laden können)

Buttons werden durch den Style nicht mehr korrekt in der Größe angepasst. Bedeutet ein Create von einem Button zur Laufzeit hat die "normalen" Dimensionen. Daher passt der rechte Rand nicht, wenn man die Width nicht entsprechend setzt.

Mavarik

Möglicher Threadtitel für Antworten in Fett?

[Rollo62]

Hallo Mavarik,

ja, guter Vorschlag.
Würde ich "Best Practices: " für jeweils verschiedenste Themen nennen.
- Arbeiten mit Styles
- Arbeiten mit ImageList
- Arbeiten mit DataModules
- etc. etc.

Wenn in der Diskussion am Ende ein optimaler Weg rauskommt wäre es doch super.
(nicht nur für Anfänger, auch als CheckListe für Profis die mal 6 Monate an anderen Themen waren.)

Rollo

[Dejan Vu]

Na ja. "Best Practices" für "Umschiffung von Bugs" passt aber auch nicht so, oder?

[mensch72]

(nur nebenbei: Ob "Best Practices" oder "Umschiffung von Bugs" ist doch egal, Hauptsache es macht (dann) was es soll... Wer nur volle Funktion OutOfTheBox akzeptiert ist hier falsch)

fangen wir bei der (virtuellen)"Hardware" Konfiguration an:
- wegen der vielen VM's emphielt sich ein Microsoft ActionPack, da sind genug Windows und Serverlizenzen sehr kostengünstig drin und sehr oft mit gleicher Serial in VM's aktivierbar
- wegen der OSX-Lizenz: man habe einen "großen" Mac mit 2+ Bildschirmen und genug Resourcen für zwei bis 3 aktive 4GB-RAM VM's (wegen Mac im Mac besser "VMwareFusion" als "Parallels")
- (auch wenn es ein OSX-Lizenzverstoß ist, ja es geht dann auch ein guter WindowsPC mit VMwareWorkstation als "Alternativhost" für die MAC/OSX-VM's "im Notfall")
- verschiedene OSX-VM's mit unterschiedlichen OSX/XCode/SDK Varianten/Versionen (für die aktuellsten Sachen ist das Apple AutoUpdate super, aber für Nachvollziehbarkeit und Archivierbarkeit schalten wir es aus und können so auch jetzt problemlos per VM zwischen IOS7.1 und IOS8.3 Konfigurationen wechseln, weil wir im BasisMAC kein Xcode nutzen, sondern dies nur per MacVM installieren)
- verschiedene WIN-VM's mit unterschiedlichen Windows Versionen und Setups
- verschiedene WIN-VM's mit unterschiedlichen Delphi Versionen mit jeweils verschiedenen Konfigurationen


kommen wir zur Delphi-(Grund)Installation an:
- niemals mehr wie eine Delphi-Installation in einer VM (bzw. bei Notebooks notfalls direkt im Haupt OS)
- ich installiere vom RadStudio Delphi separat in eine VM (für C-Builder Sachen nehme ich eine extra VM)
- ich sichere als Fehlermeldungsreferenz die "cleane" DelphiVM nach Install und Aktivierung
- ich deaktiviere (per RegPatch dem Namen einen Unterstrich hinzufügen) soviel mit installierte Addons und IDE Exts wie möglich (einschließlich der Refraktor/NET Sachen)
- cnPack wird installiert
- alles was es von Mr. Hausladen gibt, wird das installiert
- auch für Windows wird per PA Server ein externer "Client" separat installiert

dann zu Android:
- wegen dem NDK Zeug aktiviere ich die Android Sachen als "Default" im DelphiSetup, aber nach Install vor erstem Androidprojekt mache ich folgendes:
- AndroidStudio installieren und SDK-Path auf das Delphiverzeichnis zeigen lassen... da installiert sich erstmal das notwendigste dort automatisch
- manuell in die SDK Tools gehen und dort einiges "altes V4.03, V4.2, V4.4, V5.0x" nach Bedarf manuell installieren
- wir setzen lieber auf die alten Android SDKs, also am liebsten auf "ab" 4.03(meist wegen NFC) wenn das reicht oder "ab" 4.4(meist wegen BLE)
- dann im Delphi das "Default SDK" für Android erstmal exportieren und manuell mit Haare raufen sehen, was für eine Mischung aus SDK/NDK/... Verzeichnissen und Versionen da drin ist
- manuell sauber was für sagen wir SDK14, SDK19 und SDK21 editieren und separat zum "Import" abspeichern und dann im SDK Manager importieren
- "billige" Android Geräte ohne eigene Treiber unter 64Bit gingen bis Win7 auch mit gepatchten PID/VID's in den TreiberInfos.. ab Win8 weisen wir im Gerätemanger lieber "absolut manuell" den ADB-Treiber aus dem Verzeichnis vom Google Android SDK im Gerätemaneger ohne jegliche Änderung von USB PID's VID's hart zu... das funktioniert sogar bei der sehr widerspenstigen Sony SmartWatch3
- unter AndroidStudio ein DemoProjekt am besten aus dem INet laden, weil die Path's der unter Delhpi vom SDK Manger heruntergeladenen und installierten Demos oft schon so lang sind, das es zu den seltsamsten Fehlermeldungen im AndroidStudio kommt... wen man den DemoOrdner vom SDK Verzeichnis z.B. nach "C:/Android/Demos/.." verschiebt, dann gehen auch alle Demos... also nicht nur DelphiFMX hat installationsabhängige Macken, AndroidStudio auch;)
- für SmartWatches fehlen in XE7/XE8 in einer XML Definition die passenden vordefinierten Layouts und Auflösungen... man suche nach XE7+Moto360 und passe sich das dort gefundene selbst für seine Smartwatch wie z.B. die von Sony an
- man kontrolliere nochmal unter Delphi bei den SDK Sachen ob nirgends ein gelbes Ausrufezeichen ist und vergewissere sich seit XE7 das das Häckchen bei Splash/Hintergrund Bild weg ist (sonst doofer PAclient Error in allen Standardprojekten)
- Android Gerät in der VM zuweisen und schaun, ob beim Anstecken binnen 60sec es im AndroidDeviceTree als auswählbares Ziel erscheint, wenn ja Doppelklick zum aktivieren als Target und Bingo, nun kann es mit einem kleinen Testprojekt losgehen


- für OSX und für IOS fehlt mir jetzt selbst die Übersicht, weil das "Setup" erforscht&macht bei uns jemand anderes, aber ich bemühe mich auch da eine kleine Zusammenfassung unserer dann recht stabilen Umgebung zu beschreiben

[BUG]

Zitat:

Zitat von Dejan Vu (Beitrag 1301685)

Na ja. "Best Practices" für "Umschiffung von Bugs" passt aber auch nicht so, oder?

Workaround ist das gesuchte Wort ... hab ich was gewonnen? :lol:

[mensch72]

Zitat:

Zitat von BUG (Beitrag 1301694)

Zitat:

Zitat von Dejan Vu (Beitrag 1301685)

Na ja. "Best Practices" für "Umschiffung von Bugs" passt aber auch nicht so, oder?

Workaround ist das gesuchte Wort ... hab ich was gewonnen? :lol:

Gewinnen kannste hier was, wenn du deine "Workarounds" nicht für dich behältst, sondern hier teilst:)

Threads was alles nicht geht und für "ungelöste Probleme" gibt's genug... eventuell ist es ja möglich mal hier nur reale Lösungen zu verschiedenen FMX relevanten Sachen zu listen,
und ganz wichtig dies eben mal ohne "offene" Fragen oder Frust mit Lösungen("Workarounds") zu vermischen.

[Harry Stahl]

Ich möchte einen kurzen Beitrag bringen zu dem, was ich gerade eben gelernt habe:

Ich habe für mein VCL-Programm (PixPower) mit XE7 ein kleines FMX-Hilfsprogramm geschrieben, welches von einem mobilen Gerät (derzeit nur Android) ein gerade gemachtes Photo oder ein Photo, das der User aus der Foto-Bibliothek auswählt, an das Desktop-Programm überträgt. Das Programm basiert auf dem Photowall-Demo-Programm, das EMBA im Tethering-Ordner mitliefert.

Beispiel ausprobiert, alles läuft. Prima. In mein PixPower-Programm integriert:

Läuft zwar...

... aber nur, wenn die beiden Tethering-Komponenten bereits zum Programmstart aktiviert sind. Das könnte man zwar machen, finde ich aber doof, wenn beim Programmstart schon direkt die Firewall angeht.

Nach einigem Suchen habe ich herausgefunden: Habe, wie früher so üblich beim Start des Programms im Oncreate-Event der Mainform dem

Delphi-Quellcode:

"Application.OnMessage := AppMessage" zugewiesen.

Keine Ahnung warum, aber das war der Grund, warum eine nachträgliche Aktivierung der Tethering-Komponenten (eben erst dann, wenn ich einen Empfangsdialog aufrufe) nicht funktioniert. Bringt anscheinend die Kommunikation durcheinander. Workaround war, die Nachrichten, die ich bislang in der eigenen AppMessage-Procedure verarbeitet habe, in einer TApplicationEvents-Komponente (da in "OnMessage") verarbeite.

Danach funktionierte alles wie gewünscht.

Ach ja, anscheinend wird für App-Tethering die volle RTTI-Funktionalität benötigt, das hier musste ich deaktivieren:

Delphi-Quellcode:

{$weaklinkrtti on}
{$rtti explicit methods([]) properties([]) fields([])}

Das "fertige" Hilfsprogramm kann man sich bei Interesse hier mal ansehen: http://youtu.be/5MDKZI06w4g (Dauer: 2 Minuten)
Bei Gelegenheit werde ich das Programm noch erweitern und die ab XE7 bestehende Übertragungsmöglichkeit per Bluetooth ergänzen.

[himitsu]

TApplicationEvents wurde gerade dafür eingeführt, weil man davon mehrere Instanzen haben kann und sich nicht gegenseitig überschreibt.

Leider hat man TApplicationEvents nicht intern verdrahtet, sondern es ebenfalls wieder auf diese Events gehen lassen (auch wenn alle Instanzen sich über einen gemeinsamen Handler dort registrieren), aber dennoch geht es jetzt immernoch kaputt, wenn irgendwe sich direkt bei diesen Events registriert und dann z.B. die Events anderer TApplicationEvents schrottet, so wie du es wahrscheinlich gemacht hast.

[Harry Stahl]

Und dann gleich noch ein Tipp hierzu: bei der Action "TakePhotoFromCameraAction1" steht MaxWdith und MaxHeight jeweils als Vorgabe auf 1024. Das heißt, Eure Bilder werden runter skaliert übertragen, das geht natürlich zur Lasten der Qualität.

Ich habe hier die Werte jetzt auf 8000x6000 geändert, das sollte momentan für jede Mobile Kamera reichen. Leider stehen die Werte 0 x 0 nicht dafür, dass jede Größe übertragen wird. Wenn ich irgendwann mal die App weiter ausbaue, kann man da natürlich noch eine Reihe von Usereinstellungen vorsehen.

[Rollo62]

Hallo Dejan vu,

wenn "Best Practices" nicht gefällt, dann eben "Polyfill".
So nennen die Javascriptler das um zum gewünschten Ergebnis zu kommen ...

Rollo