Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what is the reason why the Qt signal function uses the inner type of the class as a parameter to lead to the failure of connect". In the daily operation, I believe that many people have doubts about the reason why the Qt signal function uses the inner type of the class as a parameter, which leads to the failure of connect. The editor consulted all kinds of materials and sorted out a simple and useful operation method. I hope it will be helpful to answer the question of "what is the reason why the Qt signal function uses the inner type of the class as a parameter that leads to the failure of connect?" Next, please follow the editor to study!

Problem code:

Sender.h

Class Sender: public QObject {Q_OBJECT public: explicit Sender (QObject * parent = nullptr); enum eResult {kSuccess, kFail,}; signals: void loginResult (eResult result); void otherSignal (QString str);}

Two signals are defined:

LoginResult () this signal takes eResult as a parameter, and eResult is a type defined within the Sender class.

OtherSignal (), as a reference, uses signals of the type defined by Qt.

Receiver.h

Class Receiver: public QObject {Q_OBJECT public: explicit Receiver (QObject * parent = nullptr); signals: public slots: void onLoginResult (Sender::eResult result); void onOtherSignal (QString str); private: Sender * sender_;}

Two slot are defined in Receiver to receive two signals from Sender.

In the constructor of Receiver:

Receiver::Receiver (QObject * parent): QObject (parent), sender_ (new Sender ()) {connect (sender_, SIGNAL (loginResult (Sender::eResult)), this, SLOT (onLoginResult (Sender::eResult); connect (sender_, SIGNAL (otherSignal (QString)), this, SLOT (onOtherSignal (QString);}

As a result, there was an error in running the Times:

The signal is not connected.

If we put eResult outside the Sender class, we don't have this problem.

Why is that?

Is it true that all types within the class will go wrong?

In order to rule out the reason for our custom enumerations, we changed our defined eResult to MyString, and changed the rest accordingly.

Try again:

As a result, an error was reported:

This also confirms my conjecture. Why is it?

Open the automatically generated moc_sender.cpp file to see the contents:

If we add another signal:

What changes will take place in moc_sender.cpp?

(1) there are two new literals in the literal quantity.

(2) there are also some new descriptions in qt_meta_data_Sender:

As you can see, qt_meta_data_Sender can describe what signal functions a QObject class has. What are the return types and parameters of each signal function.

As you can see from the above, the signal custom parameter type idx recorded in qt_meta_data_Sender points to MyString. We use Sender::MyString for connect () in Receiver. Could it be caused by the mismatch between the two?

If we change it like this:

Add the Sender:: prefix.

Let's see if it works. As a result, the report was not wrong again.

Let's take a look at the changes in moc_sender.cpp:

Conjecture:

In the following connect () code:

The SIGNAL () macro sets

A string precompiled into "loginResult (Sender::MyString)". During execution, it will take this string to the Sender object to find a signal with only one parameter named "loginResult" and a parameter type of "Sender::MyString" to connect.

If we write the parameter type of the loginResult signal as MyString instead of full Sender::MyString in Sender, it cannot find the signal in the qt_meta_data_Sender of Sender when connect (), so it fails.

If we continue to adopt the original practice:

In the place of connect (), write MyString instead of Sender::MyString, as follows:

Execute an error message:

It is said to be an incompatible parameter type.

Maybe the connect () function compares the parameter signal with the parameter type string of slot at the entrance, and if it is not consistent, it will be considered an error.

In turn, when we connect (), we write the parameter of slot as:

Execution result:

What if we change the parameter type of Receive::onLoginResult () to MyString?

As follows:

The compilation passes, and connect () is normal at run time.

Is it that it only recognizes the name of the type and does not make type deduction?

Let's make a bold attempt:

We assign a random type to MyString.

As a result, the compilation passes, and connect () is normal at run time.

MyString is essentially an alias for QString.

Won't connect () succeed if you use QString instead of MyString on the Receive side?

The following modifications are made:

The compilation is normal and the running result is:

This experiment is sufficient to prove that connect () only cares about the comparison of type names and does not make any type deduction at all.

To sum up the conclusion:

When QObject::connect () is executed, it compares the names of the signal and slot parameters. Only if the names are consistent can they be connected, otherwise they will not fail.

It is worth noting that it only compares the names of types and does not do any type derivation or type checking at all.

At this point, the study of "what is the reason why the Qt signal function uses the inner type of the class as a parameter that leads to the failure of connect" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.