Update QHeaderView section count to reflect changes in the model

skebanga

That's it! Thank you!

All that is required is to emit the headerDataChanged signal from the model

if (_model.columnCount() != _tree.header()->count())
    emit _model.headerDataChanged(Qt::Horizontal, 0, _model.columnCount());

The newly added columns appear now.

Additional feedback of the change propagating is evidenced by connecting to the QHeaderView::sectionCountChanged slot:

if (_model.columnCount() != _tree.header()->count())
{
    // just to prove this is working
    connect(_tree.header(), &QHeaderView::sectionCountChanged, [](int old_count, int new_count)
            {
                std::cout << "sectionCountChanged: " << old_count << " -> " << new_count << "\n";
            });
    emit _model.headerDataChanged(Qt::Horizontal, 0, _model.columnCount());
}

Results in the following on stdout:

sectionCountChanged: 28 -> 31

kshegunov

@skebanga
You're welcome, I'm glad it worked.

SGaist

Hi,

Out of curiosity, are you emitting the signal from outside of the model ?

skebanga

@SGaist:

Out of curiosity, are you emitting the signal from outside of the model ?

I am, as detailed in my previous reply:

emit _model.headerDataChanged(Qt::Horizontal, 0, _model.columnCount());

AFAIK emit is just syntactic sugar, and doesn't actually do anything.

So the same effect could be had by just doing:

_model.headerDataChanged(Qt::Horizontal, 0, _model.columnCount());

I leave emit in just to show that it's a signal I'm calling rather than a vanilla member function

PS: Forgive the delay in responding, I don't have the required reputation on here to post more than 1 message every 500 seconds

kshegunov

@skebanga said:

Forgive the delay in responding, I don't have the required reputation on here to post more than 1 message every 500 seconds

Now you do. Cheers.

skebanga

@kshegunov

:) thanks!

SGaist

Indeed emit is a macro that turns empty. The point is that from a coding point of view, you don't "emit from another class". Signals are emitted from within the class or the sub-class you just wrote.

Doing like you do right now makes the code confusing and also breaks the single responsibility principle i.e. why would your containing widget play with "internals" of your model ?

skebanga

@SGaist Fair enough - point noted, thanks for the suggestion

skebanga

@SGaist

one thing to note though, re emitting a signal from externally to the model, is that this is an interplay between the view and the model.

The model shouldn't need to know anything about the view, but in this case, it's the fact that the model's columnCount() has increased, whilst the view's hasn't.

In terms of best practice, would you suggest anything in this case?

SGaist

Technically the "last number of columns" is rather a model specific data. Since that part can change, the model should check the last value and then emit the signal accordingly.

The section ordering part, on the other hand, is indeed view specific data and the model shouldn't do anything with them.