Results 1 to 8 of 8

Thread: Using QAbstractTableModel.parent

  1. #1
    Join Date
    Apr 2007
    Posts
    20
    Thanks
    7
    Qt products
    Qt4
    Platforms
    Windows

    Default Using QAbstractTableModel.parent

    I've got a table model derived from QAbstractTableModel. I would like to create column objects within it using something like:

    int MyTableModel::appendColumn(...)
    {
    Column * column = new Column(..., this->parent());
    ...
    }

    However this->parent() expects a QModelIndex parameter. I want to supply the parent object given to the MyTableModel when it was created, e.g.
    model = new MyTableModel(..., parent);

    How should I retrieve that original parent if model->parent() doesn't do it?

    Or should I instead be making the model the parent of the column like:
    Column * column = new Column(..., this);

    Thanks for your help.
    Max

  2. #2
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Using QAbstractTableModel.parent

    I think you are mixing two things. When creating the model, you passed a QObject instance as a parent object of the model. The parent() method of the model is to return an index of an item which is a parent item (not parent widget) to the item passed as the argument. In case of table models it always returns an empty index (because items don't have parents).

    Models don't have parent widgets, only widgets do. Models have parent objects which are only used to make sure the model gets deleted when it is no longer needed.

  3. #3
    Join Date
    Apr 2007
    Posts
    20
    Thanks
    7
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Using QAbstractTableModel.parent

    Ok, so how do I get the parent object?
    Max

  4. #4
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Using QAbstractTableModel.parent

    Use QObject::parent(), although I think you shouldn't need that. What are you trying to achieve?

  5. #5
    Join Date
    Apr 2007
    Posts
    20
    Thanks
    7
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Using QAbstractTableModel.parent

    Quote Originally Posted by wysota View Post
    Use QObject::parent(), although I think you shouldn't need that. What are you trying to achieve?
    I'm trying to create a data table model out of data column objects where each column has a dynamically defined data type. Each column object should be managed by the Qt memory cleanup subsystem so it must derive from QObject and have the Q_OBJECT macro in it's class definition.

    Here's my solution:

    To add a column execute something like:
    int MyTableModel::columnAppendNew(QString name)
    {
    MyColumn *column = new MyColumn(name, this);
    columns_.append(column);
    }

    The MyColumn class looks like:
    class MyColumn : public QObject
    {
    Q_OBJECT
    public:
    explicit MyColumn(QString header, QObject *parent = 0)
    : header_(header), QObject(parent)
    {
    }
    ~AbstractColumn()
    {
    }
    protected:
    QString header_;
    }

    So now, I hope, the MyColumn object is created as a "memory child" of MyTable. N'est pas? Why MyTable is deleted, then all the columns will likewise be deleted.

    Would someone please tell the trolls their dual usage of the term "parent" is confusing.

    Thanks,
    Max

  6. #6
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Using QAbstractTableModel.parent

    Do you need to derive those columns from QObject only because you want them cleaned up when the model gets deleted? If so, then you might just call qDeleteAll() on your columns_ object in the model destructor. And you don't need the Q_OBJECT macro even if you want to keep the QObject legacy. As long as you don't need the meta object for the class (like when declaring new signals or slots), Q_OBJECT is not required.

  7. The following user says thank you to wysota for this useful post:

    Max Yaffe (15th June 2007)

  8. #7
    Join Date
    Apr 2007
    Posts
    20
    Thanks
    7
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Using QAbstractTableModel.parent

    Quote Originally Posted by wysota View Post
    Do you need to derive those columns from QObject only because you want them cleaned up when the model gets deleted?
    Yes, I wanted to use the cleanup mechanism. I think I read that one can explicitly delete new'ed object, but, let's face it, I'm just lazy. Actually, the cleanup is a great feature of Qt. I also hope to be able to send signals to the columns to force things like change column format, etc.

    Thanks for your help.

    Max
    Last edited by wysota; 15th June 2007 at 15:21. Reason: Missing closing tag

  9. #8
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Using QAbstractTableModel.parent

    I think you should manipulate columns this way. The model should be responsible for that and it doesn't need signals and slots. So in general I think you shouldn't derive the columns from QObject. It just doesn't seem to have any advantages and is causing you problems.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.