QualityCentral

Public Report

Report From: Delphi-BCB/RTL/Delphi [ Add a report in this area ]

Report #: 109194

Status: Open

Real valued, Int64, string properties have hard coded default values

Project: Delphi

Build #: ALL

Version: 17.0

Submitted By: David Heffernan

Report Type: Basic functionality failure

Date Reported: 10/1/2012 1:40:34 PM

Severity: Serious / Highly visible problem

Last Updated: 10/1/2012 7:45:08 PM

Platform: All platforms

Internal Tracking #: 32382

Resolution: None (Resolution Comments)

Resolved in Build: : None

Duplicate of: None

Voting and Rating

Overall Rating: (2 Total Ratings)

5.00 out of 5

Total Votes: 26

Description

Real valued, Int64, string properties have hard coded default values.  Quite possibly some of the other supported published types have hard coded default properties.

For example consider real valued types.  A property of real valued type, cannot be annotated with a default value.

property Value: Double read FValue default 0.0;//does not compile

Now, I'm not going to comment on whether or not such types should support default values being defined.

The problem is that the streaming framework assumes a default value of 0 that cannot be changed by the coder.  If the property has a value of 0 when the object is streamed to file, then nothing is written for the property.  Just as if we had defined a default value.

This is a huge problem if we don't want 0 to be the default value.  Because when we stream the object back in, the constructor will assign the true non-zero default value to the property.  Then, because the property value was omitted when streaming out, that non-zero default is the value at the end of the streaming in process.  But we wanted 0.

To summarise.  Suppose that we have a real valued property, with non-zero default (i.e. non-zero value assigned in the constructor).  Then we cannot successfully round-trip a value of 0 to and from the .dfm file.

The same issue arises for Int64 and string properties.  And also I suspect for method and variant properties.

Steps to Reproduce:

---------------
type
  TMyComponent = class(TComponent)
  private
    FValue: Double;
    procedure WriteValue(Writer: TWriter);
  protected
    procedure DefineProperties(Filer: TFiler); override;
  public
    constructor Create(AOwner: TComponent); override;
  published
    property Value: Double read FValue write FValue;
  end;

constructor TMyComponent.Create(AOwner: TComponent);
begin
  inherited;
  FValue := 1.0;
end;
---------------

Now register the component and drop one onto a form.  Note that Value is 1.  Now change Value to 0 in the Object Inspector.  Save the file, close the form and then re-open it.  Now Value is equal to 1.

This all stems from IsDefaultPropertyValue in the Classes unit. Inside that function is this local function:
---------------
function IsDefaultFloatProp: Boolean;
var
  Value: Extended;
begin
  Value := GetFloatProp(Instance, PropInfo);
  if AncestorValid then
    Result := Value = GetFloatProp(Ancestor, PropInfo)
  else
    Result := Value = 0;
end;
---------------
It seems pretty clear to me that this function should be implemented like this.
---------------
function IsDefaultFloatProp: Boolean;
var
  Value: Extended;
begin
  Value := GetFloatProp(Instance, PropInfo);
  if AncestorValid then
    Result := Value = GetFloatProp(Ancestor, PropInfo)
  else
    Result := False;
end;
---------------

The code for the other types (Int64, string etc.) is similar.

This is not a regression.  This behaviour has, I believe, been present for ever.

Workarounds

None

Attachment

None

Comments

None

Developer Tools

Database Tools