tpropeditors, objektinspektor,stringGrid

[arturx]

Die grids.tgridcolumns sollen erweitert werden, so dass zur Designzeit der jeweiligen Column ein spezifischer Editor zugeordnet werden kann.
Dabei soll die Editor-komponente im Objektinspektor als Objectproperty 1.wählbar und 2.danach editierbar sein.
Um das Ganze nicht zu sehr zu mixen, habe ich die vorhande grids.TgridColumn erweitert:

Code: Alles auswählen

type tnewcolumn = class(grids.tgridcolumn);
...
private
  veditchoice : string;
  veditobj : tpersistent;
published
   property editchoice : string read veditchoice write seteditchoice; { via picklist werden verschiedene editorTypen angeboten
                          und via seteditchoice created und veditobject zugewiesen}
   property editobj : tpersistent read veditobj write veditobj; 
end;
 

Das Ganze funktioniert zur designtime mit einem kleinen Manko:
Damit die Objectproperty nach der Wahl sichtbar wird, muss man im Objectinspektor die column verlassen
Also: 1.Columns anklicken 2.in die Column zurückkehren--> und voilà, das editobj ist sichtbar.
Meine Fragen:
1.gibt es eine Möglichkeit, den Objektinspektor zum Repaint/refresh/... zu veranlassen ?
aus den Propeditor heraus oder aus dem editobj ?
2.eine zusätzliche Frage : Objektproperties werden nur für Tpersistent-Objekte im Objectinspektor als solche behandelt.
Wie müsste der Propeditor aussehen, der z.B. abgeleitete Klassen auch als Objectproperty behandelt ?
bzw. wo ist der Propeditor definiert/registriert/..., der das tpersistent standard-Handling durchführt ?

[wp_xyz]

Dass du den neuen Spalteneditor in die Spalte packst, erscheint mir nicht in Ordnung, weil dieser zur Laufzeit überhaupt nicht mehr benötigt wird. Üblicherweise gibt es dafür Property- und Komponenten-Editoren, die speziell für jede Property / Komponente geschrieben werden, also hier für TNewColumn, und nur zur Designzeit verwendet werden. Schau dir z.B. die diversen Units in ideintf an. Leider ist das ganze ziemlich undokumentiert, und weil man direkt jedesmal Lazarus verändert, nicht einfach zu debuggen. Siehe auch die Kommentare in PropEdits ab ca Zeile 60 und in ComponentEditor ab ca Zeile 120.

Zu 1): Die Kommunikation mit dem Objektinspector erfolgt mit Hilfe eines PropertyEditorHook und dessen Methoden.

Zu 2): Ich glaube nicht, dass das möglich ist. Warum kannst du die Klasse nicht direkt von TPersistent ableiten? Die PropertyEditoren sind in Unit PropEdits, GraphPropEdits, DBPropEdits (und wahrscheinlich noch ein paar mehr) implementiert, alles im Verzeichnis components/ideintf.

[arturx]

1.

Dass du den neuen Spalteneditor in die Spalte packst, erscheint mir nicht in Ordnung, weil dieser zur Laufzeit überhaupt nicht mehr benötigt wird.

es wird ja weiter der vorhandene Spalteneditor verwendet, die Spalte wird nur um 2 properties erweitert.
Eine der beiden beiden soll zur Designzeit per Objektionspektor einstellbar (=definierbar) sein,
damit genau der Celleditor mit seinen eigenen properties genutzt werden kann, der zu der Spalte passt (datum, numeric,time,...etc)
Zur Laufzeit kann dann dieser so definierte und eingestellte Celleditor in grid.onselecteditor automatisch zugeordnet und genutzt werden.
(siehe z.B.: https://www.freepascal.org/~michael/art ... /grids.pdf)

2.

Die Kommunikation mit dem Objektinspector erfolgt mit Hilfe eines PropertyEditorHook und dessen Methoden.

ich fürchte, dass ich mich damit intensiver beschäftigen muss.
Ich hatte gehofft, das mit irgendjemand (quick & dirty ) sagen könnte,
welcher Aufruf ein refresh des Objectinspectors zur designtime auslöst.
(Egal ob der im property-editor oder in der componente aufgerufen werden müsste)

3.

Warum kannst du die Klasse nicht direkt von TPersistent ableiten?

Das mache ich auch und es funktioniert gut.
(Es hätte mir halt hin und wieder Typecasting und Typabfragen erspart)

Nun last but not least : Vielen Dank für die prompte Antwort !!!