SortedList oder iDictionary in Delphi (ohne .net!)

[rollstuhlfahrer]

Objekte kann man sich wie Integer mit Zusatzfunktionen vorstellen. Ändert man jetzt eine der Zusatzfunktionen, so ändert sich die Zahl, die der Integer repräsentiert nicht. Aber auf die Zahl kommt es an. Diese Zahl ist nämlich ein Pointer auf den Speicherbereich des Objektes. Wenn du also in einer Liste alle Einträge das selbe Objekt (also die gleiche Objektinstanz) zuweist, verweisen alle Listeneinträge auf die selbe Speicherstelle. Änderst du diese Speicherstelle, gilt das neue sofort für alle Listeneinträge (Speicherstelle = Kiste; Änderung in der Kiste => Griff in die Kiste bringt nur das neue zu Tage).

Bernhard

PS: Bei Records bin ich mir nicht ganz sicher, wie das da abläuft, aber bei Objekten brauchst du in jedem Fall für jeden Eintrag ein neues.

[himitsu]

Zitat von rollstuhlfahrer:

PS: Bei Records bin ich mir nicht ganz sicher, wie das da abläuft, aber bei Objekten brauchst du in jedem Fall für jeden Eintrag ein neues.

Ist der Record direkt eingebunden, dann hat jedes seinen eigenen Speicherbereich.

Wenn man einen Pointer auf einen Record nutzt, dann ist es wie beim Objekt.

PS: Ein Objekt ist auch nur ein Zeiger (wie du schon erkannt hast) auf einen "Record" mit Zusatzinfos.

[Chemiker]

Hallo Berlinermauer,

Zum Beispiel:

Delphi-Quellcode:

unit DemoComboBoxMitObjecte;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, ExtCtrls;

type
  TmyClass= Class(TObject)
  private
    FEintrag2: Integer;
    FEintrag1: String;
    procedure SetEintrag1(const Value: String);
    procedure SetEintrag2(const Value: Integer);
  public
    constructor Create;
    destructor Destroy; override;
    property Eintrag1: String read FEintrag1 write SetEintrag1;
    property Eintrag2: Integer read FEintrag2 write SetEintrag2;
  End;

type
  TfrmDemoComboBoxMitObject = class(TForm)
    CobMitObject: TComboBox;
    edEintrag1: TLabeledEdit;
    edEintrag2: TLabeledEdit;
    procedure FormCreate(Sender: TObject);
    procedure CobMitObjectChange(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  frmDemoComboBoxMitObject: TfrmDemoComboBoxMitObject;

implementation

{$R *.dfm}

{ myClass }

constructor TmyClass.Create;
begin
  inherited;
end;

destructor TmyClass.Destroy;
begin

  inherited;
end;

procedure TmyClass.SetEintrag1(const Value: String);
begin
  FEintrag1 := Value;
end;

procedure TmyClass.SetEintrag2(const Value: Integer);
begin
  FEintrag2 := Value;
end;

{ Programm }

procedure TfrmDemoComboBoxMitObject.CobMitObjectChange(Sender: TObject);
begin
  edEintrag1.Text:= TmyClass(CobMitObject.Items.Objects[CobMitObject.ItemIndex]).Eintrag1;
  edEintrag2.Text:= inttostr(TmyClass(CobMitObject.Items.Objects[CobMitObject.ItemIndex]).Eintrag2);
end;

procedure TfrmDemoComboBoxMitObject.FormCreate(Sender: TObject);
var
  oMyObject1: TmyClass;
begin
  oMyObject1:= TmyClass.Create; // Erste Object erzeugen
  oMyObject1.Eintrag1:= 'Das ist der erte Eintrag';
  oMyObject1.Eintrag2:= 10001;
  CobMitObject.Items.AddObject('Item1',oMyObject1);

  oMyObject1:= TmyClass.Create; // Zweites Object erzeugen
  oMyObject1.Eintrag1:= 'Das ist der zweite Eintrag';
  oMyObject1.Eintrag2:= 20002;
  CobMitObject.Items.AddObject('Item2',oMyObject1);
  CobMitObject.ItemIndex:= 0;
end;

procedure TfrmDemoComboBoxMitObject.FormDestroy(Sender: TObject);
var i: integer;
begin
  for i:=CobMitObject.Items.Count -1 downto 0 do
  begin
    TmyClass(CobMitObject.Items.Objects[i]).Free;
  end;
end;

end.

Bis bald Chemiker

[Berlinermauer]

OK, das heißt, ich kann nicht einfach den Objekt-Wert ändern, sonder muss es neu erzeugen.
Kommt da nicht ein Fehler wenn ich es nicht vorher Free or Destroyed habe?

Delphi-Quellcode:

// MyClass1.MyClass2 : Das ist mein Object. Der Grund warum ich MyClass2 und nicht MyRecord nutze, ist dass AddObject annscheinend keine Records mag?!

function GetWindows(Window: THandle; blah):blah; // Wird von Enumerate Windows aufgerufen
begin
// blah blah
MyClass1.Myclass2.Window := Window;
MyClass1.Myclass2.PID := Blah;

List.AddObject('Mein String für das Fenster', MyClass1.MyClass2);
end;

d.h. es wird bei jedem aufruf lediglich die Property geändert.
d.h. ich brauche am anfang destroy und create oder?
Wie kann ich übrigens prüfen ob schon created wurde? Assigned(Myclass1.Myclass2)?

Edit: Jap klappt, einfach neu "drübercreaten" und vorher ein destroy

[rollstuhlfahrer]

Zitat von Berlinermauer:

OK, das heißt, ich kann nicht einfach den Objekt-Wert ändern, sonder muss es neu erzeugen. Kommt da nicht ein Fehler wenn ich es nicht vorher Free or Destroyed habe?

Nein, es kommt kein Fehler. Du erzeugt ja nur ein "Speicherleck", welches du am Ende aber wieder aufräumst.

Zitat von Berlinermauer:

Der Grund warum ich MyClass2 und nicht MyRecord nutze, ist dass AddObject annscheinend keine Records mag?!

Frage am Rande: Geht TObject(myRecord)??

Zitat von Berlinermauer:

vorher ein destroy

Nein, vorher KEIN Destroy. Du willst doch die Infos haben. Wenn du sie vor dem Auslesen wegwirfst, hast du nichts gewonnen.

Warum nimmst du eigentlich ein Property von MyClass1? Wenn du MyClass2 erzeugst, kannst du MyClass2 die Werte zuweisen und sie der Stringliste hinzufügen. Die Verwendeung von MyClass1 irritiert mich etwas.

Bernhard

[Berlinermauer]

Zitat von rollstuhlfahrer:

Zitat von Berlinermauer:

Der Grund warum ich MyClass2 und nicht MyRecord nutze, ist dass AddObject annscheinend keine Records mag?!

Frage am Rande: Geht TObject(myRecord)??

Das habe ich noch nicht Probiert, werde ich mal tun

Zitat von rollstuhlfahrer:

Zitat von Berlinermauer:

vorher ein destroy

Nein, vorher KEIN Destroy. Du willst doch die Infos haben. Wenn du sie vor dem Auslesen wegwirfst, hast du nichts gewonnen.

Nein, ein Destroy vor dem Erneuten Create, d.h. wenn das Object schon in der String Liste ist, wird es zerstört und neu created. Ich könnte es auch am ende zerstören, aber da ich das object noch anderseitig brauche, geht das nicht.

Delphi-Quellcode:

procedure blah; // Wird nen paar mal aufgerufen
begin
Object.Destroy;
Object := TObject.Create;
Object.Zuweißung := '1';

List.AddObject('Object1',Object);
end;

Und so findet das ein paar mal statt.

Zitat von rollstuhlfahrer:

Warum nimmst du eigentlich ein Property von MyClass1? Wenn du MyClass2 erzeugst, kannst du MyClass2 die Werte zuweisen und sie der Stringliste hinzufügen. Die Verwendeung von MyClass1 irritiert mich etwas.
Bernhard

Ganz einfach weil myClass1 das property Myclass2 auch benötigt.
Konkret benötigt es den vom User ausgewählten ComboBox Eintrag, die ich im obigen Beispiel grade eintrage.

Und warum nicht gleich myClass2: Myclass1 verändert die Daten von Myclass2 noch ein wenig, deshalb.

Übrigens: In Delphi soll es (offiziell) keinen 64Bit Unsigned Integer geben, kann ich doch irgendwie einen zaubern?

[rollstuhlfahrer]

Zitat von Berlinermauer:

Nein, ein Destroy vor dem Erneuten Create, d.h. wenn das Object schon in der String Liste ist, wird es zerstört und neu created. Ich könnte es auch am ende zerstören, aber da ich das object noch anderseitig brauche, geht das nicht.

Bitte was willst du? Wenn du ein Objekt, was sich in der Liste befindet löschst, ist es auch nicht mehr in der Liste. Und: Es wird keine Fehlermeldung kommen.

Bernhard

[xZise]

Moin,

Zitat von Berlinermauer:

[...]Nein, ein Destroy vor dem Erneuten Create, d.h. wenn das Object schon in der String Liste ist, wird es zerstört und neu created. Ich könnte es auch am ende zerstören, aber da ich das object noch anderseitig brauche, geht das nicht.[...]

Mal nicht so abstrakt:
Wenn du sowas hast:

Delphi-Quellcode:

var
  x : THaus;
begin
  x := THaus.Create;
  x.Free;

Dann erstellst du ein Haus und speicherst du Adresse wo das Haus ist in x. Danach nimmst du die Adresse und sagst: Da wo das Haus ist gebe das Frei (= zerstöre es).

Jetzt hast du sowas:

Delphi-Quellcode:

var
  x, y : THaus;
begin
  x := THaus.Create;
  y := x;
  x.Free;

Dann ist erstmal alles gleich. Aber gleichzeitig kennt y auch die Adresse vom Haus. Das heißt in x und y stehen die gleichen Adressen. Wenn du jetzt aber x.Free; aufrufst, dann wird das Haus was an der Adresse x steht zerstört. Und damit auch das Haus was bei y drin steht, weil beide ja auf die gleiche Adresse zeigen.

Das heißt y und x sind sozusagen gleich und du hast keinen Unterschied. Du könntest sagen: y.maleAn(Grün) und auch das Haus auf das x zeigt ist danach grün.

Und so was ähnliches machst du ja. Nur das y halt in der Liste steht: In der Liste stehen die Adressen aller Häuser, aber leider zerstörst du die meisten Häuser nachdem du sie erzeugt hast.

Was du anstelle machen kannst:

Delphi-Quellcode:

var
  x, y : THaus;
begin
  x := THaus.Create; // Erstellt Haus 1 und speichert die Adresse in X
  y := x; // Speichert die Adresse die in X steht (= die von Haus 1) in der Adresse Y
  x := THaus.Create; // Erstellt Haus 2 und speichert die Adresse in X (in Y steht aber weiterhin die alte Adresse)
  x.Free; // Gibt das Haus das an der Adresse, die in X steht frei

Hier hast du zwei Häuser die nicht die gleiche Adresse haben. Das heißt das erste Haus steht weiterhin, während das zweite Haus zerstört ist.

Das bezeichnet man als Aliasing bzw. Alias.

Übrigens benutze nicht direkt x.Destroy; sondern x.Free; oder FreeAndNil(x) .

Und wie du das dann mit den freigeben erledigst musst du sehen:
Eventuell bietet dir die Liste an, die Objekte selber freizugeben (.OwnObjects auf true setzen), ansonsten kannst du auch selber eine zweite Liste haben in der alle Elemente drin stehen die auch mit OwnObjects = true die Elemente freigibt.

MfG
Fabian

[Chemiker]

Hallo Berlinermauer,

Zitat:

Edit: Jap klappt, einfach neu "drübercreaten" und vorher ein destroy

Wenn Du das Object noch brauchst, braucht vorher kein destroy ausgeführt werden, sondern nur ein neues Opbect erzeugen und mit Daten belegen.

Das ganze sollte eigentlich auch mit Records gehen. Dafür ist es notwendig auf den Record ein Zeiger zu legen und dann den Zeiger speichern.

Bis bald Chemiker

[Berlinermauer]

Also TObject() oder Ptr() ist eine Ungültige Typumwandlung