|
FMX - Kenne die Fehler für ein einfacheres Arbeiten.
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? |
AW: FMX - Kenne die Fehler für ein einfachere Arbeit.
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 |
AW: FMX - Kenne die Fehler für ein einfachere Arbeit.
Na ja. "Best Practices" für "Umschiffung von Bugs" passt aber auch nicht so, oder?
|
AW: FMX - Kenne die Fehler für ein einfachere Arbeit.
(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 |
AW: FMX - Kenne die Fehler für ein einfachere Arbeit.
Zitat:
|
AW: FMX - Kenne die Fehler für ein einfachere Arbeit.
Zitat:
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. |
AW: FMX - Kenne die Fehler für ein einfachere Arbeit.
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:
Das "fertige" Hilfsprogramm kann man sich bei Interesse hier mal ansehen:
{$weaklinkrtti on}
{$rtti explicit methods([]) properties([]) fields([])}  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. |
AW: FMX - Kenne die Fehler für ein einfachere Arbeit.
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. |
AW: FMX - Kenne die Fehler für ein einfachere Arbeit.
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. |
AW: FMX - Kenne die Fehler für ein einfachere Arbeit.
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 |
AW: FMX - Kenne die Fehler für ein einfachere Arbeit.
[DCC Fataler Fehler] Beispiel.pas(592): F2084 Interner Fehler: AV0F612DEC-R00000048-0
Bedeutet übrigens nichts anderes als "out of Memory"... > 1GB. Also IDE neu starten und noch mal compilieren... Mavarik PS:Also ca. bei jedem 3. 2. Versuch... [EDIT] |
AW: FMX - Kenne die Fehler für ein einfachere Arbeit.
Zitat:
http://www.delphipraxis.net/185121-f...ml#post1301814 |
AW: FMX - Kenne die Fehler für ein einfachere Arbeit.
XE8 zeigt noch mehr Fehler als XE7... Ich verzweifele gerade..
Die Width einer Listbox hat unter Andoid den Wert -0,00004xxx wenn die Listbox zwar auf dem Formular liegt, aber auf einem Tab das noch NIE dargestellt wurde. [EDIT] ist so nicht ganz richtig... Es muss noch etwas anderes hierfür gesetzt sein... Ich werde berichten. Unter iOS & Windows funktioniert es, aber unter Android nicht mehr! Das gleiche gilt auch für eine Label der noch nicht angezeigt wurde. Hiermit kann man nicht mehr MeasureText aufrufen. (Nur Android) Mavarik |
AW: FMX - Kenne die Fehler für ein einfacheres Arbeiten.
Spass mit dem iPad!Ganz geil... Aus der Kategorie: Macht man ja auch nicht... gegeben sein eine "Hello-World-EMBT-Button App"...
Delphi-Quellcode:
Dann bitte das iPad im Landscape-Modus halten und wundern...
procedure TForm65.FormCreate(Sender: TObject);
begin Application.ProcessMessages; end; Mavarik :coder: PS.: iOS 8.3 / XE8 Hotfix 1 / Xcode 6.3.1 Keine Ahnung welches update das bewirk... Ist neu weil ich hatte das schon seit Monaten so drin... |
AW: FMX - Kenne die Fehler für ein einfacheres Arbeiten.
Die ohne i-Produkte dürfen sich nicht wundern :(
|
AW: FMX - Kenne die Fehler für ein einfacheres Arbeiten.
Zitat:
|
AW: FMX - Kenne die Fehler für ein einfacheres Arbeiten.
Auch in der VCL macht das Spaß.
Hier knallte es öfters, weil TComport das aufruft, was ganz blöde ist, wenn es im OnClose/OnDestroy der Form passiert, die Form dabei vorzeitig verschwindet und nachfolgende Zugriffe auf die Form nicht mehr das machen können, was sie machen wollten. |
AW: FMX - Kenne die Fehler für ein einfacheres Arbeiten.
Zitat:
Grund im
Delphi-Quellcode:
vom Datenmodul wird auch ein DB Update durchgeführt. Und im
OnCreate
Delphi-Quellcode:
-Abschnitt vom Update war ein
finally
Delphi-Quellcode:
Ich hätte den Fehler sonst NIE gefunden. Also danke!!!
Application.ProcessMessages;
Gruß Philip |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 09:34 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz