class Control
{
// ganze Stange Methoden und Attribute
};

class StaticText: public Control
{
  SetHAlignment(HorizontalAlignment);
  SetVAlignment(VerticalAlignment);
};

class Button: public Control
{
  StaticText m_text;
};

class CheckBox: public Control
{
  Button m_button;
  StaticText m_text;
};

Also im Prinzip durch Komposition.
Mein Problem ist jetzt, dass ich beispielsweise in Button alle Funktionen von StaticText quasi neu fuer den Button implementieren muss:

Button::SetVAlignment(VerticalAlignment va)
{
  m_text.SetVAlignment(va);
}

Das ist irgendwie nicht das Wahre.

Mir würden folgende Alternativen einfallen:
1.

StaticText& Button::GetStaticText()
{
  return m_text;
}

Jetzt kann man alles ordentlich aendern, aber ich gebe damit Implementationsdetails preis. Das kann es irgendwie auch nicht sein, zumal ein anderer Button anders implementiert sein kann (ohne StaticText).

2. private Vererbung und einfach using <Methodenname>. Hier bin ich mir nicht ganz sicher, ob es dann bei CheckBox (wuerde von Button und StaticText erben) zu Komplikationen fuehren wuerde (wegen den identischen Membern von Control). Gibt es bei private Mehrfachvererbung die selben Probleme wie bei public Mehrfachverbung?

Fallen jemanden noch andere Moeglichkeiten ein? Wie wuerdet ihr das machen?
Ich habe auch noch an identische Basisklassen gedacht (also eine tiefere Klassenhirarchie; Control->TextControl->StaticText; TextControl->Button z.B.), aber damit komme ich auch auf keinen gruenen Zweig.

Gruss,
DeSoVoDaMu

wenn du eine wirklich gute GUI-Lib erstellen willst, dann mußt du erst einmal verschiedene Abstraktionsebenen als Grundlage nehmen.
Ich habe für das (hoffentlich in diesem Jahr noch erscheinende) Spiel "Sacred2" an dessen GUI-Lib mitgearbeitet.
Diese GUI-Lib unterscheidet zwischen 3 verschiedenen Ebenen:
1. Controls
2. Layout
3. Render-Engine

Du solltest insbesondere zwischen Controls und Layout (d.h. grafische Darstellung eines Controls) unterscheiden.

Ein Control sollte nur Angaben über (relative) Position und Größe sowie Maus- und Tastaturbehandlung besitzen.
Das Layout eines Controls sollte möglichst unabhängig vom eigentlichen Control sein (z.B. mittels Adapter-Pattern). Du könntest dann verschiedene Standard-Layouts (z.B. Text, Grafik, Gradienten-Rechteck oder auch HTML o.ä) anbieten, die dann einfach mit dem Control verknüpft werden (alternativ sogar als Liste, welche nacheinander gerendert werden - falls du z.B. Transparenz einsetzen willst bzw. kannst).

Und die Render-Engine sollte dann als einzige Ebene direkt mit der verwendeten Grafik-Engine (z.B. DirectX, OpenGL oder eine andere) interagieren.

Die einzelnen Ebenen agieren dabei über Interface-Klassen miteinander, d.h. sie sollten nicht abhängig von bestimmten Klassen sein.

Dein Hauptfehler ist schon, daß deine Controls (z.B. der Button) selber wieder aus anderen (festdefinierten) Controls bestehen. Aber du hast ja selber erkannt, daß dies ein Design-Fehlern ist und zu unübersichtlichem Code führt.
Mach' nicht denselben Fehler, wie ihn schon andere GUIs gemacht haben...

Falls du mehr Infos brauchst, kannst du mir ja eine E-Mail schreiben: TBentrup (at) bitel.net.

Das Problem ist wie gesagt, dass ich nicht so recht weiss, wie ich die einzelnen Controls implementiere, ohne gross Code-Dopplungen zu haben. Ich wuerde es schon als logisch empfinden, wenn etwa ein Button mit einem StaticText implementiert ist. Was spricht deiner Meinung nach dagegen? Es ist ja auch nicht so, dass das Control direkt festgelegt ist, denn es wird ueber eine Factory erstellt (welche nur Controls eines Themes erstellt).
Mich wuerde interessieren, wie Du das loesen wuerdest / geloest hast, da Du ja offensichtlich Erfahrung auf dem Gebiet mitbringst.

Wenn Du einen Blick in den bisherigen Stand werfen willst:
http://www.desovodamu.de/downloads/gui.rar (ist natuerlich noch nicht fertig, einige Sachen werden noch komplett ueberarbeitet, mehr kommentiert etc.; kompilieren wirst Du es nicht koennen, derzeit werden noch einige weitere Bibliotheken vorausgesetzt).

Gruß,
DeSoVoDaMu