Weak Referenzen überlegungen...

[Mavarik]

Zitat:

Zitat von Sir Rufo (Beitrag 1284759)

Welche "Variable im Form"?

idR heisst ja nicht, dass es korrekt ist. Korrekt ist auf jeden Fall, dass Variablen (vor allem die für Instanz-Referenzen) die nicht lokal sind niemals auf einem ungültigen Wert stehen zu lassen. Selbst unter Nicht-ARC ist das schon immer der direkte Weg zu "Torte-Im-Auge" gewesen.

Ein

Delphi-Quellcode:

FSomeThing.Free

knallt und ist auch mit

Delphi-Quellcode:

if Assigned( FSomeThing ) then

nicht zu bändigen, wenn sich dort noch eine ungültige Referenz befindet. Lösen kann man das nur mit dem Setzen der Variablen auf

Delphi-Quellcode:

nil

und dafür wurde ja extra

Delphi-Quellcode:

FreeAndNil

eingeführt. Und das ist dann auch ARC-Safe.

OK - auch wenn das nicht die Frage war:

Eine lokale Variable geht i.d.R. gar nicht... Weil auf dem mobilen Gerät gibt es kein showmodal.

Aber es gibt einen Button oder ein ListElement oder was auch immer...

Darin steht:

MyForm := TMyForm.Create(Application);

Und MyForm ist aus der UMyForm.pas (Die Variable die automatisch definiert wird, wenn du ein neues Form an legst.

MyForm hat auch einen Button

In diesem Buttonclick steht.

Delphi-Quellcode:

MyForm2 := TMyForm2.Create(Application);
MyForm2.KillOldForm(Self);

Wenn Du jetzt in der KillOldForm ein FreeAndNIL aufrufst passiert überhaupt nix...
Da refcount 4 oder großer ist.

Mavarik

[Sir Rufo]

Das ist eine besondere Situation, da du beim Erzeugen das Lifetime-Management bewusst an eine andere Instanz übergibst. In diesem Fall musst du System.TObject.DisposeOf verwenden.

[Mavarik]

Zitat:

Zitat von Sir Rufo (Beitrag 1284770)

Das ist eine besondere Situation.

Siehst Du... Obwohl ich davon aus gehe, dass für eine App die mehr als eine - ich nenne das gerne - Klichmich.App ist das nicht besonders, sondern normal ist.

- Es gibt kein Showmodal
- Alle Fenster sind Maximized

Wenn Du also ein sinnvolles UI bauen willst hast Du mehr als 1 Form mit 2 Slide-ins
- Startmenue
- 1..n Programmteile
- Einstellungen
- Stammdaten
- Adresseingaben oder andere Daten

Du willst zwischen den Fenstern hin und her schalten können. Aber natürlich nicht alle Fenster permanent im Speicher halten.

Mavarik

[RWarnecke]

Zitat:

Zitat von Mavarik (Beitrag 1284785)

Wenn Du also ein sinnvolles UI bauen willst hast Du mehr als 1 Form mit 2 Slide-ins
- Startmenue
- 1..n Programmteile
- Einstellungen
- Stammdaten
- Adresseingaben oder andere Daten

Du willst zwischen den Fenstern hin und her schalten können. Aber natürlich nicht alle Fenster permanent im Speicher halten.

Bei so einer Aufgabenstellung habe ich dann lieber einen TabController genommen, auch gerne mal verschachtelt. Dabei hatte ich dann keine Sorgen mit dem freigeben von Fenstern. Einzigster Nachteil dabei ist, das ab einer bestimmten Anzahl von Tabs das ganze etwas unübersichtlich wird. Das gebe ich gerne zu. Aber mit dem TabController habe ich dann auch ein paar Slides hinbekommen, was mir mit Fenstern nie so richtig gelungen ist.

[Sir Rufo]

Wir driften vom Thema ab, aber das Konzept bei einer Mobil-App ist wohl durchaus eher eine MainForm mit einem TabControl, wo die einzelnen TabItems eigene Ableitungen von

Delphi-Quellcode:

TTabItem

sind, die dann ein spezielle Ableitung einer

Delphi-Quellcode:

TForm

in sich darstellen (und zwar wird von der Form-Instanz ein

Delphi-Quellcode:

TLayout

der Parent auf das TabItem gelegt).

Ein Frame wäre auch möglich, aber dann kann man zur Design-Time nicht zwischen den Target-Platformen umschalten und spezielle Layouts vorgeben.