Property's "stored" 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.

[himitsu]

Passend zum Default gibt es auch NoDefault, um einen zuvor deklarierten Default zu entfernen.

Delphi-Quellcode:

// Varianten mit Specifiers

property MyValue: Single read FMyValue write FMyValue nodefault stored GetMyValueStored;

property MyValue: Single read FMyValue write FMyValue default 5;  // das geht nicht, weil Single kein ordinaler Typ ist



// Varianten mit Attributen

[NoDefault]
property MyValue: Single read FMyValue write FMyValue stored GetMyValueStored;

[Default(5)]
property MyValue: Single read FMyValue write FMyValue;



// und auch Stored gibt es als StoredAttribute (aber muß ja nicht sein)

[NoDefault, Stored('GetMyValueStored')]
property MyValue: Single read FMyValue write FMyValue;

DefaultAttribute
NoDefaultAttribute
StoredAttribute


Und ja, das was man als Default deklariert hat, muß auch wirklich dem entsprechen, was der Default der Klasse ist, sonst hat man viel Spaß.


Aber gibt es überhaupt einen Default-Default?
Wenn kein Default angegeben wurde, was hier der Fall ist, dann ist es doch eigentlich ein "Fehler", wenn Delphi hier eigenmächtig "irgendeinen" einen Default verwendet.

[Uwe Raabe]

Zitat von himitsu:

Aber gibt es überhaupt einen Default-Default?
Wenn kein Default angegeben wurde, was hier der Fall ist, dann ist es doch eigentlich ein "Fehler", wenn Delphi hier eigenmächtig "irgendeinen" einen Default verwendet.

Ja, gibt es. Ist auch dokumentiert:

Zitat:

Für Real-, Zeiger- und String-Typen gilt der implizite default-Wert 0 bzw. nil und '' (leerer String).

[Renate Schaaf]

Geht es hier um float-properties? Der bug ist bekannt seit Delphi 1, wurde angemahnt, und kam zurück mit "as designed". Ray Lischner hat eine Lösung gefunden, ich poste hier mal den Teil einer Komponente für Delphi 1, der die Lösung beinhaltet und erklärt. Falls das nicht das Problem ist, nevermind.

Delphi-Quellcode:

...
  protected
  procedure ReadD2WorldXw(Reader: TReader);
  procedure WriteD2WorldXW(Writer: TWriter);
  procedure DefineProperties(Filer: TFiler); override;  
 
  published
  property D2WorldXW: extended read xwd2 write setxwd2 stored false;
  {Don't worry about the stored false in all of these. They get stored:
    see override of DefineProperties. The default storing process never
    writes a value 0 of a float property to the dfm-file and the default
    value set in the constructor is used instead. So if that default is
    <>0, a value 0 can never be set. Overriding DefineProperties fixes it
     (workaround by Ray Lischner).
    Stored false is used, so the property is not stored twice. (Thanks to
    Joe Herb for the tip)}

...

procedure TMathImage.ReadD2WorldXW(Reader: TReader);
begin
  xwd2 := Reader.ReadFloat;
end;

procedure TMathImage.WriteD2WorldXW(Writer:TWriter);
begin
  Writer.WriteFloat(xwd2);
end;

procedure TMathImage.DefineProperties(Filer: TFiler);
begin
  inherited DefineProperties(Filer);
  with Filer do
  begin
    DefineProperty('D2WorldXW', ReadD2WorldXW, WriteD2WorldXW, true);
  end;
end;

[himitsu]

Zitat:

Delphi 1

Damals gab es noch keine Attribute, somit war es standtardmäßig garnicht möglich für Floats einen Default zu definieren.
Seit 12 Jahren ist es aber möglich, womit es keinen Grund mehr gibt, für so einen Bug.

Zitat:

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

Jupp, und auch andersrum, wenn es Stored True ist, dann muß gespeichert werden. (in diesem Fall darf so ein Default niemals diese Angabe überschreiben, was man auch schon seit Delphi 1 hätte reparieren können)

[Stevie]

Zitat von himitsu:

Seit 12 Jahren ist es aber möglich, womit es keinen Grund mehr gibt, für so einen Bug.

Das ist kein Bug, das ist "Abwärtskompatibilität"

[Uwe Raabe]

Zitat von himitsu:

Jupp, und auch andersrum, wenn es Stored True ist, dann muß gespeichert werden. (in diesem Fall darf so ein Default niemals diese Angabe überschreiben, was man auch schon seit Delphi 1 hätte reparieren können)

Es war vermutlich einfacher die Dokumentation anzupassen.

[BigAl]

Delphi tut sich ja generell schwer mit Float Properties. Beinhalten einen Property einen Float, dann wird das übergeordnet Property im Objektinspektor generell als "changed" angezeigt. Unabhängig ob tatsächlich was geändert wurde:

2021-03-08 20_27_54-fnmProject - Delphi 10.4 - Main [Built].png

In dem Beispiel ist "AutoColorFactor" ein Single. Der Standardwert ist 1. TPointStyle sollte also nicht fett dargestellt werden...

Ich habe alle Eigenschaften meines aktuellen Projekts soweit möglich als Integer definiert. Auch wenn sie eigentlich als Floats sinnvoller wären. Das Projekt hat etwa 40 spezielle Klassen die von TPersistent abgeleitet und teilweise ziemlich verschachtelt sind. Des weiteren gibt es wieder Ableitungen von den Klassen die im Wesentlichen die Standardwerte neu definieren usw.. Irgendwann hatte ich die Faxen mit den Floats dann Dicke und habe vieles umgestellt. An allen Stellen ist das leider nicht so ohne Weiteres möglich...

Weitere Suchen im Internet haben ergeben, dass es sich tatsächlich um einen sehr alten Bug handelt (und ja, es ist definitiv ein Bug). Auch wenn dieser - wie schon geschrieben - seit langem existiert, sollte man mit diesem ja nicht in alle Ewigkeit leben müssen. Es handelt sich um ein bis zwei zentrale Stellen die korrigiert werden müssten. Bestehende Programm sollten damit eigentlich klarkommen. Embarcadero hat die letzten zwei Updates echt tolles abgeliefert (meine Meinung) und Delphi ist aktuell besser denn je. Es macht wieder richtig Spaß mit der IDE zu arbeiten...

In diesem Sinne

Alex