QSqlRelationalTableModel with multiple Joins?

[devhobby]

@SGaist said in QSqlRelationalTableModel with multiple Joins?:

Your CPP file contains an error, the default value should be in the declaration of the function.

If you are using Qt >= 5.7, you can simply use the override keyword as C++11 support is mandatory since that version. Q_DECL_OVERRIDE was used to allow compatibly with non-C++11 enabled compilers.

I hoped it was just that...

I moved the default value in the header file, same issue

[ I will update the code posted above so that I don't repost it everytime ]

[SGaist]

Did you try re-running qmake before building ?

[devhobby]

@SGaist

Did you try re-running qmake before building ?

Thank you, sir! That solved it :)

@JonB

I'm going back to your very original post and thinking about what you're actually trying to achieve anyway. The code we're talking about is all well & good, if you want to proceed, but I'm wondering about your expectations of the interface.

Back to the original post... at the moment I can successfully double-click items and edit them.

How they are edited and how the edit is going to affect the table and the database is something I believe I can do by myself now.

I guess I've caught the mechanism behind it!

BUT

One thing that has remained unresolved is the fact that anytime I change a field (setData() is called) the edited cell must change its background color.

I still don't get this one.

P.S: @JonB I wanted to thank you too. It's amazing the way you're helping me. I just can't thank you enough :)

[SGaist]

Do you mean you want to mark the cell as "edited" ?

[devhobby]

@SGaist said in QSqlRelationalTableModel with multiple Joins?:

Do you mean you want to mark the cell as "edited" ?

Yes but... my way!

I want to change it's background color to, say, Cyan.

This way the user, before committing the changes, can take a look and see what is going to really change in the database.

[SGaist]

One way could be to keep a vector of edited cells that you update when setData is called with the EditRole and that you will use when data is called for the BackgroundRole and you return the colour you want.

[devhobby]

@SGaist said in QSqlRelationalTableModel with multiple Joins?:

One way could be to keep a vector of edited cells that you update when setData is called with the EditRole and that you will use when data is called for the BackgroundRole and you return the colour you want.

Thank you. The problem is I can't find the method which allows me to change te color to a cell. I guess something like setBackgroundColor(row,column)

[SGaist]

Because there's none. Do you have a custom setData method ? If so you should emit the dataChanged signal properly and it should trigger an update of the view which should request all the roles including the one for background colour.

[devhobby]

@SGaist said in QSqlRelationalTableModel with multiple Joins?:

which should request all the roles including the one for background colour.

That! I don't know how to make such a request for the table view.

[SGaist]

That's what dataChanged is for.

[devhobby]

@SGaist said in QSqlRelationalTableModel with multiple Joins?:

That's what dataChanged is for.

In fact I emit the signal including the role

emit dataChanged(index, index, roleArray);

roleArray includes Qt::BackgroundColor

Now what? Where do I select the color the cell has to become?

[SGaist]

Re-implement the data method and handle the BackgroundRole special case there.

[devhobby]

@SGaist said in QSqlRelationalTableModel with multiple Joins?:

Re-implement the data method and handle the BackgroundRole special case there.

I now return the red color when the role is Qt::BackgroundColor

if (!item.isValid())
   return QVariant();

if(role == Qt::BackgroundRole)
    return QColor(255, 0, 0);

return QVariant();

My Table View now is all red without changing anything!

Also, is it good to return a default-constructed QVariant when no particular criteria are met?

[JonB]

@devhobby

My Table View now is all red without changing anything!

Have you understood you now need to look up the cell coordinates (item) in the vector of changed cells, as per:

@SGaist said in QSqlRelationalTableModel with multiple Joins?:

One way could be to keep a vector of edited cells that you update when setData is called with the EditRole and that you will use when data is called for the BackgroundRole and you return the colour you want.

[devhobby]

@JonB @SGaist said in QSqlRelationalTableModel with multiple Joins?:

@devhobby

My Table View now is all red without changing anything!

Have you understood you now need to look up the cell coordinates (item) in the vector of changed cells, as per:

@SGaist said in QSqlRelationalTableModel with multiple Joins?:

One way could be to keep a vector of edited cells that you update when setData is called with the EditRole and that you will use when data is called for the BackgroundRole and you return the colour you want.

I did it.

But now all the text is gone!

The color is applied to the modified cells.

But there's no text! Even if I don't edit any cell, the text is gone!

[JonB]

@devhobby
What? You want text as well as color? ;-)

I think you'll need to show us your data() function now?

[devhobby]

@JonB said in QSqlRelationalTableModel with multiple Joins?:

@devhobby
What? You want text as well as color? ;-)

I think you'll need to show us your data() function now?

Oh God, don't tell me it's another pain in the neck!

QVariant MyModel::data(const QModelIndex& item, int role) const
{
    if(role == Qt::BackgroundRole)
    {
        if(MainWindow::cellsEdited.contains(item))
            return QColor(66, 197, 244, 150);
    }

    return QVariant();
}

Yes... I want the background color to stay behind the text, of course...

[JonB]

@devhobby
You're supposed to be only handling Qt::BackgroundRole special case. The rest of the time presumably you want to return the inherited class's implementation of data(). So: instead of your return QVariant(); catch-all, you want whatever it is (remember I'm not C++) for return base::data(item, role);.

The idea is: your overload is not called only for the color (which is when role == Qt::BackgroundRole), it's called loads of other times for quite different information (including the text) with other values of role. You were returning an empty QVariant for any other "property" of the cell, including its text! That's how it works.

BTW, if it's any consolation, I'm as new to this as you are. So I didn't know it worked this way till earlier too.

[devhobby]

@JonB said in QSqlRelationalTableModel with multiple Joins?:

@devhobby
You're supposed to be only handling Qt::BackgroundRole special case. The rest of the time presumably you want to return the inherited class's implementation of data(). So: instead of your return QVariant(); catch-all, you want whatever it is (remember I'm not C++) for return base::data(item, role);.
The idea is: your overload is not called only for the color (which is when role == Qt::BackgroundRole), it's called loads of other times for quite different information (including the text) with other values of role. You were returning an empty QVariant for any other "property" of the cell, including its text! That's how it works.
BTW, if it's any consolation, I'm as new to this as you are. So I didn't know it worked this way till earlier too.

Oh ok thanks, it worked!

Do you know, by chance, in which order are setData() and data() called? When is data() specifically called? When a dataChanged signal is emitted?

[JonB]

@devhobby
Well, I presume:

• setData() is called whenever the data is changed/set
• dataChanged signal should be emitted by setData() whenever new data is different from current data
• data() is called many times, with whatever role aspect is wanted, not only by your code but also by Qt code whenever it wants a piece of information

http://doc.qt.io/qt-5/qt.html#ItemDataRole-enum:

enum Qt::ItemDataRole

Each item in the model has a set of data elements associated with it, each with its own role. The roles are used by the view to indicate to the model which type of data it needs. Custom models should return data in these types.