Record-Member kann nichts zugewiesen werden?

[mh166]

Hallo Leute,

ich steh ein wenig auf dem Schlauch: ich habe einen Record definiert und diesen einer Klasse inkl. zugehöriger Eigenschaft (r/w!) zugewiesen. Wenn ich in meinem Code jetzt über diese Eigenschaft die Member des Records beschreiben will, geht das schief.

Lange Rede, kurzer Code:

Delphi-Quellcode:

  TVanitySettings = record
    Number: String;
    PIN: String;
    Password: String;
  end;

  TSettings = class
    // ...
    procedure loadSettings;
  private
    FVanity: TVanitySettings;
  public
    property Vanity: TVanitySettings read FVanity write FVanity;
  end;

// ...

procedure TSettings.loadSettings;
var
  Ini: TIniFile;
begin
  Ini := TIniFile.Create(FSettingsPath);

  Vanity.Number   := Ini.ReadString('0700', 'Nummer', '');
  // ..
end;

Jetzt bringt mir der Compiler nun bei der Zuweisung des gelesenen Strings die Fehlermeldung:

Zitat:

Zitat von Compiler

[DCC Fehler] uVanityManagerCommon.pas(67): E2064 Der linken Seite kann nichts zugewiesen werden

In der Hilfe hab ich schon geschaut, und die war der Meinung, dass die Meldung sich auch auf Member von Records bezieht, sofern diese als read-only Eigenschaft deklariert sind. Ist aber ja bei mir nicht der Fall. :gruebel:

An sich kein großes Thema: greife ich direkt auf das Feld, statt auf die Eigenschaft zu, dann kann ichs natürlich problemlos befüllen. Aber das Ganze interessiert mich nun doch: wieso mag der Compiler den Code nicht?

Vielleicht hat ja einer eine Erleuchtung für mich und ich lern wieder mal was spannendes dazu. Oder ich hab mich einfach zu doof angestellt. Wäre auch möglich. :stupid:

Grüße,
mh166

[Sir Rufo]

Das ist bei Records halt so, denn beim Zuweisen einer Record-Eigenschaft (oder einem Feld) wird automatisch eine neuer Record erzeugt.

Das hier würde funktionieren

Delphi-Quellcode:

procedure TSettings.loadSettings;
var
  Ini: TIniFile;
  LVanity : TVanitySettings;
begin
  Ini := TIniFile.Create(FSettingsPath);

  LVanity.Number := Ini.ReadString('0700', 'Nummer', '');

  Vanity := LVanity;
  // ..
end;

Am wenigsten Stress hast du, wenn du anstatt eines Records eine Klasse nimmst

Delphi-Quellcode:

TVanitySettings = class
private
  FNumber: String;
  FPIN: String;
  FPassword: String;
public
  property Number : string read FNumber write FNumber;
  property PIN : string read FPIN write FPIN;
  property Password : string read FPassword write FPassword;
end;

  TSettings = class
    // ...
    procedure loadSettings;
  private
    FVanity: TVanitySettings;
  public
    constructor Create;
    destructor Destroy; override;
    property Vanity: TVanitySettings read FVanity;
  end;

// ...

constructor TSettings.Create;
begin
  inherited;
  FVanity := TVanitySettings.Create;
end;

destructor TSettings.Destroy;
begin
  FVanity.Free;
  inherited;
end;

procedure TSettings.loadSettings;
var
  Ini: TIniFile;
begin
  Ini := TIniFile.Create(FSettingsPath);

  Vanity.Number := Ini.ReadString('0700', 'Nummer', '');
  // ..
end;

[Bummi]

Nachdem Sir Rufo den korrekten Zugriff bereits erklärt hat, bleibt mir noch eine gegf. denkbare Alternative anzubieten

Delphi-Quellcode:

  public
    Vanity: TVanitySettings; // statt einer property
  end;

[mh166]

Auf die DP ist eben Verlass. :) Danke euch beiden! :thumb:

In der Tat wieder was gelernt. Wusste nicht, dass jedes mal ein neuer Record erzeugt wird. In diesem Fall werde ich wohl der Einfachheit halber den Record als Public definieren. Ist ja meines Erachtens nach vom Speicherverbrauch doch um einiges genügsamer als eine Klasseninstanz. Oder täusch ich mich mal wieder? Zumindest spar ich mir aber Tipperei mit dem Create der Klassen. ;)

Oder gibt es gravierende Nachteile, an die ich mal wieder nicht denke, wenn ich hier weiter bei meinen Records bleibe?

Grüße,
mh166

[Sir Rufo]

Ja, du hast die Eigenschaften der Klasse nicht so unter Kontrolle.
(Du machst aus der Eigenschaft ja auch jetzt ein public Field und das ist dann völlig unkontrolliert und hat dir spätestens beim MultiThreading um die Ohren).

Bei einer Eigenschaft kann man über die Getter/Setter so einiges veranstalten und den Zugriff sehr schön regeln.

[mh166]

Okay, also gehts wirklich nur um die Getter/Setter. Na gut, das is mir bewusst. In dem konkreten Fall stellt das aber kein Problem dar: weder muss irgendwas verifiziert werden noch ist hier Thread-Sicherheit notwendig.

Aber ich werde das auf jeden Fall für die Zukunft im Sinn behalten.

Nochmals: Danke! :)