TCategoryPanel.ControlCount immer = 1

[Uwe Raabe]

Das TCategoryPanel hat nur ein einziges Child-Control vom Typ TCategoryPanelSurface. In diesem stecken dann die einzelnen Conrols, die du sehen kannst. Du musst also nicht über die Controls von TCategoryPanel iterieren, sonden über die des TCategoryPanelSurface, was du über Cpl.Controls[0] erreichts. Die Typumwandlung mittels as ist wohl nicht mal nötig.

[Nils S.]

Achso.

Also ist Cpl.Controls[0] quasi das TCategoryPanelSurface und dieses enthält alle Controls.

Um an die einzelnen Controls zu kommen müsste ich jetzt Cpl.Controls[0].Controls[i] verwenden, was aber nicht geht.
Daher muss ich die Typumwandlung mit as wohl machen (die Schleife klappt jetzt sogar ).

Aber da ich ja auch lernen und verstehen will,
warum funtkioniert z.B. bei einem TPanel Controls/ControlCount, bei einem TCategoryPanel aber nicht, bzw. wieso hat TCategoryPanel dieses Surface, was alle Controls enthält?
Und woran erkennt man sowas bei einer Komponente oder muss man die ganze Klasse durchstöbern, ob man irgendwo ein TXyzSurface findet?

[Uwe Raabe]

Zitat von Nils S.:

Also ist Cpl.Controls[0] quasi das TCategoryPanelSurface und dieses enthält alle Controls.

So ist es.

Zitat von Nils S.:

Um an die einzelnen Controls zu kommen müsste ich jetzt Cpl.Controls[0].Controls[i] verwenden, was aber nicht geht.
Daher muss ich die Typumwandlung mit as wohl machen

Eigentlich reicht hier auch eine Umwandlung in TWinControl, denn dort wurden die Eigenschaften Controls und ControlCount eingeführt.

Zitat von Nils S.:

Aber da ich ja auch lernen und verstehen will,

Zitat von Nils S.:

warum funtkioniert z.B. bei einem TPanel Components/ComponentCount, bei einem TCategoryPanel aber nicht, bzw. wieso hat TCategoryPanel dieses Surface, was alle Controls enthält?

Das ist ein durchaus übliches Pattern (siehe auch TCategoryButtons). Die Instanz von TCategoryPanelSurface ist nicht unbedingt genau ein TCategoryPanelSurface, sondern kann auch davon abgeleitet sein. Die tatsächlich verwendete Klasse wird in der virtuellen Methode GetCategoryPanelSurfaceClass bestimmt, die in einer Ableitung von TCategoryPanel durchaus etwas anderes zurückgeben kann.

Zitat von Nils S.:

Und woran erkennt man sowas bei einer Komponente oder muss man die ganze Klasse durchstöbern, ob man irgendwo ein TXyzSurface findet?

Ich finde sowas eigentlich immer durch Analyse der Sourcen (mach ich immer als Erstes, wenn eine neue Version rauskommt). Gerade für diesen Fall führt ein Blick in die Methode GetChildren meist schnell in die richtige Richtung.

So ein schickes UML-Diagramm wäre da sicher ganz hilfreich, aber das müsste nicht nur jemand einmal erstellen, sondern auch regelmäßig pflegen. Bis dahin gilt: Use the source, Luke!

[himitsu]

Zitat von Uwe Raabe:

Die Typumwandlung mittels as ist wohl nicht mal nötig.

Doch ist ist, denn was passiert wohl, wenn Emba diese Komponente mal umbaut?
Wenn man ein undokumentiertes Verhalten benutzt, dann sollte man wenigstens eine "kleine" Sicherheitsprüfung einbauen.
Oder man benutzt gleich den "offiziellen" Weg.

[Sir Rufo]

Ein Control brauche ich nicht zu casten wenn ich davon die ChildControls haben möchte.

Wenn Emba diese Komponente umbaut und es kommen keine Controls dann kompiliert das Programm nicht. Mit einem Cast stelle ich das dann zur Laufzeit fest.

[Uwe Raabe]

Zitat von Sir Rufo:

Ein Control brauche ich nicht zu casten wenn ich davon die ChildControls haben möchte.

Genauer gesagt: ein TWinControl

[himitsu]

Jupp, .Controls steckt im WinControl, bzw. genauer in TControl, aber egal.

Wenn die es mal umbauen und man bekommt ein anderes Control, dann wird man darüber vermutlich nicht die gewünschten Child-Controls erhalten.

[mkinzler]

Wenn nan das mal umbauen sollte, was sehr unwahrscheinlich ist, würde noch mehr nicht mehr funktionieren. Deshalb jetzt unnötige Cast durchzuführen ist imho nicht nltig. Dann müsstest Du auch alle andeten Properties casten, wer garantiert Dir das eine Caption in der Zukunft noch ein String ist?