@HolgerX
Hallo, danke für die Antwort.
hmm ... im Prinzip weiß ich daß, aber im Trial and Error habe ich gesehen, daß beim Löschen der Listen-Variablen
im FUNKTIONIERENDEN BEISPIEL (Propertys direkt in tform gelegt) die Properties zum Schluß auch Nil waren:
Delphi-Quellcode:
if assigned(list.items[0]) then
begin
list.items[0].free; //freeandnil(list.items[0]) geht nicht Es wird hier FormRiched.free gerufen
{list.items[0]:=nil;} //auch wenn ich den Listen-Eintrag nicht Nil setze
end;
ist FormRiched (oder FormMemo) hier schon NIL!
ICH WEISS NICHT; WER DAS MACHT!
Auch wenn ich den Listeneintrag NICHT Nil setze.
Den Listeneintrag muß ich Nil setzen, um bei einer erneuten Listen-Nutzung dort dann nicht in einen nur scheinbar assigned Listeneintrag zu greifen.
Im PROBLEMFALL wird ja ein ähnliches Konstrukt angewendet, nur das OwnRichEd und OwnMemo nicht das tForm als Eigentümer haben, sondern z.b. ein anderes Trichedit. Parent von den beiden Own-Komponenten wird erst gesetzt, damit sie sichbar werden im tForm.
Beim Löschen über die Liste
Delphi-Quellcode:
if assigned(TestRich_UA1.OwnControlList.items[0]) then
begin
TestRich_UA1.OwnControlList.items[0].free;
TestRich_UA1.OwnControlList.items[0]:=nil;
end;
wird zwar hier wohl z.B. Ownriched.free, damit Ownriched zerstört, aber eben nicht Nil gesetzt.
Heißt für mich leider, daß es wohl nichts wird, aus einer Liste heraus Properties zu löschen (GEHT) und Nil zu setzen (GEHT NICHT).
Die Hoffnung war, dies mit einer eleganten for-to-Schleife über die Listeneinträge zu schaffen statt z.B. so
Delphi-Quellcode:
case so of
ShowOwnRichEd_UA: if free then FreeAndNil(FOwnRichEd) else if assigned(ownriched) then ownriched.hide;
ShowOwnMemo_UA: if free then FreeAndNil(FOwnMemo) else if assigned(OwnMemo)then OwnMemo.Hide;
end;
hat sich da wohl erledigt.
Und dennoch - warum geht das bei Properties auf der Form?
Guß Uwe