Der Witz ist erstmal, dass du unbedingt einen Setter brauchst, auch wenn NextButton und BackButton nicht von außerhalb geändert werden dürfen.
Aber damit das Property vom
DFM-Reader/Writer behandelt wird, ist das leider nötig.
Man könnte den Setter hier einfach leer lassen,
und ich würde hier im Setter auch nichts machen, außer bei NewValue<>OldValue eine
Exception werfen zu werfen, falls irgedwer im Code doch mal was zuweisen will.
Und dann mußt du bei deinen Unterkomponenten auch
SetSubComponent aufrufen,
denn sonst denkt der
DFM-Writer es wäre ein "Link", ähnlich den Links für DataSet oder PopupMenu, wo die Eigenschaften der Komponenten ja wo anders gespeichert sind.
Delphi-Quellcode:
FNextButton := TMyButton.Create(Self);
FNextButton.SetSubComponent(True);
Ist dir schonmal aufgefallen, dass Property manchmal andere Farben haben?
Dieses zeigt z.B. ein derartiges Speicherverhalten an. (bei vererbten Forms stimmt die Anzeige nur nicht immer)
Public NextButtonClick?
Willst du diese Events wirklich in der
DFM gespeichert haben?
Besser Sicherer wäre es diese Events nicht an Button.OnClick zu hängen, was man z.B. im Property-Editor dann ändern könnte
und dein internes Event dann nicht mehr funktioniert.
Im Button sollte es eine Click- oder DoClick-Methode geben, worin das OnClick-Event aufgerufen wird.
Diese Methode kannst du überschreiben und darin das Ereignis "direkt" in deine Klasse weiterleiten.
Entweder ein zurätzliches eigenes Protected-OnMyClick-Event in den TMyButton einbauen, wo sich den TKalender anhängt,
oder diese Methode direkt aus dem Button
(Owner as TKalender).DoButtonClick(Self)
.
Also zwei Methoden in TKalender oder eine Methode, die über den Sender/Parameter erkennt welcher Button es ist.