Multi-line messages in QTableView

[Conel]

I use QTableView to show data contained in my LogsModel (which inherits QAbstractTableModel). In order to enable sorting and filtering I use QSortFilterProxyModel as a proxy between LogsModel and QTableView. LogsModel is refreshed from time to time (it takes additional items from the database)

Now the problem is that my model can contain multi-line text strings. In that case I have the following problem with displaying these messages: I can see only the bottom of the first line and the top of the second line (in case of 2-lined message)

This issue can be easily solved if I invoke method resizeRowToContents(int i) of QTableView class. But the problem is that table is refreshed from time to time (when changing sorting order, or when filter is applied, or some new items appear in LogsModel). So every time it refreshes I should resize all the rows in the table (because I don't know exact place where new rows have appeared). But this is very time-consuming because table may contain thousands rows.

So, the question is: how to make multi-line message fully visible in QTableView taking into account all that I said before.

Probably I can resize only currently visible rows. In this respect my question is: how can I get to know which rows of the QTableView are currently visible?

[KShots]

This is a known bug in both 4.0.1 and 4.1.1

Use either 4.1.0 or 4.1.2 to fix this.

See also this (http://www.qtcentre.org/forum/showthread.php?t=1289) thread.

[Conel]

Thanks for the info. The problem is that for QTreeView this issue is fixed but not for QTableView. I'm using Qt 4.1.2 and for different source code I have different results



#include <QApplication>
#include <QTableView>
#include <QTreeView>
#include <QStandardItemModel>
int main(int argc, char **argv)
{
QApplication app(argc, argv);
QTreeView view;
QStandardItemModel *model = new QStandardItemModel;
// Prepend 4 rows into the model
model->insertRows(0, 4);
// Prepend 4 columns into the model
model->insertColumns(0, 4);
for (int row = 0; row < 4; row++)
{
for (int col = 0; col < 4; col++)
{
// Return a model index for the given row and column.
QModelIndex index = model->index(row, col);
// Set the index's data to the specified value
model->setData(index, QVariant("hello\nnextline\nonemoreline"));
}
}
view.setModel(model);
view.show();
return app.exec();
}


Here the result:
298

Now I'm changing only one line: QTreeView is replaced with QTableView



#include <QApplication>
#include <QTableView>
#include <QTreeView>
#include <QStandardItemModel>
int main(int argc, char **argv)
{
QApplication app(argc, argv);
QTableView view;
QStandardItemModel *model = new QStandardItemModel;
// Prepend 4 rows into the model
model->insertRows(0, 4);
// Prepend 4 columns into the model
model->insertColumns(0, 4);
for (int row = 0; row < 4; row++)
{
for (int col = 0; col < 4; col++)
{
// Return a model index for the given row and column.
QModelIndex index = model->index(row, col);
// Set the index's data to the specified value
model->setData(index, QVariant("hello\nnextline\nonemoreline"));
}
}
view.setModel(model);
view.show();
return app.exec();
}


And now I have the wrong output:
299

Do you think I should send this as a bug to Trolltech?

[KShots]

Yeah, I think they must not have fixed the problem fully yet. Check to see if someone already has an active bug submitted, and if not tell the Trolls exactly what you said here (very good detail).

[Brandybuck]

Have you tried resizeRowsToContents()?

[Conel]

Yes, I did. Invoking method reziseRowsToContents() makes multiline messages fully visible but this does not suit my needs. I use QTableView with my own model which takes items from the database and refreshes quite often. Since I also use QSortFilterProxyModel I can't predict where updated rows will appear. So every time I refresh the model I should invoke resize method for all rows in the table. Since the table may contain thousands of rows this is very time-consuming. So this workaround can not be applied here

[KShots]

Not only that, but he shouldn't have to fix TT bugs in his code. Much better for everyone if TT fixes this - they've already determined that such behaviour is a bug on their part.