2019-08-14起笔
小熊的情况描述：
父类A继承自QWidget，所以父类A自动添加了Q_OBJECT。 子类B继承自父类A，子类B没有添加Q_OBJECT。在子类B中给动态创建的控件添加事件和槽。编译通过，无警告，无错误。运行时，应用程序输出栏显示：QObject：：connect: No Such slot ......
网上扒拉扒拉很多网友给的方案是这样的：
以后要是碰到no such slot的问题
、添加头文件#include<QCoreApplication>
、看类声明中有没有Q_OBJECT
、看slot函数有没有声明 private slots:
void xxxx(); 、查看slot有没有出现拼写错误～～～
然而，小熊并没有从方案一受益，于是接着发现了下面这样一个方案：
在xxx.pro文件中添加 OBJECTS_DIR = tmp
MOC_DIR = tmp
哈哈~百试不爽。 非常OK。
但是，问题接踵而至，再添加子类，子类C继承父类A，同样的场景，同样的处理方法，不见效了....what??？请教网友了。
2019-08-16续写
基类B和基类C的信号和槽的关联方式为：
connect(m_lineEditL, SIGNAL(editingFinished()), this, SLOT(slotsLineEditContentVerify()));
今天在小熊在尝试两种方式使用线程的时候，我发现用另一个版本的connect比上面使用SIGNAL/SLOTS宏的版本好用，因此尝试做如下修改：
QObject::connect(m_lineEditL, &QLineEdit::editingFinished, this, &ZLayout::slotsLineEditContentVerify);
问题搞定，perfect。
回过头来思考， 编译错误提示是没有 基类::slotsFunctiong, 而this执行对象，是从基类继承而来的，我们又知道带宏定义SIGNAL/SLOTS版本的connect仅仅是做函数名的字符串替换，并不会像上面第二个版本一样进行类型检查，所以导致了异常现象的出现。
然后把修改工程文件的事情删掉，并不影响什么，说明不需要更改工程文件。 另外，每一个基类都应当采用第二种版本的connect。
小熊分析的真棒！！！
网友的力量真强大！！！
2019年08月18日续写
重读16日续写的内容，冥冥之中感觉到自己的解释不能够清晰的说服自己。 同时，无敌小熊猜疑到另一个点，是否是在父类A中声明一个跟基类B和基类C用到的槽函数一样的虚槽函数，问题一样可以解决呢，于是动手尝试了一下，在父类A中做如下补充：
parentCalss.h public slots:
virtual void slotsLineEditContentVerify(); ...
parentClass.cpp
void slotsLineEditContentVerify()
{
}
这种方案下，两种connect版本都可以达到想要的效果。
通过对比，小熊再次认定第二种版本的connect好用，为啥呢，可以少做不必要的事情而达到相同的目的。至于8月18号解释的原因小熊日后再做校准。