Child-Widgets in Scroll Areas untereinander agieren lassen

Alles rund um die Programmierung mit Qt
Antworten
Metzlmane
Beiträge: 13
Registriert: 23. März 2010 19:43
Kontaktdaten:

Child-Widgets in Scroll Areas untereinander agieren lassen

Beitrag von Metzlmane »

Hallo Leute,

nach langem Rumtüfteln hab ich mich hier mal angemeldet und hoffe ihr könnt mir helfen :-)

Folgendes Problem:

Ich hab ein Hauptfenster erstellt, indem 3 Scrollareas mit jeweils einem enthaltenem Widget erzeugt werden. Das ganze geschieht im Konstruktor des Hauptfensters.

Code: Alles auswählen

    List* MainList =  new List(0);
    Sublist* SecondList = new Sublist(0);

    //Scrollarea für Mainliste
    Scr_Area_List = new QScrollArea(this);
    Scr_Area_List->setGeometry(0,60,200,456); //einpassen
    Scr_Area_List->setFrameStyle(0); // 0 um den Rahmen zu entfernen
    Scr_Area_List->setWidget(MainList);

    Scr_Area_Sublist = new QScrollArea(this);
    Scr_Area_Sublist->setGeometry(200,60,824,456);
    Scr_Area_Sublist->setWidget(SecondList);
Das Problem vor dem ich nun stehe ist, dass ich in einem anderen der beiden Widgets GUI-Elemente hinzufügen möchte wenn ich auf einen Button im 1. Widget klicke, oder diese mit einem Destruktor beenden (vorerst egal)

Versucht habe ich mich mit friend-klassen, aber in meinem Buch hieß es, diese seien nur im Notfall zu verwenden.

Die Frage ist, wie greife ich auf die MainList oder SecondList von einer Methode einer anderen Klasse zu?
Dies übersteigt mein Wissen immens, ich bitte nur um einen Denkanstoß :)

MfG, Alex
jerry42
Beiträge: 126
Registriert: 9. Oktober 2008 10:48

Beitrag von jerry42 »

hm...also vlt versteh ich nicht ganz richtig, aber ich würde es z.B. wie folgt lösen:
Stelle für die Klassen public Methoden bereit. Und dann könntest du über die "parent()"-Methode auf dein Hauptfenster zugreifen und von dort wieder auf die public methoden der anderen scroll areas zugreifen.
sacrif
Beiträge: 40
Registriert: 22. Januar 2010 18:52

Beitrag von sacrif »

Das sollte sich auch relativ leicht mit signals uns slots lösen lassen.
Also in der Klasse deines ersten widgets eine entsprechendes signal erstellen und per Knopfdruck emitten, und in den beiden anderen widget Klassen entsprechende slots erstellen die durch das signal ausgelöst werden.
Und im Hauptfenster kannst du das connect() machen (nachdem du die objecte aller subwidgets erstellt hast).
Hier nachzulesen: http://doc.qt.nokia.com/4.6/signalsandslots.html

lg
RavenIV
Beiträge: 267
Registriert: 21. Januar 2009 14:24
Wohnort: Waldshut

Beitrag von RavenIV »

jerry42 hat geschrieben:hm...also vlt versteh ich nicht ganz richtig, aber ich würde es z.B. wie folgt lösen:
Stelle für die Klassen public Methoden bereit. Und dann könntest du über die "parent()"-Methode auf dein Hauptfenster zugreifen und von dort wieder auf die public methoden der anderen scroll areas zugreifen.
Ganz schlechter Stil.
So schafft man ungewollte Abhängigkeiten und die Widgets können nicht mehr für sich alleine leben.

Besser ist der Vorschlag mit Signalen zu arbeiten.
Linux, das längste Text-Adventure aller Zeiten
jerry42
Beiträge: 126
Registriert: 9. Oktober 2008 10:48

Beitrag von jerry42 »

RavenIV hat geschrieben:
jerry42 hat geschrieben:hm...also vlt versteh ich nicht ganz richtig, aber ich würde es z.B. wie folgt lösen:
Stelle für die Klassen public Methoden bereit. Und dann könntest du über die "parent()"-Methode auf dein Hauptfenster zugreifen und von dort wieder auf die public methoden der anderen scroll areas zugreifen.
Ganz schlechter Stil.
So schafft man ungewollte Abhängigkeiten und die Widgets können nicht mehr für sich alleine leben.

Besser ist der Vorschlag mit Signalen zu arbeiten.
jetzt wo ich es so les, stimm ich Dir voll zu. Bin wohl doch noch nich ganz in der Qt Denkweise angekommen. Danke für den Hinweis. :)
RavenIV
Beiträge: 267
Registriert: 21. Januar 2009 14:24
Wohnort: Waldshut

Beitrag von RavenIV »

jerry42 hat geschrieben:
RavenIV hat geschrieben:
Ganz schlechter Stil.
So schafft man ungewollte Abhängigkeiten und die Widgets können nicht mehr für sich alleine leben.

Besser ist der Vorschlag mit Signalen zu arbeiten.
jetzt wo ich es so les, stimm ich Dir voll zu. Bin wohl doch noch nich ganz in der Qt Denkweise angekommen. Danke für den Hinweis. :)
Das hat nicht so viel mit Qt zu tun.
Es ist die Denkweise der Objektorientierung.
Linux, das längste Text-Adventure aller Zeiten
Metzlmane
Beiträge: 13
Registriert: 23. März 2010 19:43
Kontaktdaten:

Beitrag von Metzlmane »

Ok, erst mal danke!
Das mit dem parent() hab ich versucht, bin aber leider auf keinen grünen Zweig gekommen. Genaugenommen hieß es parentWidget() so weit ich es gelesen habe, aber ich habe mich jetz mit den signals und slots versucht.
Nur leider muss ich feststellen dass das ganze nicht so einfach ist wie es scheint :-)


Ich habe im Hauptwidget mehrere Buttons, wo ich, jenachdem welcher gedrückt wird, entsprechend im 2. Widget etwas anzeigen lassen will. Ich habe es so verstanden:

Code: Alles auswählen

class GameButton : public QPushButton{
    Q_OBJECT
public:
    GameButton(const QString & text,int id, QWidget * parent = 0);
    GameButton(const QString & text, QWidget * parent = 0);
public slots:
    void click();
signals:
    void clicked(int id);
private:
    static int nextId;
    int m_id;
};
mit clicked(int id) als Signla und einer einfachen Funktion im selben Widget ... sagen wir settext(), welche einfach nur ein label verändert (wie in vielen Beispielen) funktioniert es.
Was mache ich nun aber wenn ich die ID des Buttons im 2. Widget brauche?

Mein Gedanke war, im 1. Widget auch SIGNAL und SLOT zu erstellen und es einfach "weiterzuleiten" ?

Code: Alles auswählen

class List : public QWidget{
    Q_OBJECT
private:
    QVBoxLayout* VBox;
public:
    GameButton *bn_list[12];
    List(QWidget *parent = 0);
public slots:
    void buttonclicked(int id);
signals:
    void buttonid(int id);
};

class Sublist : public QWidget{
 Q_OBJECT
private:
    QLabel *title;
public:
    Sublist(QWidget *parent = 0);
public slots:
    void settext(int id);
};
Danke für die Hilfe :D
Antworten