QSqlRelationalTableModel with multiple Joins?

SGaist · 8 Feb 2018, 21:57

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 · S SGaist 8 Feb 2018, 21:34

@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 · 8 Feb 2018, 22:25

That's what dataChanged is for.

devhobby · S SGaist 8 Feb 2018, 21:59

@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 · 8 Feb 2018, 22:44

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

devhobby · 8 Feb 2018, 22:48

@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 · 2 Aug 2018, 22:50

@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 · 8 Feb 2018, 23:15

@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 · 8 Feb 2018, 23:17

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

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

devhobby · 2 Aug 2018, 23:18

@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 · 2 Aug 2018, 23:29

@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 · 2 Aug 2018, 23:32

@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 · 2 Aug 2018, 23:47

@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.

devhobby · 9 Feb 2018, 09:29

@JonB said in QSqlRelationalTableModel with multiple Joins?:

@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.

What I have noticed:

Double-Click signal on the Table View calls slot function onTableChanged()
onTableChanged() calls data() when it has finished
<>
Flags are checked
setData() is called if flag is editable
Signal dataChanged is emitted by setData()

Where's the problem?

Say I want to allow modification of some cells (name, surname...) and forbid modification of others (primary key, foreign key...)

I have a vector of immutable columns (0, 3, 5...)

I have to check if the column being edited belongs to the vector of immutable columns... TWICE!

One inside the flag() function and one inside onTableChanged()

Doing the check in flags() keeps me from modifying the content of the cell (hence, disabling the double-click)
Doing the check in onTableChanged() keeps the cells from being added to the vector of cells that need to be coloured by data()

Both checks are identical, but serve for 2 different purposes: one for disabling the double-click, the other for disabling the coloration.

All of these events are not sequential. I put a symbol <> in the list above to evidence two apparently unrelated events.

If these events had been sequential, I would've written only ONE check at the beginning of the event.

So, the question is: should I keep the situation this way (2 checks)?

SGaist · 9 Feb 2018, 12:00

If you overwrote the flags method correctly, you shouldn't be able to edit the corresponding cell so you shouldn't have to make several checks.

VRonin · wrote on 9 Feb 2018, 09:26

@devhobby said in QSqlRelationalTableModel with multiple Joins?:

@VRonin said in QSqlRelationalTableModel with multiple Joins?:

See https://forum.qt.io/topic/85973/how-to-simply-change-the-background-colour-of-a-cell-inside-a-tableview

Thanks but before doing that

This discussion went on way too long because you didn't bother looking at that link.

The solution is already presented there. Basically you need a proxy between the QSqlQueryModel and the view that can handle data changes. That link presents you with an example implementation. You can then use the dataChanged signal of the proxy to detect things you probably want to send to db

P.S.
Be careful that proxy considers Qt::EditRole as separate from Qt::DisplayRole

JonB · 9 Feb 2018, 10:10

@devhobby
Yeah, I don't really understand what you're saying, and I don't seem to have the knack of the miraculous correct interpretations @SGaist comes up with :)

If I understand right, you should have two different method overloads doing different things for what you want:

data(): when called for BackgroundRole, this will look up your vector of changed cells to determine the desired color.
flags(): when called, this should look up whether this is to be an editable cell, which depends on column (PK/FK versus others), but not your "edited vector". That will determine whether or not it returns Qt::ItemIsEditable. If it's not editable, Qt won't let it get edited.

VRonin · 9 Feb 2018, 10:22

@JonB There is one more point: setData should actually do something. QSqlQueryModel::setData is just a return false;

JonB · V VRonin 9 Feb 2018, 10:10

@VRonin
Yes, he's supposed to know that from when I pointed him at:

Ah ha!! Here's what we wanted to know:
http://doc.qt.io/qt-5/qsqlquerymodel.html#details

The model is read-only by default. To make it read-write, you must subclass it and reimplement setData() and flags(). Another option is to use QSqlTableModel, which provides a read-write model based on a single database table.

way earlier! :)

devhobby · 9 Feb 2018, 12:38

@SGaist said in QSqlRelationalTableModel with multiple Joins?:

If you overwrote the flags method correctly, you shouldn't be able to edit the corresponding cell so you shouldn't have to make several checks.

The flag() check is:

    if(MainWindow::isConstColumn(index.column()))
        QAbstractItemModel::flags(index) & (~Qt::ItemIsEditable);

    else
        return QAbstractItemModel::flags(index) | Qt::ItemIsEditable;

Qt::ItemIsEditable is only assigned when the cell being modified isn't found in the vector of immutable cells.

In data() the check is similar:

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

    if(role == Qt::BackgroundRole)
    {
        if(MainWindow::cellsEdited.contains(item))
            return QColor(66, 197, 244, 150);
    }

    return QSqlQueryModel::data(item, role);

However, removing the check from either part is disastrous:

Removing the check from flags() makes no cell editable
Removing the check from data() makes all the cell blue as soon as the program starts