FireMonkey Sammelthread

[Sir Rufo]

Ich habe zwar nicht dieses aber ein Verhalten beobachtet, was wohl die gleiche Ursache hat.

Beim TGrid wollte ich eine Spalte immer so breit machen, dass die gesamte Gridbreite ausgefüllt ist.
Eigentlich ganz einfach: Kleine procedure und im Resize Event des TGrid diese aufrufen.

Aber denkste, das funktioniert nicht immer (eher öfter nicht), allerdings wird das Ereignis zuverlässig aufgerufen jedoch teilweise bevor die Änderungen wirklich stattgefunden haben.

Seltsam, ist aber so ...

Meine Lösung dafür heisst nun, dass ich im Resize Event einen IdleEvent auslöse und der wird erst dann ausgeführt, wenn die Anwendung in den Idle Zustand geht - analog zum TApplicationEvent.OnIdle, nur wird mein Event nur einmal ausgelöst.
Und schon funktioniert es zuverlässig.
(Eigentlich ist das schon fast Holzhammer, aber wer hilft hat erst mal recht )

[Unx]

Zitat von Sir Rufo:

(Eigentlich ist das schon fast Holzhammer, aber wer hilft hat erst mal recht )

Für mich hört sich das eher an..... was zu verwenden was man nicht verwenden sollte!

[stahli]

Ich arbeite an einigen FMX-Controls bzw. versuche das.

Irgendwie finde ich die FMX-Controls im Allgemeinen unnötig kompliziert aufgebaut.
Z.B. werden ín einem Header die Items in der Childrenliste gespeichert und dann anhand der Classe herausgesucht.
Das Hinzufügen von Einträgen funktioniert zwar, aber die Breite passt nicht immer und wird erst bei einer Größenänderung des Parent aktualisiert.
Dass AddObject neue Einträge vor dem automatischen ersten Eintrag "addiert" werden ist nicht dokumentiert.
Realign ist nicht öffentlich.

Von der oder anderer Sorte gibt es an allen Ecken Probleme bzw. (für mich) Unklarheiten.
Ohne jetzt Details ausdiskutieren zu wollen hätte ich mir das ganze Framework irgendwie übersichtlicher und klarer strukturiert erhofft.

Seht Ihr das auch so (insb. beim Arbeiten an eigenen Controls)?

[greenmile]

Willkommen im Club

[Darlo]

Zitat von stahli:

Im Formular reicht ein Timer, der ein Invalidate ausführt.

Delphi-Quellcode:

procedure TForm1.Timer1Timer(Sender: TObject);
begin
  Invalidate;
end;

Danke, das hat mir geholfen Memos und Stringgrids die zur Laufzeit nicht angezeigt wurden (ein Klick auf die Position hat die Komponente dann angezeigt) zu lösen!

[Sir Rufo]

Zitat von Unx:

Zitat von Sir Rufo:

(Eigentlich ist das schon fast Holzhammer, aber wer hilft hat erst mal recht )

Für mich hört sich das eher an..... was zu verwenden was man nicht verwenden sollte!

Hast ja recht, FireMonkey ist noch Beta und sollte daher in Produktivlösungen nicht verwendet werden ... manchmal kann man aber nicht anders und dann muss man die Bugs eben irgendwie wegbügeln

[stahli]

@Darlo

Ok, das ist schon mal eine hilfreiche Info.

Kannst Du das Problem reproduzierbar und in verständlichem Englisch in der QC beschreiben?
(Für mich ist das schwierig, weil ich mich mit dem Englisch schwer tue und an einem komplexen Framework arbeite, so dass das Problem nicht problemlos reproduzierbar wäre.)

(roter Kasten hatte Urlaub)

[Union]

Zitat von stahli:

Ok, das ist schon mal eine hilfreiche Info.

Hattest Du nicht mal gesagt, EMB würde eine "echte" FMX Anwendung zur Verfügung stellen? Was ist damit? Hast Du Feedback?

[stahli]

Das war mein Wunsch, ein reales und nutzbares Beispiel mit den LiveBindings zu sehen: http://www.delphipraxis.net/171665-e...moprojekt.html
David I hatte eine entsprechende Demo versprochen, reagiert aber nicht mehr auf Nachfragen.

Inzwischen ist mir das egal, da ich an einem eigenen Framework (als Alternative zu den LiveBindings) arbeite. Die Ansätze finde ich vielversprechend.
Hier habe ich das mal angesprochen: http://www.delphipraxis.net/172249-d...ml#post1196272
U.a. baue ich gerade an einem eigenen Grid (abgeleitet von einem Panel, also wirklich ein eigenes), das sich dann an diverse Datenmengen binden lassen soll (Listen und DataSets). Gleiches für eine ListBox.

FM2 finde ich nicht schlecht, wenngleich noch nicht ganz ausgereift und an einigen Stellen nicht ganz nachvollziehbar und zu umständlich.
Die Style-Funktionalität finde ich nur bedingt sinnvoll um eigene Controls zu bauen. Ich finde es meist sinnvoller, eigene Controls klassisch aufzubauen da man so besser in´s Detail gehen kann.

[greenmile]

Ich denke man kann es auf den Punkt bringen: Bräuchte ich Firemonkey für Multiplattform (Mac, Android und co) nicht, könnte ich getrost drauf verzichten und es keine Sekunde meines Lebens vermissen. An anderer Stelle habe ich mich auch schon ordentlich zu den Styles geäußert: Wer sich so einen Blödsinn hat einfallen lassen ... Versuch doch mal, einen Style zu wechseln, wenn Du schon eigene Änderungen drin vorgenommen hast. Und zack ... is' alles weg.