SortedList oder iDictionary in Delphi (ohne .net!)

[Berlinermauer]

Hey Leute,

Ich bin an einem Punkt, andem muss ich quasi Arrays mit Key haben.

Ich weiß nicht mehr wie man es nennt, aber in c sähe das so aus: meinarray['brot'] = 'schmeckt nicht';

Dazu kommt, dass ich das nicht mit Strings machen kann, sondern ein TObject habe.

Um es genauer zu sagen: Ich habe eine GUID, und anhand dieser GUID muss ich auf nen TObject kommen.

Ein Array dafür zu verweden, und nur die GUIDS reinzuschreiben ist schlecht, da diese mal 4000 sind, mal 12000 mal 15, sprich die GUID ist nicht klein, und auch nicht durchgängig.

Hat jemand ne Idee wie das zu machen wäre?

In .NET gibt es die SortedList, und in C gibt es ein "iDictionary".

Danke :)

[jfheins]

Such mal in der CodeLib nach "Dictionary" ;)

[bernau]

Wenn es "nur" die GUID ist und ein Object, dann bietet sich doch wunderbar eine einfache Stringlist an. Zu jedem String kann man ein Object hinterlegen.

Delphi-Quellcode:

meineStringliste.addObject('DieGUID',MeinObject);

[himitsu]

http://www.delphipraxis.net/topic156343.html

Den Index-String auch noch zum generischen Typen machen und 'nen IComparer (oder wie das jetzt nochmal hieß) für den Index-Vergleich anschaffen, dann sollte/dürfte/könnte das auch mit anderen Indize funktionieren.

[Berlinermauer]

Danke für die vielen Antworten, ich habe das Problem und dmait gleich ein weiteres Problem gelöst:

Ihr kennt ja sicher die ComboBoxen etc, die Controls womit man was auswählt, nun wollte ich passend zum Text der da steht ein Objekt haben, und war kurz davor den Text zu parsen :]

Nur ein Problem habe ich da:

Delphi-Quellcode:

TObject(ComboBox1.Items.Objects[ComboBox1.ItemIndex]);

So, ItemIndex hat immer unterschiedliche Werte (d.h. je nach dem, was ausgewählt wurde), jedoch ist das TObject das am Ende rauskommt, immer das, welches den größten ItemIndex hat?!

Egal auf das ComboBox1.ItemIndex steht, ComboBox1.Items.Objects ist immer High() in dem Sinne.

lt. der OH müsste es so funktionieren?
Warum mag das nicht?!


Edit: Achja, Ich tue das nicht! im OnChange oä der ComboBox, sondern dies ist ein Seperater Button der da gedrückt werden muss. (obwohl, das ist ja nur wichtig wenn ItemIndex nicht stimmt)

[himitsu]

Wie hast du die Objekte der ComboBoxen zugewiesen?
Eventuell stimmt da ja was nicht, ansonsten sollte

Delphi-Quellcode:

ComboBox1.Items.Objects[ComboBox1.ItemIndex]

schon korrekt sein.

[Chemiker]

Hallo Berlinermauer,

das sieht so aus, dass Du allen Objecten das letzte Object zugewiesen hast.

Bis bald Chemiker

[himitsu]

Zitat:

Zitat von Chemiker (Beitrag 1051386)

das sieht so aus, dass Du allen Objecten das letzte Object zugewiesen hast.

Was auch gern "falsch" gemacht wird:
Allen Items das selbe Objekt und nur den Objektinhalt ausgetauscht/überschrieben.

[Satty67]

Ist vielleicht nicht angebracht, aber wenn jemand von der (C#?) .NET Welt kommt...

Objekte werden in Delphi ja nicht automatisch in einer GarbageCollection entsorgt. Wenn da etwas bei der Objektzuweisung schief läuft und Referenzen verloren gehen sowieso.

Evtl. ReportMemoryLeaksOnShutdown := true oder FastMM4 verwenden (wenn Delphi 7 noch stimmt)?

[Berlinermauer]

Hm, wie kann ich gucken ob alle Objecte die gleichen sind? beim Debuggen will das iwie nicht so recht, weil .Objects[] kein array oder soetwas in dem Sinne ist.

und nein ich komme nicht von C# nur hab ich da halt einen Beispiel Code gefunden, und dachte: Sowas müsste es doch auch in Delphi geben!


Achja:

Zitat:

Was auch gern "falsch" gemacht wird:
Allen Items das selbe Objekt und nur den Objektinhalt ausgetauscht/überschrieben.

Ja könnte sein, aber was ist daran falsch?
Wie müsste es richtig lauten?

Grüße
;)

[Chemiker]

Hallo Berlinermauer,

Zitat:

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:

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:

Zitat von rollstuhlfahrer (Beitrag 1051959)

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:

Zitat von Berlinermauer (Beitrag 1052013)

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:

Zitat von Berlinermauer (Beitrag 1052013)

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

Frage am Rande: Geht TObject(myRecord)??

Zitat:

Zitat von Berlinermauer (Beitrag 1052013)

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:

Zitat von rollstuhlfahrer (Beitrag 1052026)

Zitat:

Zitat von Berlinermauer (Beitrag 1052013)

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:

Zitat von rollstuhlfahrer (Beitrag 1052026)

Zitat:

Zitat von Berlinermauer (Beitrag 1052013)

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:

Zitat von rollstuhlfahrer (Beitrag 1052026)

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

[Chemiker]

Hallo Berlinermauer,
z.B.:

Delphi-Quellcode:

type
  TmyPointer= ^TmyRecord;
  TmyRecord= Record
    rEintrag1: String;
    rEintrag2: Integer;
  End

;
An die Stringlist hängen:

Delphi-Quellcode:

p1:= @myRec1;
  p2:= @myRec2;
  myRec1.rEintrag1:= 'Das ist der erte Eintrag';
  myRec1.rEintrag2:= 10001;
  myRec2.rEintrag1:= 'Das ist der zweite Eintrag';
  myRec2.rEintrag2:= 20002;
  CobMitObject.Items.AddObject('Item1',TObject(p1));
  CobMitObject.Items.AddObject('Item2',TObject(p2));

Und so auslesen:

Delphi-Quellcode:

 p1:= TmyPointer (CobMitObject.Items.Objects[CobMitObject.ItemIndex]);
   edEintrag1.Text:= p1.rEintrag1;
   edEintrag2.Text:= inttostr(p1.rEintrag2);

Bis bald Chemiker

[rollstuhlfahrer]

Zitat:

Zitat von Berlinermauer (Beitrag 1052043)

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

[Berlinermauer]

Zitat:

Zitat von rollstuhlfahrer (Beitrag 1052070)

Zitat:

Zitat von Berlinermauer (Beitrag 1052043)

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

Ich mache es umgekehrt, ich erstelle ein Objekt, befülle es, schicke es in die StringListe, und lösche das "echte" wieder.

Die StringList scheint auch nicht nur einen Pointer darauf setzen, sonst hätte es schon geknallt.

Das mit dem Record werd ich mir mal angucken @ Chemiker.

Dennoch würde ich gerne wissen wie ich nen Unsigned 64 Bit Int hinbekomme.

Quasi einen Cardinal64, via type müsste das doch irgendwie gehen oder?


Int64 gibt es ja in Delphi aber kein UInt64

MfG

[stahli]

Zitat:

Ich mache es umgekehrt, ich erstelle ein Objekt, befülle es, schicke es in die StringListe, und lösche das "echte" wieder.
Die StringList scheint auch nicht nur einen Pointer darauf setzen, sonst hätte es schon geknallt.

Das funktioniert nur, so lange der Speicherbereich nicht überschrieben wurde (und Du entsprechend glück hast).
Die Verfahrensweise ist also auf keinen Fall korrekt.

[xZise]

Moin,

Zitat:

Zitat von Berlinermauer (Beitrag 1052043)

[...]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

Delphi-Quellcode:

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

Delphi-Quellcode:

x.Destroy;

sondern

Delphi-Quellcode:

x.Free;

oder

Delphi-Quellcode:

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,

Dein Vorgehen ist irgendwie nicht so ganz verständlich. Du solltest auf jeden Fall in dem Project-Quelltext die Zeile:

Delphi-Quellcode:

  ReportMemoryLeaksOnShutdown := true;

einfügen, damit Du feststellen kannst ob Du bei Deinem Vorgehen nicht Speicherlöcher produzierst.

Zitat:

Ich mache es umgekehrt, ich erstelle ein Objekt, befülle es, schicke es in die StringListe, und lösche das "echte" wieder.

Das ist doch Kontraproduktiv, Du kannst doch einfach, wie xZise es beschreibt das Object an die StringList anhängen.

Zitat:

Die StringList scheint auch nicht nur einen Pointer darauf setzen, sonst hätte es schon geknallt.

Der StringList ist es egal, ob das Object freigegeben worden ist, oder nicht.

Bis bald Chemiker

[Berlinermauer]

Ich glaube wir reden teilweise aneinander vorbei:

Ich möchte, dass der benutzer an einer ComboBox etwas auswählen kann.
Er hat dazu mehrere Sachen zur Auswahl, es wird aber immer nur eins benutzt nie mehrere gleichzeitig.

Was ich bis jetzt hatte: Objekt kreeieren, Methode des Objekts aufrufen, die vollständig füllt, Objekt der Liste zuweisen, Objekt selbst freigeben.

Ist das jetzt falsch, weil theoretisch eine AccessViolation lesen von Adresse XY die falschen Werte gibt da da was anderes steht?

Wie sollte ich es sonst besser machen? Dynamisches Array ist nen bisschen umständig und Speicherverbrauchend oder? (Obwohl, das wird ja dann nach der Auswahl gelöscht)


btw: kennt denn eigentlich keiner nen UINT 64 in Delphi?

[rollstuhlfahrer]

Zitat:

Zitat von Berlinermauer (Beitrag 1052257)

btw: kennt denn eigentlich keiner nen UINT 64 in Delphi?

Gibt es nicht. Int64 (also signed 64bit ist das größte was Delphi semi-nativ unterstützt

Zitat:

Zitat von Berlinermauer (Beitrag 1052257)

Ich glaube wir reden teilweise aneinander vorbei:

JA

Zitat:

Zitat von Berlinermauer (Beitrag 1052257)

Was ich bis jetzt hatte: Objekt kreeieren, Methode des Objekts aufrufen, die vollständig füllt, Objekt der Liste zuweisen, Objekt selbst freigeben.

Dein Freigeben kommt an der falschen Stelle. Nimm bitte an, dass wenn du das Objekt freigibt, dass dann die Objekte in deiner Liste auch futsch sind. Es ist so!
Der Grund, warum du immernoch auf die gelöschten Objekte zugreifen kannst, ist, dass sie noch im Speicher liegen. Sobald dieser Speicherbereich neu belegt wird, sind die Objekte aber wirklich futsch.

Zitat:

Zitat von Berlinermauer (Beitrag 1052257)

Ist das jetzt falsch, weil theoretisch eine AccessViolation lesen von Adresse XY die falschen Werte gibt da da was anderes steht?

Wo kommt denn die AV?

Zitat:

Zitat von Berlinermauer (Beitrag 1052257)

Wie sollte ich es sonst besser machen?

Du hast doch eine "funktionierende" Lösung. Was "besseres" gibt es für diesen Anforderungsbrereich nicht (Außer Record).

Bernhard

[xZise]

Moin,
also ich weiß nicht was du vor hast, aber sowas geht nicht:

Delphi-Quellcode:

var
  x, y : THaus;
begin
  x := THaus.Create;
  y := x;
  x.Free;
  y.maleAn(Grün);

Weil sobald du x.Free aufrufst ist auch das Haus y zerstört.

Du hast jetzt folgendes gemacht: Du hast eine Combobox befüllt. Und die Objekte dabei schon freigegeben. Und da man erst nach der Aktion was auswählen kann, sind also alle Objekte bis auf das letzte freigegeben.

Was solltest du anstelle machen? Das habe ich schon gesagt: Mach dir eine TObjectList in der du die Element auch speicherst, und sobald du sie nicht mehr brauchst kannst du sie alle löschen indem du TObjectList.Clear aufrufst (oder die Liste freigibst). Das setzt voraus das OwnObjects auf true steht.

Eventuell kannst du aber auch OwnObjects auf true stellen, von der Liste der ComboBox.

MfG
Fabian

PS: Und falls du glaubst du gibst zu wenig Objekte frei: Schalte doch einfach

Delphi-Quellcode:

ReportMemoryLeaksOnShutdown := true;

.

[rollstuhlfahrer]

Wenn Delphi 7 stimmt, dann gibt es diesen Schalter nicht. Aber man kann auf für Delphi 7 FastMM einbinden.

Bernhard