tstrings property

[arturx]

Eine Komponente soll eine property tstrings haben.
Also habe ich einfach den untenstehenden Code geschrieben und in ein package eingebaut.
Nach Eintrag von Werten in die Subcaptions mittels OI zeigt sich folgendes Verhalten :

1.die Einträge sind beim nächsten Aufruf nicht mehr da
2.die Komponente verursacht einen streamerror :
kann Form nicht streamen: tform1
path to failes instance
tform1.test1

Code: Alles auswählen

type ttest = class(tcomponent)
  private
      vsubcaptions : tstrings;
  public
     constructor create(aowner : tcomponent);   override;
     destructor  destroy;                       override;
  published
     property subcaptions : tstrings read vsubcaptions write vsubcaptions;
end;
 
constructor ttest.create(aowner: tcomponent);
begin
      inherited create(aowner);
      vsubcaptions   := tstringlist.create;
end;
 
destructor ttest.destroy;
begin
  vsubcaptions.free;
  inherited destroy;
end;

Was habe ich übersehen ? Oder ist es ein Lazarus Problem ?

[theo]

Nur mal ne Frage: Wieso deklarierst du das im Interface als TStrings und nicht als TStringList?
Createn tust du ja auch eine TStringList.

[arturx]

Wieso deklarierst du das im Interface als TStrings und nicht als TStringList?.

Der Unterschied wirkt sich nicht aus :

1.Das eigentliche Object wird im Constructor erstellt und zugewiesen.
2.die Variable stellt nur einen Pointer da.
-tstrings ist in diesem Fall die unterste persistente Klasse,
die alle für mich evt. weiter nötigen Methoden ohne Typcasting zur Verfügung stellt : die meisten Komponenten machen es genauso.
(Trotzdem hatte ich es auch probiert: leider wie zu erwarten ohne Erfolg)
Auf alle Fälle: vielen Dank für den Beitrag !

[arturx]

Nun habe ich die Lösung :
der propeditor versucht der Stringlist die geänderten Werte mitzuteilen.
Dabei assigned er nicht die Liste, sondern überschreibt gnadenlos die Variable vsubcaptions
(Alle anderen Variablen würde er ja auch überschreiben).
Also ist Handarbeit gefragt :

Code: Alles auswählen

type ttest = class(tcomponent)
  private
      vsubcaptions : tstrings;
  protected
      procedure setSubcaptions(avalue : tstrings); // Neu
  public
     constructor create(aowner : tcomponent);   override;
     destructor  destroy;                       override;
  published
     property subcaptions : tstrings read vsubcaptions 
                                    write setsubcaptions; // Neu
end;
 
constructor ttest.create(aowner: tcomponent);
begin
      inherited create(aowner);
      vsubcaptions  := tstringlist.create;
end;
 
procedure ttest.setSubcaptions(avalue : tstrings); 
      begin vsubcapcreated.Assign(Value);   // !!!!! 
     end;                                        
 
destructor ttest.destroy;
begin
  vsubcaptions.free;
  inherited destroy;
end;

Dieses Forum ist irgendwie magic :

Ideen, die tagelang nicht kommen wollen, werden -wie auch immer- unbewusst getriggert.....

[theo]

Ja, diesen Vorschlag wollte ich auch soeben machen.
Komponenten zur IDE Integration fit machen hat schon ein paar Tücken.

[Socke]

Warum lässt du überhaupt eine Zuweisung auf die Eigenschaft zu? Die ist unnötig und führt zu Irritationen, da im Normalfall eine solche nicht nötig ist und durch Assign() umgangen werden kann.

[arturx]

Warum lässt du überhaupt eine Zuweisung auf die Eigenschaft zu? Die ist unnötig und führt zu Irritationen, da im Normalfall eine solche nicht nötig ist und durch Assign() umgangen werden kann.

?? Nun bin ich etwas ratlos : Wie kann ich die Zuweisung verhindern, wenn ich die Eigenschaft published brauche (wegen OI) ??
HIlf mir bitte auf die Sprünge .....

[Socke]

Warum lässt du überhaupt eine Zuweisung auf die Eigenschaft zu? Die ist unnötig und führt zu Irritationen, da im Normalfall eine solche nicht nötig ist und durch Assign() umgangen werden kann.

?? Nun bin ich etwas ratlos : Wie kann ich die Zuweisung verhindern, wenn ich die Eigenschaft published brauche (wegen OI) ??
HIlf mir bitte auf die Sprünge .....

Inwiefern der Objetkinspektor bzw. die RTTI allgemein einer TStrings-Eigenschaft etwas zuweisen können muss, weiß ich nicht. In der LCL wird aber zumindest in TCustomMemo und TCustomListBox auch nur ein Assign() ausgeführt.
Zum Verhindern allgemein: eine published-Eigenschaft benötigt nicht zwingend eine write-Methode.

[arturx]

Warum lässt du überhaupt eine Zuweisung auf die Eigenschaft zu? Die ist unnötig und führt zu Irritationen, da im Normalfall eine solche nicht nötig ist und durch Assign() umgangen werden kann.

1.Irgendeine Zuweisbarkeit mittels write muss vorhanden sein, damit der OI die Werte der Stringlist übergeben kann

2."Assign" in einer Zuweisungsmethode statt direkter Zuweisung war natürlich die Lösung. (s.o.)
Mein ursprünglicher Irrtum bestand darin zu erwarten,
dass der OI automatisch ein assign durchführen würde und nicht, dass er den Zeiger auf die Stringlist überschreibt.

[Socke]

Warum lässt du überhaupt eine Zuweisung auf die Eigenschaft zu? Die ist unnötig und führt zu Irritationen, da im Normalfall eine solche nicht nötig ist und durch Assign() umgangen werden kann.

1.Irgendeine Zuweisbarkeit mittels write muss vorhanden sein, damit der OI die Werte der Stringlist übergeben kann

2."Assign" in einer Zuweisungsmethode statt direkter Zuweisung war natürlich die Lösung. (s.o.)
Mein ursprünglicher Irrtum bestand darin zu erwarten,
dass der OI automatisch ein assign durchführen würde und nicht, dass er den Zeiger auf die Stringlist überschreibt.

Solange immer die Zuweisung funktioniert und ich mein Objekt danach wieder freigeben muss, wäre ja alles in Ordnung. Ich kann aber oft nicht erraten, was richtig ist.

[Patito]

Warum lässt du überhaupt eine Zuweisung auf die Eigenschaft zu? Die ist unnötig und führt zu Irritationen, da im Normalfall eine solche nicht nötig ist und durch Assign() umgangen werden kann.

1.Irgendeine Zuweisbarkeit mittels write muss vorhanden sein, damit der OI die Werte der Stringlist übergeben kann

Das übergeben von Werten an die Stringlist hat aber überhaupt nichts mit dem write in der Property zu tun.
Beim write in der Property geht es nur darum die Stringlist selber komplett durch ein anderes Objekt zu ersetzen.
Und das sollte man hier auf keinen Fall erlauben.

[arturx]

Das übergeben von Werten an die Stringlist hat aber überhaupt nichts mit dem write in der Property zu tun.
Beim write in der Property geht es nur darum die Stringlist selber komplett durch ein anderes Objekt zu ersetzen.
Und das sollte man hier auf keinen Fall erlauben.

Ich habe das auch einmal probiert (analog in der folgenden coedzeile) :

Code: Alles auswählen

property items read vitems;

Das Ergebnis war, dass dann keine Werte mehr in die Eigenschaft geschrieben wurden.
Probiers mal aus, vielleicht habe ich ja irgendetwas übersehen.
Ich glaube, dass write jedesmal aufgerufen wird, wenn der dazugehörige property-editor etwas in die property schreiben will.
In diesem Fall muss er halt "zu Fuß" per write methode überzeugt werden, dass er nicht die Variable selbst überschreiben soll
(könnte in einem anderen Fall evt. auch mal sinnvoll sein), sondern dass er dem Object, auf das die Variable zeigt,
Werte zuweisen soll : eben per assign