Switching tabs with table views , the grid does not disappear.

[Dax]

Thanks for the answer,

I checked the rowCount(). It looks ok to me. (Thats what the std::cout < .. is for.)

To making a minimal example it will take some time to do it but its a good idea.

Here are some screen shots:

This one shows the Input tab with no row added into the model:
empty-input.jpg

This one shows the Output tab after adding a output row into the model:
one-row-output.jpg

This one shows the Input tab again after adding the output row.
input-after-add-output-row.jpg

If you take a close look you can see that the grid lines are different in both tabs.

PS.
If someone is wondering, this application is a tool to do HW configuration for our own HW. Its usually not shipped to customers.

[d_stranz]

If you take a close look you can see that the grid lines are different in both tabs.

Yep. Are you sure you aren't mixing up the access to the underlying data structures somehow? If you add two rows to the Output table, do you see two ghost rows in the Input table? What happens if you remove an Output row?

[Dax]

(Sorry for my late response but I had to take a couple of days off.)

Are you sure you aren't mixing up the access to the underlying data structures somehow?

I have check this a couple of times. The method rowCount() returns the correct value. And the data in the table and the node tree are correct to.
See below why you are right about this.

If you add two rows to the Output table, do you see two ghost rows in the Input table?

Yes. Looks like the grid is drawn from the sum of all data rows over both tables.

What happens if you remove an Output row?

Good question, have to check it. (Need to implement this anyway.) If I remove all rows (clear all nodes) then the ghost grid is still there.

After some impl. time...

During implementing the removeRow() method, I saw a bugs in the node insert handling.
The underling Node tree structure calls a callback to inform about changes in the data. My model gets informed before and after new Nodes are inserted. The callback method in the model looks like this:

void ExtendedSignalModel::OnNodeBeforeInsert(DataChangeInfo a_info)
{
    if(!NodeIsHandledHere(a_info.node1))
    {
        return;
    }
    beginInsertRows(QModelIndex(), a_info.row, a_info.row);
    m_CallEndInsertRows = true;
}

void ExtendedSignalModel::OnNodeBeforeInsert(DataChangeInfo a_info)
{
    if(!NodeIsHandledHere(a_info.node1))
    {
        return;
    }
    beginInsertRows(QModelIndex(), a_info.row, a_info.row);
    m_CallEndInsertRows = true;
}

To copy to clipboard, switch view to plain text mode 

The problem here is that the a_info.row value is not the model-row but the row (or index) in the internal Node data list which contains both, the input and output nodes.
Looks like the TableView uses the information from beginInsertRows() to draw the grid, not the rowCount().

Fixing this is not so easy, need to do some thinking.

I will comeback to you when this is done. I'm certain that this is the problem.
Thanks for all the help so far.

[d_stranz]

Looks like the TableView uses the information from beginInsertRows() to draw the grid, not the rowCount().

That doesn't sound right, but maybe there is some internal optimization to avoid redrawing the entire table on an insert.

[ChristianEhrlicher]

That doesn't sound right

Passing a wrong value to beginInsert/RemoveRows/Columns() is wrong since this triggers a lot of stuff (e.g. adjusting the persistent indexes/editors, saving the header visibility state, mapping from visible to logical columns, ...). So rowCount() must return the correct value afterwards but can't be used internally.

[d_stranz]

So rowCount() must return the correct value afterwards but can't be used internally.

Granted. But when is the table itself actually redrawn? During or after all the internal reorganization has been completed? Since many implementations of data() might make use of rowCount() to check the validity of the QModelIndex passed as argument and since data() is almost certainly called during the repainting, rowCount() would have to be valid at that point.

My hunch is that because the OP is using a single tree-shaped model to supply different information to different views, both views are reacting to the same begin/end signals. And as you mentioned, the row indices are probably correct only for one of the two views.

[ChristianEhrlicher]

The redraw happens after endInsert/RemoveRows/Columns() and then the internal data structure is used to draw the cells, rowCount() must then match the internal rowCount().

[Dax]

Hi everyone,

finally I found some time to work on the Qt application again.
(When customers needs new functionality then every thing else has to be put on hold.)

I fixed the bad behavior of my model implementation and now it works as intended.
This strange looking error, the grid I mean, and the real problem behind it gave me a lot
of headache (figurative).
Thanks to all of you, the problem could be solved.

Maybe some else can benefit from this thread.

Many thanks
Dax