c++ - Qt信号/插槽实际上如何与.ui文件中的元素耦合？

Question

我目前正在研究Qt项目，并且对信号和插槽机制有些困惑。但是，我觉得我对QObject和用户界面形式之间的区别有了一定的了解。

用户界面形式(由.ui文件描述)被馈送到用户界面编译器(uic)中，并生成关联的头文件。该头文件不仅包含接口(interface)信息，还包含应格式化的QObject的实现细节。另一方面，QObject是许多Qt框架都建立在其上的基类。信号和插槽系统完全基于QObject。

扩展QObject类(或从派生类)时，实际上是在定义一个可以在其中产生信号和插槽的对象。要格式化该对象使其看起来像您刚刚在Qt Designer中设计的用户界面，请创建ui类的实例(通过uic生成的ui header )。您可以在此类上调用setup方法，并将其提供给您正在创建的新QObject。

这一切似乎都是有道理的。

但是，没有意义的是当您开始实际定义信号时。通过Qt Designer，我可以选择右键单击并选择一个“信号”。当我选择一个信号时(无论是鼠标单击按钮还是在进度栏中进行更改)，最终都会将其添加到我的QObjects信号部分。我的问题是:为什么以及如何做？ Qt Designer(一个为uic生成XML的程序)在Qt Designer中的 Action 与Qt Creator中的QObject耦合得如何？更具体地说，它如何知道将此插槽添加到哪个QObject？

这个问题可能还不清楚，所以我在这里举一个例子。

例如，我要创建某种新的交互式显示。我们称之为“MyScreen”。为了创建此界面，我可能会有3个文件:“myscreen.h”，“myscreen.cpp”和“myscreen.ui”。 “myscreen.h”负责声明QObjects属性和方法以及信号和插槽。 “myscreen.cpp”负责定义方法，信号和插槽。 “myscreen.ui”负责创建用于格式化MyScreen实例的用户界面布局。

但是由于我之前所说的ui仅用于生成 header ，为什么将它精确地耦合到“myscreen.cpp”？也就是说，我可以右键单击.ui布局，创建一个新的信号类型，然后将该信号类型添加到myscreen.h和myscreen.cpp中。这是怎么发生的？它如何耦合？ Qt是否可以始终存在3个文件(xxx.h，xxx.cpp，xxx.ui)运行？

因此，希望能为您提供一些我感到困惑的背景。似乎没有一个写得很好的文件(至少我已经找到)，该文件彻底描述了所有这些项目之间的潜在关系。

TLDR-.h和.cpp中的信号/插槽实际上如何链接到.ui文件中定义的元素？

Answer 1

My question is: why and how? How exactly are my actions in Qt Designer (a program that generates an XML for the uic) getting coupled to my QObject in Qt Creator? More specifically, how does it know which QObject to add this slot to?

简短的答案是:魔术。

真正的答案是，它实际上与您在Designer中的操作无关，至少没有直接关系。实际上，它甚至不是特定于UI的东西，只是设计师可以充分利用它。这是怎么回事:

首先，每次您编译使用 Q_OBJECT宏的文件时，都会触发Qt的 moc工具在编译过程中运行(“触发”实际上并不是最准确的描述:更确切地说，当 qmake运行以生成makefile时， ，当在 header 中检测到 moc时，它会添加构建规则以运行 Q_OBJECT，但这只是重点。详细信息超出了此答案的范围，但长话短说，它最终会生成您将在编译后看到的 moc_*.cpp文件，其中包含一大堆已编译的元信息。此操作的重要部分是生成有关您声明的各种信号和插槽的运行时可访问信息。您将在下面看到这一点的重要性。

另一个重要的事情是所有 QObject都有 a name。在运行时可以访问该名称。您在设计器中为窗口小部件指定的名称被设置为窗口小部件的对象名称。这很重要的原因也将在下面阐明。

最后重要的是 QObject具有分层结构；创建 QObject时，可以设置其父代。表单上的所有小部件最终都将表单本身(例如，源自 QMainWindow的类)作为其父级。

好吧

您会在Qt为您的Windows生成的源代码中注意到，在构造函数中始终具有 ui->setupUi(this)调用。该功能的实现是由Qt的 uic工具在编译过程中生成的，例如 ui_mainwindow.h。该函数是您在设计器中设置的所有属性的实际设置，其中存储了.ui文件，包括小部件的对象名。现在，生成的 setupUI()实现的最后一行是关键:

void setupUi(QMainWindow *MainWindow) {
    ...
    // Object properties, including names, are set here. This is 
    // generated from the .ui file. For example:
    pushButton = new QPushButton(centralWidget);
    pushButton->setObjectName(QString::fromUtf8("pushButton"));
    pushButton->setGeometry(QRect(110, 70, 75, 23));
    ...
    // This is the important part for the signal/slot binding:
    QMetaObject::connectSlotsByName(MainWindow);
}

该函数 connectSlotsByName 是所有这些小部件信号发生魔术的地方。

基本上，该功能执行以下操作:

遍历您声明的所有插槽名称，因为它全部由元对象信息中的moc打包到运行时可访问的字符串中，所以可以这样做。

当找到名称与on_<objectname>_<signalname>模式匹配的插槽时，它将在对象层次结构中递归搜索名称为 的对象，例如您的命名小部件之一，或您可能创建的任何其他命名对象。然后，它将对象信号 连接到找到的插槽(它基本上自动执行对 QObject::connect(...)的调用)。

就是这样。

因此，这意味着，当您转到那里的插槽时，设计师中实际上没有发生什么特别的事情。发生的所有事情是设计器将一个具有适当参数的名为on_widgetName_signalName的插槽插入 header ，并为其生成一个空函数体。 (thuga已为此添加 a great explanation)。这足以让 QMetaObject::connectSlotsByName在运行时找到它并建立连接。

这里的含义非常方便:

您可以删除窗口小部件的信号处理程序，而无需在设计器中进行任何特殊操作。您只需从源文件中删除插槽及其定义，它们就完全独立了。

您可以手动添加小部件信号处理程序，而无需通过设计器界面，这有时可以节省一些乏味。您要做的就是在窗口中创建一个名为on_lineEdit1_returnPressed()和voila，它有效。您只需要小心，就像海德在评论中提醒我们的那样:如果您在此处出错，则不会收到编译时错误，您只会收到打印到stderr的运行时警告，而连接不会被创造；因此，如果您在此处进行任何更改，请务必注意控制台输出。

这里的另一个含义是此功能实际上并不限于UI组件。 moc在所有 QObject上运行，并且 connectSlotsByName始终可用。因此，您创建的任何对象层次结构，如果命名对象，然后使用适当的名称声明插槽，则可以调用 connectSlotsByName自动建立连接；碰巧 uic会在 setupUi的末尾粘贴调用，因为这是放置它的方便位置。但是魔术不是特定于UI的，也不依赖 uic，仅依赖于元信息。这是一种普遍可用的机制。非常干净。

顺便说一句:我在 GitHub上贴了一个 QMetaObject::connectSlotsByName的简单示例。