4. QGridLayout::addWidget(...)

QGridLayout::addWidget(...)

  • M

    Hallo wieder einmal, (ich hoffe, ich werde nicht wegen Spammens gesperrt :p)

    ich wende mich mit folgendem Problem an euch:
    Ich hab zwei dynamische QVectors, die Elemente des Typs "QLineEdit*" beinhalten. Wenn ich nun mittels der "at()"-Methode den Zeiger auf das jeweilige QLineEdit im Vektor zurückgeben und in ein QGridLayout einpassen will, wird folgender Fehler gemeldet:

    request for member ‘at’ in ‘((Generator*)this)->Generator::paramsName’, which is of non-class type ‘QVector<QLineEdit*>*’

    Das Initialisieren eines Vektors sieht im Konstruktor so aus:
    "QVector<QLineEdit*>* paramsName = new QVector<QLineEdit*>;"

    verarbeitet werden seine Elemente dann in einer anderen Funktion in einer for-Schleife:
    "paramsLayout->addWidget(paramsName.at(i),i,0);",
    wobei paramsLayout eben ein QGridLayout ist.

    Der Zugriff über den Indexoperator "[]" funktioniert ebenfalls nicht, führt sogar zu einer noch längeren Fehlermeldung, die auch wieder davon erzählt, dass die Parameteranforderungen von der addWidget-Funktion nicht erfüllt sind.

    Vielen Dank wie immer im Voraus! 🕶

    0
  • G

    moagnus schrieb:

    "paramsLayout->addWidget(paramsName.at(i),i,0);",

    paramsName ist ein zeiger, daher musst du mit paramsName->at(i) oder (*paramsName).at() arbeiten. das erste ist aus meiner sicht die elegantere methoden.

    nur mal so als frage: warum brauchst du einen zeiger auf ein vector?

    0
  • M

    Damit die Lösch-Hierarchie funktioniert, d.h. damit ein Elternobjekt seine Kindobjekte löschen kann.

    Da hätte ich eigtl. selbst drauf kommen müssen, aber vielen Dank! 🤡

    0
  • G

    dafür brauchst du dir keine eigene liste zu halten. qobject löscht alle objekte, die das objekt als parent gesetzt haben gleich mit. siehe doku von QObject::~QObject()

    ansonsten wenn du die liste brauchst, kommst du über QObject::findChild() einfacher daran.

    0
  • M

    Danke für den Tipp. Ich werds mir auf jeden Fall mal anschaun.
    Dass die Objekte dynamisch erstellt werden, war für mich bisher selbstverständlich, da ich es in zwei Büchern gelesen habe und die Beispiele des QtAssistant auch immer mit von "new" erzeugten Instanzen und Zeigern funktionieren.

    0
  • G

    du musst die auch mittels new erstellen, sonst fliegt dir der code bei ausführen des dtors oder danach um die ohren. steht auch groß in dem warning zu dem dtor von qobject.

    das automatische löschen funktioniert wie folgt:

    QObject* a=new QObject; //keine eltern gesetzt
QObject* b=new QObject(a); //a ist parent von b
delete a; //löscht sowohl a als auch b

    wenn du das kind vorher mittels delete löschst, ist es auch nicht weiter tragisch, da dessen dtor dafür sorgt, dass es bei dem parent ausgetragen wird. ist halt nur unnötig, selber vor dem löschen des parent die kinder von hand zu entfernen.

    0
  • M

    Genau, deswegen lass ich das ja auch von den automatisch aufgerufenen Destruktoren erledigen.
    Ich meinte nur, dass ich meine Attribute mit "new" erzeuge, damit eben diese Prozedur funktioniert.

    0
  • G

    wenn du eine zweitliste führen willst, deren sinn ich irgendwie wohl falsch verstanden haben und bei der mir völlig rätselhaft ist, wozu du die brauchen könntest, solltest du dafür aber keine nackten zeiger sondern eher qpointer benutzen. ist hier deutlich hilfreicher, da trotz autodelete keine ungültige referenzen irgendwo hinterlassen kannst.

    0
  • M

    Danke für den Tipp! 🙂
    Aber ich glaub, ich versteh dich jetzt wiederum nicht... Kannst du nachvollziehen, warum ich die Vektoren auf den Heap legen will?

    0
  • G

    ich verstehe nicht, wozu den den vector überhaupt brauchen könntest.

    0
  • M

    Okay, das hätte ich vllt. am Anfang mal erklären sollen.
    Also: Ich bastel an einem Firefox-Suchmaschinen-Generator, der den Benutzer in ner Combo-Box auswählen lässt, wie viele Parameter die URL beinhaltet. Je nachdem wie viel der User da eingibt, werden jeweils zwei QLineEdits hinzugefügt: eins für den Parameternamen und eins für dessen Wert. Das Ganze wird eben über die append()- bzw. pop_back()-Methode eines QVektors realisiert.
    Hoffe, das ist nicht zu umständlich gedacht und für dich nachvollziehbar.

    0
  • G

    machen kann man das so. hätte ich nur nicht so gemacht. 😉

    ich hätte es wohl anders gebaut. erstmal eigene widgetklasse für die beiden edits -> sinnvoll api für key und value. dann diese in ein qvboxlayout gepackt. für die abfrage hätte ich dann mittels itemAt()->widget() (def. steht in qlayout) über das qvboxlayout iteriert. immerhin ist da ja schon einer, der die widgets speichert. dann braucht man sich auch keine gedanken über die haushaltung der widgets machen. das layout kümmert sich um die passenden fortlaufende nummern und übernimmt auch das handling der einfügungen und löschungen.

    0
  • M

    Erstmal: Tut mir leid, dass ich den Thread so versanden hab lassen. Normalerweise mach ich sowas nicht, aber hatte gut zu tun...
    Außerdem muss ich mich leider auch zu der Gruppe von Threadstellern zählen, die ein Problem loswerden wollen und es am Ende ganz anders lösen, wofür sie überhaupt keine Tipps gebraucht hätten... 🙄
    Hab die Funktion jetzt über Checkboxen gelöst. Das heißt, der Benutzer kann auswählen, wie viele Felder er will, indem er vor jedes Feld das Häkchen setzt.

    Hier noch abschließend ein Screen, damit du siehst, für was du dich abgemüht hast:
    http://img117.imageshack.us/my.php?image=ffol0.png
    😉

    0
  • G

    na das nehme ich dir doch nicht übel, auch wenn es aus meiner sicht wenig elegant ist, dass mittels checkbox zu lösen. vlayout wäre aus meiner sicht eleganter. 😉

    0
Anmelden zum Antworten