über Objekte einer Klasse iterieren

[Bomberbb]

Hallo!

Ist es möglich in Delhi über die Objekte einer Klasse zu iterieren???

Sascha

[s-off]

Hallo,

wenn Deine Klasse das kann; sicher.

Die Klasse TForm hat beispielsweise die Eigenschaft 'ComponentCount' über die sämtliche auf der Form befindlichen Componenten abgefragt werden können (sämtliche Komponenten werden intern in einer TList referenziert). Damit kannst Du dann über die Komponenten iterieren.

[peschai]

Hallo
Kannst du kurz beschreiben was du tun möchtest, dann können wir eventuell besser helfen.

Wen du z.b. wissen möchtest wie oft die Klasse TObject instantiiert wurde, also wie oft es das Objeckt "TObject" gibt, so kann dir standard delphi das nicht sagen. Den create bzw destroy prozess müsstest du mitprotokollieren in zb einer eigenen abgeleteteten TMyObject Klasse.

Es gibt aber einige Klassen, welche per definition weintere Klassen verwalten und so etwas bereits mitbringen. das Property "Components" z.b TForm ist hier ein Beispiel.

[Bomberbb]

Ja die Möglichkeit mit Components hab ich auch schon gesehen, da wird aber über die Komponenten auf einer Komponente iteriert.

Mein Problem ist, wenn die auf unterschiedlichen Komponenten sitzen, erwische ich nicht alle...

Ich habe eine Komponente von TCustomPanel abgeleitet und möchte nun über alle Objekte iterieren, die sich in meinem Programm befinden. Hatte schon überlegt, etwas ähliches wie einee verkettete Liste im Konstruktor zu erstellen, das bekomme ich aber auch nicht hin, da ich im Konstruktor keinen Zeiger auf mein Objekt bekomme...

[Luckie]

Rekursion ist hier das Stichwort.

[Bomberbb]

Rekursion? Wie muss ich mir das in diesem Zusammenhang vorstellen?

[peschai]

Zitat:

Zitat von Bomberbb

...bekomme ich aber auch nicht hin, da ich im Konstruktor keinen Zeiger auf mein Objekt bekomme...

Innerhalb des constructors nach dem Aufruf von Inherited sollte "Self" die adresse deines Objects sein ...

[s-off]

Zitat:

Zitat von peschai

Wen du z.b. wissen möchtest wie oft die Klasse TObject instantiiert wurde, also wie oft es das Objeckt "TObject" gibt, so kann dir standard delphi das nicht sagen. Den create bzw destroy prozess müsstest du mitprotokollieren in zb einer eigenen abgeleteteten TMyObject Klasse.

Es gibt aber einige Klassen, welche per definition weintere Klassen verwalten und so etwas bereits mitbringen. das Property "Components" z.b TForm ist hier ein Beispiel.
[...]

Liest hier eigentlich niemand (fast niemand) die Beiträge eines Threads, bevor er antwortet? Ansonsten kann ich mir das permanente Wiederholen bereits getätigter Aussagen nicht erklären...

Zurück zum Thema<<<

Zitat:

Zitat von Luckie

Rekursion ist hier das Stichwort.

Für Rekursion benötigt er aber etwas, woran er sich festhalten kann. Und das muss die Klasse können, wie bereits in Beitrag #2 erläutert. Oder meintest Du das Luckie?

[Bomberbb]

@peschai:

Das wird nicht funktionieren, da Self kein Zeiger ist.

[Luckie]

Nun ja, wen er eine Komponente gefunden hatm, ruft er ComponentCount usw. für die gefundene Komponente auf und so weiter. Eben genauso wie man durch das Dateisystem iteriert mit Rekursion.

[s-off]

Also nocheinmal,

eine Klasse, die von TObject abgeleitet ist, bringt von Haus aus keine Möglichkeit mit, über alle ihr zugehörigen Objekte zu iterieren.

Fazit: Man muss selber dafür sorgen, dass diese Funktionalität implementiert wird, wenn man sie denn wünscht.

Für einige Klassen ist dieses bereits implmentiert worden. Beispielsweise für TForm und ihr Feld FComponents, wie bereits in #2 erläutert.
FComponents ist vom Typ TList. In ihr werden sämtliche Componenten gespeichert, die auf der Instanz von TForm erzeugt werden.

Edit: Ah, Rekursion in diesem Fall hat Luckie schon erläutert.

[alzaimar]

Zitat:

Zitat von s-off

Für einige Klassen ist dieses bereits implmentiert worden. Beispielsweise für TForm und ihr Feld FComponents, wie bereits in #2 erläutert.

:gruebel: Das Eine hat doch nichts mit dem Anderen zu tun. Wincontrols können als Container fungieren und stelln deshalb logischerweise Funktionalitäten bereit, die es ermöglichen, durch den Container zu iterieren. Das betrifft jedoch andere Objekte, die auf ihr drauf liegen, aber nicht die Form selbst...

Die TForms-Klasse weiss aber auch nicht, wie viele Forms denn so rumfleuchen. Das geht auch gar nicht, weil eine Klasse keine Felder besitzen kann, die aber irgendwie für die Implementierung dieser Funktionalität von Nöten wäre.

Erstelle Dir also einen Container für deine Objekte. Im Construktor fügst Du die Instanz in die Liste ein und im Destruktor wieder raus.

Delphi-Quellcode:

TPanelContainer = Class (TList) ...
...
End;

Var
  MyPanelContainer : TPanelContainer;

TMyPanel = Class (TPanel)
  Constructor Create (aOwner : TComponent); Override;
  Destructor Destroy; 
...
End;

Constructor TMyPanel.Create (aOwner : TComponent);
Begin
  inherited;
  MyPanelContainer.Add (Self);
...
end;

Destructor TMyPanel.Destroy;
Begin
  MyPanelContainer.Remove (Self);
  ...
  inherited
End;

[Bomberbb]

ich glaube alzaimar ist der erste der mich verstanden hat!!!
Danke!!! Ist genau das was ich brauche.

[Luckie]

Hier noch mal ein kleines Tutorial dazu: http://www.michael-puff.de/Developer...er_Klassen.php

[s-off]

Zitat:

Zitat von alzaimar

Zitat:

Zitat von s-off

Für einige Klassen ist dieses bereits implmentiert worden. Beispielsweise für TForm und ihr Feld FComponents, wie bereits in #2 erläutert.

:gruebel: Das Eine hat doch nichts mit dem Anderen zu tun. Wincontrols können als Container fungieren und stelln deshalb logischerweise Funktionalitäten bereit, die es ermöglichen, durch den Container zu iterieren. Das betrifft jedoch andere Objekte, die auf ihr drauf liegen, aber nicht die Form selbst...

Wieso hat das eine mit dem anderen nichts zu tun?
Die Form (Instanz der Klasse) weiß aber, was auf ihr liegt (Komponenten).

Zitat:

Zitat von alzaimar

Die TForms-Klasse weiss aber auch nicht, wie viele Forms denn so rumfleuchen. Das geht auch gar nicht, weil eine Klasse keine Felder besitzen kann, die aber irgendwie für die Implementierung dieser Funktionalität von Nöten wäre.

Das habe ich doch auch gar nicht behauptet. Aber eine Instanz von TForm weiß, wieviele Komponenten auf ihr 'rumfleuchen'

Zitat:

Zitat von alzaimar

Erstelle Dir also einen Container für deine Objekte. Im Construktor fügst Du die Instanz in die Liste ein und im Destruktor wieder raus.

Spreche ich chinesisch :?: :!:
Das ist doch genau das, was ich die ganze Zeit gesagt habe; in jedem der Beiträge oben habe ich gesagt, dass er es seiner Klasse beibringen muss.
Was eine Liste (FComponents) der Container für TForm ist muss er sich für seine Klasse auch bauen.
Und damit meinte ich genau das, was alzaimar mit seinem PanelContainer vorgeschlagen hat :!: :!: :!:

Deutlicher kann man es wohl ohne Codebeispiel nicht erläutern.
Und dass Du, BomberBB, mich nicht ohne Beispiel verstanden hast, tut mir leid. Deswegen musst Du allerdings nocch lange nicht allen anderen unterstellen, sie hätten Dich nicht verstanden :wall:

[alzaimar]

Zitat:

Zitat von s-off

Wieso hat das eine mit dem anderen nichts zu tun?

Das eine ist ein Container, das Andere eine Liste von Objekten. Na klar ist ein Container eine Liste von Objekten, aber hier (TForm) haben wir eine übergeordnete Klasse, die ihre Kinder verwaltet. Das ist aber nicht erwünscht.
Wir wollen eine Klasse, die ihre Instanten automatisch in eine bestimmte Liste (achtung! Singleton!) schreibt und wieder entfernt.

Der Unterschied zur Containerklasse TWinControl ist der:
Ich kann ein Control (also ein potentielles Kind der TForm) instantiieren, ohne das es auf einer Form ist. Damit taucht es in keiner Controls-Liste auf.

Wenn ich aber eine Instanz von TMyPanel erzeuge, dann taucht es in jedem Fall in einer Liste auf.

Ansonsten gebe ich dir recht: Ich habe nur übersetzt, was Du schon vorher gesagt hast.

[s-off]

Upsi, habe vielleicht etwas zu harsch geantwortet.
Deine Erläuterung werde ich beim Mittagessen mal Revue passieren lassen - danke :wink:

[alzaimar]

Zitat:

Zitat von s-off

Upsi, habe vielleicht etwas zu harsch geantwortet.

Na ja, :cry: geht aber schon wieder. :zwinker:

[Bomberbb]

@s-off:

Zitat:

Und dass Du, BomberBB, mich nicht ohne Beispiel verstanden hast, tut mir leid. Deswegen musst Du allerdings nocch lange nicht allen anderen unterstellen, sie hätten Dich nicht verstanden ouch!

Du sprichst von:

Zitat:

FComponents ist vom Typ TList. In ihr werden sämtliche Componenten gespeichert, die auf der Instanz von TForm erzeugt werden.

das wollte ich auch nicht haben. Ich wollte über alle Intanzen einer Klasse iterieren. Ob ich das jetzt schlecht erklärt habe oder ob das nicht so verstanden wurde wie ich das meinte kann man unter Komunikationsprobleme abhaken. Ist für mich aber lange kein Grund für den Umgangston aus #15.

@alzaimar:

DANKE. Funzt bestens!!!

[peschai]

Hallo Kollegen,

@s-off:
Bitte weniger Vorwürfe was ein anderer falsch macht oder schreibt oder nicht liest und mehr konstruktive hilfe.

@BomberBB:
Self ist in Wirklichkeit ein Zeiger auf das Object selbst. Damit kannst du in jeder ObjectMethode das object selbst ansprechen. Mit einem typecast wie Pointer(Self) kannst du das auch nutzen ... z.b. in einer Liste abspeichern, etc ... Dass benutzt z.b. das Beiepisl von Alzaimar.

[s-off]

Zitat:

Zitat von peschai

@s-off:
Bitte weniger Vorwürfe was ein anderer falsch macht oder schreibt oder nicht liest und mehr konstruktive hilfe.
@

Wenn mir etwas nicht passt, dann sage ich das. Und ich möchte, dass das respektiert wird. Dieses Recht räume ich schliesslich auch jedem anderen mir gegenüber ein.
Wenn jemand mit meiner Kritik nicht umgehen kann, hat er mehrere Möglichkeiten:

• Er ignoriert es
• Er verwertet die Kritik; wie auch immer.

Über quantitative Aspekte mein Angebot an Hilfestellungen betreffend kannst Du Dich wohl kaum beschweren. In jedem meiner Beiträge innerhalb dieses Threads bin ich auch auf die Problemstellung eingegangen.
Die Tatsache, dass diese nicht zum gewünschten Erfolg geführt hat, können wir lt. Aussage des Threaderstellers unter 'Kommunikationsschwierigkeiten' verbuchen.

[stahli]

Hallo zusammen,

alle haben sich wieder lieb ;-)
(Alles Männer und doch versteht man sich nicht...)

Wenn man keine eigenen Komponenten sucht (die man bei Erzeugen extra registrieren kann), geht´s z.B. auch so (das war sicher mit der Rekursion gemeint):

Delphi-Quellcode:

procedure AlleXyzSuchen;

  procedure AlleXyzSuchen_(Comp:TComponent);
  var I:Integer;
      Temp:TComponent;
  begin
    with Comp do begin
      for I:=0 to ComponentCount-1 do begin
        Temp:=Components[I];
        if (Temp is TXyz) then begin 
          (Temp as TXyz).MachWas;
        end
        else AlleXyzSuchen_(Temp);
        // wenn auch in TXyz selbst gesucht werden soll, else entfernen
      end;
    end;
  end;

begin
  AlleXyzSuchen_(Application);
end;

Stahli

[Reinhard Kern]

Zitat:

Zitat von Bomberbb

Ja die Möglichkeit mit Components hab ich auch schon gesehen, da wird aber über die Komponenten auf einer Komponente iteriert.

Mein Problem ist, wenn die auf unterschiedlichen Komponenten sitzen, erwische ich nicht alle...

Ich habe eine Komponente von TCustomPanel abgeleitet und möchte nun über alle Objekte iterieren, die sich in meinem Programm befinden. Hatte schon überlegt, etwas ähliches wie einee verkettete Liste im Konstruktor zu erstellen, das bekomme ich aber auch nicht hin, da ich im Konstruktor keinen Zeiger auf mein Objekt bekomme...

Hallo,

dafür gibt es aber mehrere Lösungen:

a) ich rufe für jedes neue Objekt Create auf mit den Parametern Root und Parent - Root ist das Ausgangsobjekt (eines Baumes, hier könnte man auch Klassenvariable einsetzen), Parent eben das Vorgängerobjekt, deren Adressen werden im Objekt gespeichert. Dann rufe ich StartNewObject auf mit dem Ergebnis (also dem neuen Objekt) als Parameter, dort wird u.a. der Pointer Parent.Next gesetzt auf das neue Objekt.

b) man verkettet rückwärts - die Adresse von Parent ist ja bekannt und kann als self.Previous gespeichert werden.

Gruss Reinhard