SortedList oder iDictionary in Delphi (ohne .net!)

[Chemiker]

Hallo Berlinermauer,

Zitat von Berlinermauer:

Ja könnte sein, aber was ist daran falsch?

Wenn alle Einträge gleich sein sollen ist daran erst mal nichts falsch.

Zitat von Berlinermauer:

Wie müsste es richtig lauten?

1. Neues Object erzeugen
2. Daten dem neuen Object zuweisen
3. Object mit AddObject anhängen.

Wichtig ist zum Schluss, dass du die Object einzeln wieder frei gibst, wenn sie nicht mehr gebraucht werden.

Bis bald Chemiker

[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?

[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

[mkinzler]

Das sind Casts und keine Umwandlungen