hier muß auf das Feld zugreifen (weil nur-Lese-Properties nichts zugewiesen werden darf)
Ist auch vollkommen richtig.
Ich persönlich nutze innerhalb einer Klasse auch vorzugsweise nicht deren Property, sondern geht direkt auf die Felder.
(abgesehn dort, wo es einen Setter gibt und ich nicht die Setter-Methode direkt aufrufen möchte/kann)
Property sind für mich also "nur" externe Schnittstellen.
Tipp: Siehe Lines eines TMemo oder Items einer TListBox.
Ja, Lines verfügt zwar über einen Setter, aber dort ist quasi eine Assign-Methode dahinter versteckt.
Es wird also nicht die Komponenten-Variable (das Feld) überschrieben, sondern es werden nur die Eigenschaften des übergebenen Objektes an das interne Objekt übertragen.
Aber vorallem wird intern möglichst immer nur eine Variante verwendet.
Zitat:
Delphi-Quellcode:
FcheckC:=tcheckbox.Create(self);// hier muß auf das Feld zugreifen (weil nur-Lese-Properties nichts zugewiesen werden darf)
checkC.Caption:='C';
checkC.top:=checkb.top+15;
InsertControl(checkC);
fcheckc.SetSubComponent(true);
also entweder
Delphi-Quellcode:
FcheckC:=TCheckBox.Create(self);
FcheckC.Caption:='C';
FcheckC.Top:=FcheckB.Top+15;
InsertControl(FcheckC);
FcheckC.SetSubComponent(true);
oder
Delphi-Quellcode:
FcheckC:=tcheckbox.Create(self);// geht eh nicht ander
checkC.Caption:='C';
checkC.Top:=checkB.Top+15;
InsertControl(checkC);
checkC.SetSubComponent(true);
Zusärtlich macht sich eine einheitliche Schreibweise (inkl. der Groß-/Kleinschreibung)
IMHO irgendwie besser ... Code ist dadurch meißt übersichlicher.
Und Refactoring macht sich mit solchem Code bestimmt auch besser. (wenn Zusammengehörendes gleich heißt)