TableView.forceLayout() seems prone to throwing assertions related to internal
data structures being out of sync with the number of rows and columns from the
QAbstractTableModel used. Some of these assertions were fixed in 5.13.0, more
were fixed in 5.13.1. But this one still remains:
items/qquicktableview.cpp:458:void QQuickTableViewPrivate::dumpTable() const():
"table cells: (4,0) -> (15,15), item count: 160, table rect: 270,0 x 1040,704"
items/qquicktableview.cpp:477:auto
QQuickTableViewPrivate::modelIndexAtCell(const QPoint &)::(anonymous
class)::operator()() const(): output: modelIndex: 915 cell: QPoint(15,0) count:
915
items/qquicktableview.cpp:477:None(): ASSERT: "(modelIndex < model->count()) ||
[&](){ dumpTable(); qWarning() << "output:" << "modelIndex:" << modelIndex <<
"cell:" << cell << "count:" << model->count(); return false;}()" in file
items/qquicktableview.cpp, line 477
In many cases this assertion happens when TableView.rows is out of sync with
model.rowCount(), or TableView.columns is out of sync with model.columnCount().
The fact that these are out of sync at all seems to me to be a bug?
At any rate, this isn’t a reliable workaround. This happens most often when
emitting columnsRemoved() from the model while the column is visible. It never
occurs when the column is hidden, e.g. scrolled beyond the width of the
TableView’s viewport.
Is there something I’ve missed about the TableView implementation? Or does it
just early days yet for this QtQuick Item?
And for what it’s worth, QQuickTableView::dumpTable() was also throwing an
assertion regarding the GL context not matching when dumping the table to a
png. I commented out that code block to be able to see the original assertion
above.
Cheers,
-P_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
