Hallo,
Vielen Dank!!!
Wie hast Du das heraus gefunden?
Ist das irgendwo dokumentiert? Oder ist das eher ein Bug?
Erst mal fand ich das komisch, dass das nicht geht, da ich sowas schon öfters gemach habe. Da du so ein schönes Beispiel angehangen hattest, dachte ich mir Kopf noch nicht wach aber für klickibunti reicht es. Fehler ließ sich auch schnell reproduzieren. Beim Blick auf den Sourcecode fiel mir erst mal noch nichts auf. Also musste ein funktionierendes Beispiel her. TMemo.Lines ist so ein Beispiel. Im TCustomMemo fiel mir sofort der Setter auf und da war der Kopf wach. Es ist doch quasi ein Gesetz:
Alle Properties deren Typ von TPersistent aber nicht von TComponent erbt, werden per Setter und Assign gesetzt!
Habe das auch schon mal anders gemacht und hab dann später über mich selbst geflucht. Und dann fehlte nur noch eine Begründung, wieso man das bei diesem Beispiel auch nicht anders machen darf. Da half ein Haltepunkt im Setter. Angehalten wurde nur nach dem Ok im Propertyeditor und Value zeigt tatsächlich auf ein anderes Objekt. Und meine Vermutung, dass dort als Objekt eine TMemo.Lines übergeben wird, kommt daher das es nur zwei sinnvolle Wege gibt wie man mit
Rtti so ein Proberty setzen kann.
1. Mit
Rtti holt man sich die Objektreferenz aus dem Property, Castet diese nach TPersistent und ruf Assign auf. Dann würde aber der Setter nicht getriggert.
2. Man baut ein Objekt welches von TStrings erbt und schmeißt per
Rtti die Referenz in den Setter. Und das wird im XE5 und XE8 (und vermutlich auch im XE10.2) so gemacht. TMemo war auch fast richtig. Der Typ von Value beim Ok im Propertyeditor ist tatsächlich TRichEditStrings.
Also aufgepasst bei published Properties mit Typen welche von TStrings erben.
einbeliebigername.