Qt QComboBox core principle analysis

Regarding how the QComboBox kernel is implemented and how it works, the analysis is as follows:

QComboBox is a window inherited from QWidget rewriting, and the 111 area is implemented with QLineEdit. The source code is as follows:

QLineEdit *lineEdit() const;

Zone 2 is made with a toolbutton similar to that you can use to pull down events and change icons

 

The event of Zone 2 will pop up an associated ListView window, the system kernel will pop up a similar qlistview associated with the window, the associated qlistview uses the model-view-delegate structure,

The listview responds to the events that are responded to and handles the data processing associated with the 111,2 area.

So QComboBox can be freely transformed into various shapes, such as irregular shapes such as rounded rectangles, and her lineEdit component can also be replaced. From the source code, it can be seen that it deletes the original default lineEdit and then replaces it with a new LineEdit The source code is as follows:

void QComboBox::setLineEdit(QLineEdit *edit)

{

。。。

    if (edit == d->lineEdit)

        return;

 

    edit->setText(currentText());

    delete d->lineEdit;

 

d->lineEdit = edit;

。。。

}

Its associated listview principle is similar, so it can be freely transformed, and independent transformation,

This may be a bug

        auto aaa = new QListView ();

        m_pComboBox->setView(aaa);

        aaa- > setStyleSheet ( "QAbstractItemView :: item {height: 35px;}" ); In this way, the height of the item can be set successfully,

But this will not work, in fact, its logical meaning should be the same, all are to modify the view

m_pComboBox->view()->setStyleSheet("QAbstractItemView::item{height:35px;}");

If you need to make ui more complex and changeable, you can rewrite a listview, as long as the effect that listview can do, QComboBox can do it.

 

Since the listview associated with QComboBox should be independent, you can freely draw the desired effect, but there is still a certain association. When setting the window to a rounded rectangle, generally according to the object-oriented idea, the corresponding listview should be set It can be a rounded rectangle, but the effect is not particularly ideal, such as the following code:

        m_pComboBox->view()->window()->setWindowFlags(Qt::Popup | Qt::FramelessWindowHint | Qt::NoDropShadowWindowHint);

        m_pComboBox->view()->window()->setAttribute(Qt::WA_TranslucentBackground);

        m_pComboBox->view()->setStyleSheet(R"(

       QAbstractItemView {

      border-radius: 14px ;

      background-color:rgb(134,134,134);

      }

)");

The effect has reached a rounded rectangle, but there will be a shadow, but the code has NoDropShadowWindowHint , and the shadow       has been removed, so it feels a bit illogical here. If you change the code to m_pComboBox / * -> view () * /-> setStyleSheet ( R "(

       QAbstractItemView {

      border-radius: 14px ;

      background-color:rgb(134,134,134);

      }

It can achieve the desired effect, there will be no shadow, because it has been removed, it is logical.

It is roughly guessed that its underlying implementation may be that when using the internal view stylesheet, the drawing function executed by the bottom layer is only its corresponding listview, but this NoDropShadowWindowHint bottom layer should be related to the parent class QComboBox, so it will Some drawing actions do not take effect, because no related actions are performed to their parent class, so it will cause NoDropShadowWindowHint to not take effect, so Qt has its own rules and routines, so if you need to draw in QComboBox, do not use it The corresponding basically encapsulated sub-window, if you need to draw, try to use the QComboBox class itself, there will be no such similar problems.

 

 

 

Published 85 original articles · praised 18 · 120,000 views

Guess you like

Origin blog.csdn.net/a1317338022/article/details/105281272