Property's "stored" bug...

[BigAl]

Hallo zusammen,

ich habe eben einen Bug entdeckt. Ich gehe mal davon aus, dass es so ist, habe auf jeden Fall mal einen case dazu aufgemacht: RSP-33237

Folgendes Problem:

Properties von Komponenten (abgeleitet von TPersistent) welche mit "stored" prüfen ob die Eigenschaft gespeichert werden soll werden nicht gespeichert wenn entweder die stored-Funktion "False" zurück liefert (ist korrekt) oder Wert der Eigenschaft "0" ist (das ist falsch). Das ist natürlich fatal, da im Falle von "0" beim nächsten laden wieder der vorgegeben Wert in der Variable steht...

Also: aufpassen

Oder habe ich was übersehen?

Gruß
Alex

[Stevie]

Das ist leider ein bisschen schäbig gelöst - das Kernproblem liegt in System.Classes.IsDefaultFloatProp - dort wird nämlich 0 immer als Standard betrachtet, auch wenn man explizit eine storedproc angegeben hat.
Allerdings kann man dort sehen, dass nach dem Default Attribut geschaut wird.

Lösung also:

[Default(5)] über die Eigenschaft schreiben und schon klappt es.

[himitsu]

Dann wird doch die 5, bzw. 5.0 nicht gespeichert?

Allerdings sollte das DEFAULT garnicht verwendet werden, wenn ein STORED angegeben ist, womit das ein Fehler wäre.



Und ja, das "normale" Default an Properties ist nur für ordinale Typen nutzbar (Byte bis Integer und Enums bzw. Sets)

Daher wurde schon vor Längerem das [Default]-Attribut hinzugefügt. (geht auch für Strings)


Und natürlich müssen Atttribute vor/über dem stehen, für was sie gelten.

[BigAl]

Ich denke das einzige was ich momentan machen kann ist die "stored" wegzulassen und somit die Properties immer speichern (außer sie sind 0). Sieht dann halt wieder im Objektinspektor doof aus wenn die alle fett sind obwohl die auf default stehen.

Vielleicht nimmt sich dem Bug bei Emba ja mal einer an. Meiner Meinung ist das ein Bug...

[Stevie]

Zitat von himitsu:

Dann wird doch die 5, bzw. 5.0 nicht gespeichert?

So isset, und so sollet - denn die storedproc sagte ja Result := not SameValue(FMyValue, 5.0);

Zitat von BigAl:

Ich denke das einzige was ich momentan machen kann ist die "stored" wegzulassen und somit die Properties immer speichern (außer sie sind 0). Sieht dann halt wieder im Objektinspektor doof aus wenn die alle fett sind obwohl die auf default stehen.

Vielleicht nimmt sich dem Bug bei Emba ja mal einer an. Meiner Meinung ist das ein Bug...

Eventuell hab ich mich zu verschwurbelt ausgedrückt, aber ich stimme dir zu, dass es ein Bug ist.
5 nicht speichern kann man abbilden, wie ich oben schrieb. Ich glaube, man kann dann sogar die storedproc ganz weglassen und einfach nur das Attribut nutzen.
Denke dann aber daran, diesen Wert auch im ctor explizit zu setzen.

[Rolf Frei]

Der Datentyp hat doch keinerlei Einfluss darauf, ob das Property gespeichert wird oder nicht. Wenn da "stored False" ist, darf überhaupt nichts gespeichert werden. Im DFM darf das Property dann überhaupt nicht vorhanden sein. Das ist die Funktion dieser Direktive. Auch der Defaultwert hat damit überhaupt nichts zu tun. Dafür gibt es "default X" und das entsprechende Zuweisen an das Feld im Create.

OP, ich sehe da nichts Falsches. Dass ein Property Integer 0 oder ein leerer String nicht gespechert wird, ist absolut richtig. Das sind ja die Anfangswerte auf die du deine Felder im Create initialisierst oder machst du das nicht? Dann ist der Fehler bei dir. Du solltest alle Felder in Create initialisieren.

EDIT:
Eventuell habe ich diene Frage falsch verstanden. Setzt du den einen default Wert beim Property? Also so...

Delphi-Quellcode:

property Abc: Integer read FAbc write FAbc default 5 stored IsStored;

TMyOvjet.Create...
begin
  FAbc = 5;
  inherited;
end;

In diesem Fall dürfte das Property nur dann nicht gepseichert werden, wenn es den Wert 5 hat oder IsStored False liefert. Verstehe cih das nun richtig, dass das Property auch nicht gespeichert wird, wenn es den Wert 0 hat. Das wäre dann in der Tat ein Bug, insofern dein Property so definiert ist wie oben in meinem Beispiel.

[Uwe Raabe]

Zitat von Rolf Frei:

Wenn da "stored False" ist, darf überhaupt nichts gespeichert werden.

Das wird ja auch gar nicht bemängelt.

Zitat von BigAl:

werden nicht gespeichert wenn entweder die stored-Funktion "False" zurück liefert (ist korrekt) oder Wert der Eigenschaft "0" ist (das ist falsch)

Das Problem ist hier offenbar, dass stored True zurück liefert, aber trotzdem nichts gespeichert wird, wenn der aktuelle Wert 0 ist. Insofern liegt es schon am falschen (impliziten) Default-Wert.

Es ist aber wohl kein Bug, denn das entspricht zumindest der Dokumentation:

Zitat:

Wenn sich der aktuelle Wert einer Eigenschaft von ihrem default-Wert unterscheidet (oder kein default-Wert vorhanden ist) und stored True ist, wird der Wert gespeichert. Treffen diese Bedingungen nicht zu, wird der Wert nicht gespeichert.

[Sinspin]

An einigen Stellen nutzen DevExpress und mittlerweile auch Emba ein weiteres Property "AssignedValues" um zwischen Defaultwert und zugewiesenem Wert zu unterscheiden.
Das wird leider noch nicht konsequent durchgezogen.

Das ist ein Bitset das einen Eintrag pro Property hat. Trägt man einen Wert in ein Property ein, geht das passende Bit auf true. Setzt man es wieder auf false ist das Property wieder default.