Der Grund ist saubere
OOP:
Der Sinn, ein Property namens "Parent" anzubieten ist, Dir einen immer funktionierenden Weg zu geben, das Parent eines Controls zu setzen. Intern ruft das Control seine Setter-Methode "SetParent" auf und nimmt die nötigen Schritte vor. Wenn der Programmierer des Controls (mußt nicht Du sein) sich entscheidet, eine andere Setter-Methode für das Property "Parent" zu implementieren, stehst Du da und änderst Deinen gesamten Code. Dem Programmierer des Controls ist kein Vorwurf zu machen, solange er das Property "Parent" am Leben läßt - er geht davon aus, daß alle Zugriffe auf dieses erfolgen und nicht auf die Objektinterne Setter-Methode.
Spielt für
VCL-Controls nicht so die Rolle (da relativ selten geändert), aber wenn Du eigene Controls entwickelst, oder Fremdcontrols nutzt, solltest Du Dich strikt an die Benutzung der Properties und nicht der internen Setter-Methoden halten, weil auch das geht:
Delphi-Quellcode:
TNewClass = class(TWinControl)
private
function GetMyNewParent:TControl;
procedure SetMyNewParent(Value:TControl);
public
property Parent read GetMyNewParent write SetMyNewParent;
end;
implementation
function TNewClass.GetMyNewParent:TControl;
begin
Result := inherited Parent;
end;
procedure TNewClass.SetMyNewParent(Value:TControl);
begin
// hier macht er irgendwas Lebenswichtiges oder verrücktes
// und dann:
inherited Parent := Value;
end;
Wenn Du dann:
TNewClass.SetParent(TControl);
statt:
TNewClass.Parent := TControl;
aufrufst wird es knallen.
Gruß