Hi Himitsu,
danke für's mitdenken.
"Wenn du im Code (z.B. Button-Click) auf den Property/Setter zugreifst, dann ist es True?"
-> dann ist das FALSE, und man kann über SetShowpts(const Value: tshowOpts_UA) hier den SubRichEd ein und ausschalten.
Nur bei der Initialisierung, nach TSimpTestRich_UA.Create(AOwner:TComponent);overrid e;,wenn danach automatisch eine Eigenschaft nach der anderen über die Setter eingelesen wird, ist dort (csloading in ComponentState) TRUE.
Aber dein Hinweis ist schon richtig: Erst wenn alles gelesen ist, sollte man den Rest initialisieren.
Delphi-Quellcode:
protected
{ protected declarations }
procedure Loaded;override;// nun wieder versteckt
...
procedure TSimpTestRich_UA.Loaded;
begin
inherited;
setReadyForTmp(FReadyForTmp);//die anderen Komponenten initialisieren
SetShowpts(FShowOpts);
end;
... so ich den unbedingt die Setter so nutzen will - die Warnung habe ich schon verstanden.
Finde ich aber praktisch: Man kann über FShowOpts:tShowOpts_UA; und dessen Setter die Kompenenten ein und ausschalten.
Diese Komponenten bekomme ich sogar in der
IDE und im Objekt-Inspektor zu sehen, wenn ich die entsprechende Option anklicke (ShowOpts:=[ShowSubRichEd_UA, ...] oder setReadyForTmp:=true) an der Stelle, wohin ich sie in ihrem Create hinrechne.
Komponenten mit Feld kann ich sogar im Objekt-Inspektor editieren (z.B. Left, Top), die Änderungen werden aber nicht übernommen - logisch - läuft ja über Create.
Und man kann viel Unfug mit solchen Settern anrichten: Habe zum Test im Objekt-Inspektor in die Eigenschaft "SubRichEd" einen auch auf dem Desktop liegend TrichEdit eingebunden - das geht auch, und man kann diesen Richedit auch nutzen, aber wehe, man löscht in der
IDE diesen Richedit mal schnell weg - dann kann man das Programm nicht mehr compilieren noch den SubRichEd vom Desktop nehmen, noch das Delphi mit speichern beenden. Mußte dann händisch aus der *.dfm die störenden Objekte (SubrichEd und Richedit) entfernen,
um wieder normal starten zu können.
"Entweder Self.Name niemals für SubKomponenten verwenden, oder diese Namen immer mit synchronisieren"
und hier war ich der irrigen Ansicht, daß, wenn ich mehrere TSimpTestRich_UA's auf den Desktop lege, es zu Namensdopplungen kommen kann - ist aber nicht so, da das nur beim Owner nicht passieren darf, Parent(hier tForm) ist das egal.
"oder diese Namen immer mit synchronisieren" heißt ? self.Name unbedingt selbst festlegen?
Grüße Uwe