Genau dann "liegt ein Defekt in der Architektur" vor.
Die Aussage ich zu generell... Aber genau darum geht es ja...
Mit FreeAndNIL ist es "egal".
Ich finde, das sollte der Entwickler schon wissen.
Theoretisch richtig.... Mit - sagen wir mal - 50 Komponenten auf einem Form die OnExit, OnEnter und ggf. noch mit SetFocus arbeiten... Wer kann da schon ohne debug Ausgaben sagen, was in welcher Reihenfolge kommt.
Wäre nicht das 1. mal, dass ich hier von der Reihenfolge überrascht wurde.
Ich bleibe dabei dass das generell (nicht prinzipiell) gilt.
Wenn man nicht weiss aber auch wenn man weiss in welcher Reihenfolge Events kommen - entweder
a) erzeugt man das Objekt in der Methode und gibt die abgesichert durch try finally in der Methode auch wieder frei.
b) Wenn man die Daten übergreifend benötigt, dann erzeugt man das Objekt bei der Erzeugung des Forumlars und gibt es bei der Zerstörung des Formulars wieder frei.
c) benutzt man (so wie ich meistens) nur Objekte mit Referenzählung.
Nachschlag:
1. Bei der Benutzung von TStringlist "liegt ein Defekt in der Architektur" vor - meistens.
2. Bei 50 Komponenten auf einem Form "liegt ein Defekt in der Architektur" vor - meistens.
Das gilt natürlich nicht für Stellen, an denen nil explizit als Flag für "nicht zugewiesen" verwendet wird, das also so gedacht ist. Dann darf man es natürlich nirgends an solchen Stellen weglassen oder vergessen (was bei mehreren Personen, die am Quelltext arbeiten, auch problematisch sein kann). Das klang jetzt aber nicht so, als ob das gemeint ist.
