Forms & ARC "spielereien"

[Elfriede]

Wir sollte mal schauen, nach welchen Mustern das FMX-Framework sich verhält. Den kompletten Total-Ausfall, den Du da beschreibst, konnte ich so nicht nachvollziehen. Anbei der Lebens-Zyklus eines Child-Forms, das ich über eine Schaltfläche auf dem Haupt-Form aufgerufen habe:

Screen Shot 2013-07-01 at 21.20.34.png

Zumindest im Simulator - diese Einschränkung muss ich noch machen. Vielleicht kann ich meinem Mitbewohner nachher wieder sein iPhone klauen, dann kann ich es auch dort versuchen.


Elli

[arnof]

Hallo,

wenn Du dir mal den Projektquelltext anschaust, dann machen die die Forms so:


Application.CreateForm(TFormxyz, Formxyz);

Dann wird die Form wahrschein lich beim Destory des Applicationsobject kommen ....

Wenn Du natürlich 100 Forms hast, dann wird dies wahrscheinlich nicht gehen ....

Ich hatte mich mit dem Arc auch einwenig beschäftigt und gesehen, das der RefCount bei manchen Sachen nicht mit 1 erstellt wird sondern mit einer großen Zahl.

Also mal testen formxyz.Refcount ausgeben lassen!

[Stevie]

Zitat von arnof:

Hallo,

wenn Du dir mal den Projektquelltext anschaust, dann machen die die Forms so:


Application.CreateForm(TFormxyz, Formxyz);

Dann wird die Form wahrschein lich beim Destory des Applicationsobject kommen ....

Das stimmt nur für Forms, die man im Projekt als auto-create angegeben hat - Frank erzeugt das Form selber.

Generell wird ARC wohl ein kleines Problemchen mit so fire and forget Aktionen haben. Im ersten Beispiel müsste es schon knallen (bzw das Form sofort wieder geschlossen und freigegeben werden), wenn die lokale Variable die einzige Referenz wäre. Das Form wird angezeigt und danach die Routine verlassen (Show ist nicht blockierend). Das heißt also, irgendwo wird es eine Referenz auf das Form geben. Ich bin der Meinung, Beispiel 3 sollte das sein, was funktionieren sollte - die AV in der FMX.Platform.iOS sollte abgefangen werden (bzw nil safe implementiert werden).

[Mavarik]

Das Problem fängt ja damit an, dass nach einem

F := TForm.Create(NIL)

F.Refcount = 2 ist.

Achso...

Und beim "Klassiker"

F := TForm.Create(Application)

F.Refcount = 4 ist.


Mavarik

[Elvis]

Ich hätte eigentlich erwartet, dass "Show" den RefCount um einen erhöht, da es ja non-blocking ist.
Wenn man es mit Show gezeigt hat, sollte das Schließen den Zähler um 1 verringern.

Zumindest hätte ich das so angenommen. Wie soll das ja auch sonst funktionieren?
Wenn man es modal zeigt, dann sollte da nix passieren.

Wie es tatsächlich passiert? kA
Aber es ist irgendwo nicht schlecht, dass sich EMBT Gedanken macht, um ein bissel Garbage Collection zu erlauben. Denn mit dem alten Modell gab es ja die abstrusesten Konventionen um bloss keine Leaks zu erzeugen.

[Mavarik]

Zitat von Elvis:

Ich hätte eigentlich erwartet, dass "Show" den RefCount um einen erhöht, da es ja non-blocking ist.
Wenn man es mit Show gezeigt hat, sollte das Schließen den Zähler um 1 verringern.

Das Problem ist, wie soll man sauber alles free(n), wenn irgendwo versteckte Referenzen sind.

Show ändert (natürlich) nicht den RefCounter...

Das blöde ist, wenn man die Referenzen killt um alles sauber zu machen, greift Firemonkey immer noch an irgend einer Stelle auf das Formular zu
um noch eine Animation ab zu schließen oder was auch immer...

Und dann knallt es..

Mavarik

[Daniel]

Dann trenne Deine Business-Logik vom FMX-Framework. An einem Punkt X, an dem Deine App der Ansicht ist, das Formular könne weg, räumt sie alles, was sie selbst erzeugt hat, auch wieder ab und gibt den Rest an FMX zurück. Mehr kann man letztlich eh nicht tun und was dann übrig bleibt, kann nicht mehr gravierend viel Speicher kosten.