property ComPortProperties: TStrings read FComPortProperty;
.
wenn du unbedingt write haben willst, dann implementier dieses als 'ne Assign-Methode,
Ist zwar eigendlich schon geklärt, daß man für die Lösung nicht unbedingt Tstrings benötigt, sondern ein Record verwenden kann. Aber ich möchte mal grundsätzlich auf das Thema TStrings als Property eingehen. Deinen Post, himitsu, habe ich mal als Aufhänger genommen. Könnte aber auch 2-3 anderes Posts Quoten, die ein Assign im Setter vorschlagen.
Im Zweifel weis man nicht, wie die Setter-Methode implementiert ist. Diese könnte eine Zuweisung einer Stringliste auf eine interne Variable sein (Interne Variable wurde dann z.B. nicht im Constructor instanziert), oder eben ein Assign auf eine bereits instanzierte Variable.
Daher gibt es bei mir die Konvention, daß eine interne bereits im Create instanzierte Stringliste nur über eine Function oder ein Readonly-Property zugreifbar ist.
property ComPortPropertys: TStrings read FComPortPropertys;
Delphi-Quellcode:
function ComPortPropertys: TStrings;
begin
result:=FComPortPropertys;
end;
Eine Stringliste, die im Objekt nicht instanziert wurde, die bekommt eine Getter UND eine Setter-Methode. Mit dieser Vorgabe weis ich genau, ob das Objekt die Zerstörung der übergebenen Stringlist übernimmt. Soll die Zerstörung der zugewiesenen Stringliste nicht vom Objekt übernommen werden, dann muss vorher ein NIL zugewiesen werden, oder es gibt ein Property mit dem namen OwnsStringlist. Gilt im übrigen nicht nur für Stringlisten, sonder für alle Objekte, die in einem Objekt zugreifbar sind.
Alles andere birgt die Gefahr eines Speicherlecks oder einer Schutzverletzung.