QSqlRelationalTableModel with multiple Joins?

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

[devhobby]

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

1. Double-Click signal on the Table View calls slot function onTableChanged()
2. onTableChanged() calls data() when it has finished
   <>
3. Flags are checked
4. setData() is called if flag is editable
5. 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]

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]

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

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

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

[JonB]

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

@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

[JonB]

@devhobby said in QSqlRelationalTableModel with multiple Joins?:

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

There is no return statement there??????