Forms & ARC "spielereien"

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

[Mavarik]

Zitat von 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.

Tja das ist aber auch nur ein Workaround!

Hab jetzt - auf Olaf's Rat - mal das Form mit Release freigegeben...

Das sieht recht gut aus...

Fenster mit Show anzeigen und danach über einen Fensterhandler wieder schliessen...

Also ein weiteren Test in einer For-Schleife!

so ab dem 25. Form.Show und Close über einen Fensterhandler wird der iPhone Bildschirm zwischen durch schwarz
und der Show kommt immer verzögerter... bei 35 Form Show#s: Exception in System.pas in _DbgExcNotify

Also das war es auch noch nicht...

Mavarik

[Sir Rufo]

Ich denke jetzt einfach mal laut:

Ein iOS Device ist ja nun mal kein MultiWindow-Anzeiger, sondern es wird immer nur eine View angezeigt.

Daraus ergibt sich, dass jede View als Singleton implementiert werden könnte/angesehen werden kann. Die anzuzeigenden Daten übergibt man der View mit einem ViewModel und lässt die View anzeigen.

Die Views müssen dabei nicht direkt alle beim Start erzeugt werden, aber wenn einmal erzeugt, dann immer wieder verwenden.

Einen Controller gebaut der das ViewModel bekommt, darüber die View auswählt und anzeigt.
Damit kann dann auch die nette Zurück-Funktion implementiert werden

[Mavarik]

Zitat von Sir Rufo:

Ich denke jetzt einfach mal laut:

Ein iOS Device ist ja nun mal kein MultiWindow-Anzeiger, sondern es wird immer nur eine View angezeigt.

Daraus ergibt sich, dass jede View als Singleton implementiert werden könnte/angesehen werden kann. Die anzuzeigenden Daten übergibt man der View mit einem ViewModel und lässt die View anzeigen.

Die Views müssen dabei nicht direkt alle beim Start erzeugt werden, aber wenn einmal erzeugt, dann immer wieder verwenden.

Einen Controller gebaut der das ViewModel bekommt, darüber die View auswählt und anzeigt.
Damit kann dann auch die nette Zurück-Funktion implementiert werden

OK gebe ich Dir 100%ig Recht!

Frei nach dem Motto... Lass die Form's doch rumgammeln... Der nächste App-Kill Event vom iOS wird es richten...

Mavarik

[arnof]

So ich habe es mal getestet und alles geht wie man es gelernt (war mal beim Forumschef in einer Schulung zu iOS ....):

zuerst die zu erzeugende Form:

Code:

type
  TFM_Debug = class(TForm)
    Label1: TLabel;
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  FM_Debug: TFM_Debug;

implementation

uses unit1;

{$R *.fmx}

procedure TFM_Debug.FormCreate(Sender: TObject);
begin
 Label1.Text:=self.Name;
 Form1.Memo1.Lines.Add('Create '+Label1.Text);
end;

procedure TFM_Debug.FormDestroy(Sender: TObject);
begin
 Form1.Memo1.Lines.Add('Destroy '+Label1.Text);
end;

Nun das Hauptfenster mit der Debugausgabe:

Code:

uses Unit2;

var FDebug : array of TFM_Debug;

{$R *.fmx}

procedure TForm1.Button1Click(Sender: TObject);
 var i:integer;
begin
 FDebug:=nil;
 SetLength(FDebug,Trunc(SpinBox1.Value));
 for I := 0 to length(FDebug)-1 do begin
  FDebug[i]:=TFM_Debug.Create(self);
 end;
 Button1.Enabled:=False;
 Button2.Enabled:=True;
end;

procedure TForm1.Button2Click(Sender: TObject);
 var i:integer;
begin
 for I := 0 to length(FDebug)-1 do begin
  FDebug[i].Close;
  FDebug[i].Release;
 end;
 Memo1.Lines.Add('alle released now Nil');
 FDebug:=nil;
 Button1.Enabled:=True;
 Button2.Enabled:=False;
end;

Im Screenshot seht man das der Destory erst kommt, wenn ich das Array indem ich die Forms ablegt = nil setzte , vorher nicht, da noch eine Refernz darauf besteht

[Sir Rufo]

@arnof

Aber so hast du das bestimmt nicht bei Cheffe gelernt (s. Form1 )

[arnof]

Zitat von Sir Rufo:

@arnof

Aber so hast du das bestimmt nicht bei Cheffe gelernt (s. Form1 )

war ja für könner mit viel bla bla zu ARC, den ich erstmal keine große Beachtung Geschenk hatte, aber wie es so ist, dann fliegt einem der Kram um die Ohren ....

siehe

http://www.delphipraxis.net/174930-i...r-bug-arc.html