Konzeptuelles Problem bei dem C++"Code" erstellt werden soll

[Käsetoast]

Hallo!

Ich hätte eine Frage zu einem konzeptuellen Problem...

Ich arbeit derzeit mit Qt an einem Baummodell (Tree Item View). Das kann man dann beliebig auslegen. Nun stehe ich vor folgendem Hindernis: Es ist möglich eine zusätzliche Spalte einfügen zu lassen. In dieser Spalte steht dann immer ein gewisser Datentyp oder besser gesagt dort findet man einen entsprechenden delegate zum editieren der Daten in der Spalte. Um auszuwählen was für eine Spalte man einfügen will gibt's einen Dialog, in dem man "vorgefertigte" Typen von Spalten auswählen kann. An der Stelle kommt dann mein Problem ins Spiel...

Es soll halt möglich sein nachträglich neue Spaltentypen anzulegen und damit das dann möglich einfach geht soll das Ganze dann "modular" ausfallen. Das heißt es wird irgendwo angegeben, dass Spaltentyp XYZ den Namen "ABC" hat und delegate "DEF" zum Einsatz kommen soll und der Rest wird von einem "Manager" übernommen (also das Aufführen des neuen Spaltentyps in der Auswahlliste und so weiter und so fort). Der Haken besteht nun beim delegate. Nachdem der jeweilige Spaltentyp gewählt worden ist, soll dann eben eine neue Spalte eingefügt werden. Hierbei wird dann der delegate ja mit einem "new" ins Leben gerufen und dann entsprechend den Zellen der Spalte zugewiesen. An dieser Stelle hänge ich nun...

Mein Problem: Das Folgende kann ich in C++ nicht schreiben.

Code: Alles auswählen

KLASSENPLATZHALTER editor = new KLASSENPLATZHALTER;

Geht ja nicht, weil sich da ja erst zur Runtime entscheiden würde was in dem Platzhalter nun genau stehen soll. Kann mir hier jemand unter die Arme greifen mit Tipps wie man das am Besten handhabt? Was ich halt irgendwie bräuchte wäre eine Funktion die quasi das macht was ich oben im Code-Fenster geschrieben habe. Ich weiß jetzt halt nicht wie ich es anstellen soll, dass eine Klassenbezeichnung halt wie eine Variable zu verwenden ist. Aber vielleicht geht's natürlich auch einfacher...

Ansonsten müsste ich da halt eine lange "if-Liste" anlegen wo der Code zum erzeugen des jeweiligen delegates drinsteht und in der beim Spaltenerzeugen nach dem richtigen Abschnitt gesucht wird. Da das jeweils dann auch nur wenige Zeilen Code sind wäre es schon ok wenn man beim Anlegen eines neuen Spaltentyps halt auch hier seinen Code per Hand reinsetzen muss. Schöner wäre es aber eben schon wenn das automatisch übernommen werden könnte...

[RHBaum]

Ich hoffe DU arbeitest mit models !?

das model sollte den Typ wissen, der kann fuer jeden Index seperat gehalten werden, dafuer bist selber verantwortlich ...
fügst du irgendwo daten ein, kannst du am View z.b. QAbstractItemView::setItemDelegateForColumn immer auch das delegate dafuer bestimmten.
Das Delegate wiederum ist dafuer verantwortlich, wie daten im View dargestellt und editiert werden ...

KLASSENPLATZHALTER editor = new KLASSENPLATZHALTER;

sowas loest man ueber vererbung.
DU musst ja mit der klasse umgehen koennen. dafuer legst ne basisklasse / Interface an (oder bentutz was vorhandenes).
Die konkrete Implementation erzeugst dann aufgrund irgendwelcher enscheidungen, meist in einer Factory Function/Methode .

Die signatur und impl sieht dann grob meist so aus

Code: Alles auswählen

IBaseClass * createXYZ(*/Params die zum entscheiden brauchst*/ )
{
    IBaseClass * preturn = nullptr;
    switch(irgendnenParam)
    {
    case A:
        preturn = new MyConcreteImpl;
        break;
    ....
     }

    return preturn:
}

In deinem fall solltest eigene versionen von QAbstractItemDelegate verwenden oder QItemDelegate nehmen und was dir ned passt ueberschreiben.
Dort haengt auch ne funktion dran (createEditor), wo ihm nen Editor für deine Daten liefern musst.

DU kannst generell fuer alle Zellen dein eigenes delegate verwenden.
Da das delegate selber ueber index und Model an die daten kommt, kannst du generell das Delegate entscheiden lassen, wie was angezeigt wird.
Du musst nur alle Infos im Model hinterlegen (Tipp: UserRole nutzen fuer den Typ) .

Ciao ....

[Käsetoast]

Hi!

Schonmal danke für die Antwort. Ja, ich benutze ein Modell und das Delegate zuweisen & Co funktioniert soweit auch alles wunderbar. Mein "Problem" ist nun wie beschrieben, dass wenn jemand einen neuen Spaltentyp bzw. einen neuen Delegate hinzufügen will, man quasi nur den Code für den neuen Delegate irgendwo includet sowie einen "Namenseintrag" in die Liste der möglichen Spalten setzt. Da habe ich auch noch nicht ganz verstanden wie mir Vererbung bzw. dein Codebeispiel helfen soll. Das Problem ist ja wie gesagt nicht die Funktionalität an sich, sondern dass sich Sachen wie die Initialisierung für den neuen Editor bzw. Delegate selbstständig regeln. Das sollte prinzipiell ja möglich sein, da die entsprechenden Möglichkeiten ja schon zum Zeitpunkt des Kompilierens vorliegen und sich nicht alles erst während der Runtime entscheidet. Da stehe ich halt auf dem Schlauch und wüsste spontan auch nicht wie mir Vererbung da weiterhelfen soll, denn die entsprechende neue Klasse für einen neuen Delegate bzw. Editor (also jene, die den new Befehler beinhaltet) müsste dann ja immer noch selbst geschrieben werden...

[RHBaum]

hoffe ich hab dich richtig verstanden ....
deine "delegates" liegen also vor, bzw du weisst alle Möglichkeiten im vorraus ?
Wenn ja, das ist gut so ... wenn nein, muesstest du dynamisch zur laufzeit code einfuegen -> plugins -> kein geeignetes thema fuer ... ich sag mal noch nicht soweit Fortgeschrittene.

In deinem Modell fügt jemand eine neue spalte ein ... da legt er doch auch den typ fest oder ?
Wie macht er das ?

ciao ....

[Käsetoast]

Also es gibt eine feste Anzahl von Spaltentypen die man einfügen kann. Code dynamisch zur Laufzeit einfügen kommt also nicht vor - alle Möglichkeiten sind im Voraus festgelegt...
Die Spaltentypen, die zur Auswahl angeboten werden, sollen komplett im Source Code vorgegeben sein. Sprich es gibt da z.B. eine Liste mit den Namen der angebotenen Typen - dort setzt der geneigte Programmierer halt eine neue Zeile mit dem neuen Namen rein. Des weiteren kann man halt entweder um nicht das Rad stets neu zu erfinden einen der bereits bestehenden Editoren wiederverwenden (wenn z.B. erneut integers > 0 samt SpinBox zum Editieren in die Zellen kommen sollen), oder man erstellt eine neue Klasse für den neuen Editor. Die Krux vor der ich stehe ist einen neuen Editor dann auch tatsächlich im Sinne der Speicherzuweisung (siehe die new-Geschichte) zu erstellen bzw. ohne halt den new-Befehl explizit eingetippt zu haben...

Eine Lösung dafür ist halt eine vorgegebene if-Liste für die besagten new-Befehle, die ich bzw. der zukünftige Programmierer der was Neues einfügen will pflegen muss. Eigentlich ist das auch kein großes Ding, aber das ist dann auch wieder ein Schritt mehr, den man bei sowas beachten muss bzw. wo händische Arbeite nötig ist. Wenn es irgendwie geht (und das sollte es theoretisch ja) soll das halt "vollautomatisch" funktionieren, so dass man wirklich nur Spaltennamen, passender Delegate sowie Default-Wert angibt und dann läuft das. Spart dann halt einen kleinen Arbeitssschritt der jetzt zwar nicht besonders zeitaufwendig ist, aber ich sag's mal so: Viele solch kleiner Zeitersparnisse an verschiedenen Stellen läppern sich irgendwann ja und der geneigte Programmierer wird sich auch über eine "Anleitung", die einen Schritt kürzer ausfällt, freuen...