Following example from this link: http://developer.kde.org/documentation/books/kde-2.0-development/ch03lev1sec3.html
#include <QObject>
#include <QPushButton>
#include <iostream>
using namespace std;
class MyWindow : public QWidget
{
Q_OBJECT // Enable slots and signals
public:
MyWindow();
private slots:
void slotButton1();
void slotButton2();
void slotButtons();
private:
QPushButton *button1;
QPushButton *button2;
};
MyWindow :: MyWindow() : QWidget()
{
// Create button1 and connect button1->clicked() to this->slotButton1()
button1 = new QPushButton("Button1", this);
button1->setGeometry(10,10,100,40);
button1->show();
connect(button1, SIGNAL(clicked()), this, SLOT(slotButton1()));
// Create button2 and connect button2->clicked() to this->slotButton2()
button2 = new QPushButton("Button2", this);
button2->setGeometry(110,10,100,40);
button2->show();
connect(button2, SIGNAL(clicked()), this, SLOT(slotButton2()));
// When any button is clicked, call this->slotButtons()
connect(button1, SIGNAL(clicked()), this, SLOT(slotButtons()));
connect(button2, SIGNAL(clicked()), this, SLOT(slotButtons()));
}
// This slot is called when button1 is clicked.
void MyWindow::slotButton1()
{
cout << "Button1 was clicked" << endl;
}
// This slot is called when button2 is clicked
void MyWindow::slotButton2()
{
cout << "Button2 was clicked" << endl;
}
// This slot is called when any of the buttons were clicked
void MyWindow::slotButtons()
{
cout << "A button was clicked" << endl;
}
int main ()
{
MyWindow a;
}
results in:
[13:14:34 Mon May 02] ~/junkPrograms/src/nonsense $make
g++ -c -m64 -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/opt/qtsdk-2010.05/qt/mkspecs/linux-g++-64 -I. -I/opt/qtsdk-2010.05/qt/include/QtCore -I/opt/qtsdk-2010.05/qt/include/QtGui -I/opt/qtsdk-2010.05/qt/include -I. -I. -o signalsSlots.o signalsSlots.cpp
g++ -m64 -Wl,-O1 -Wl,-rpath,/opt/qtsdk-2010.05/qt/lib -o nonsense signalsSlots.o -L/opt/qtsdk-2010.05/qt/lib -lQtGui -L/opt/qtsdk-2010.05/qt/lib -L/usr/X11R6/lib64 -lQtCore -lpthread
signalsSlots.o: In function `MyWindow::MyWindow()':
signalsSlots.cpp:(.text+0x1a2): undefined reference to `vtable for MyWindow'
signalsSlots.cpp:(.text+0x1aa): undefined reference to `vtable for MyWindow'
signalsSlots.o: In function `MyWindow::MyWindow()':
signalsSlots.cpp:(.text+0x3e2): undefined reference to `vtable for MyWindow'
signalsSlots.cpp:(.text+0x3ea): undefined reference to `vtable for MyWindow'
signalsSlots.o: In function `main':
signalsSlots.cpp:(.text+0x614): undefined reference to `vtable for MyWindow'
signalsSlots.o:signalsSlots.cpp:(.text+0x61d): more undefined references to `vtable for MyWindow' follow
collect2: ld returned 1 exit status
make: *** [nonsense] Error 1
vtable is for virtual functions, AFAIK, what's the reason of error here?
It looks like moc doesn't generate code for your QObject because you declare it in the .cpp file. The easiest way to fix that is to move the declaration of MyWindow to a header, and add the header to the HEADERS list, in the .pro file:
HEADERS += yourheader.h
Then rerun qmake.
(Please note that the KDE 2.0 book you look at is vastly outdated)
Maybe too late but... Had the same issue and fighted for a while to find where it comes from.
Right click on your project and select “Run qmake” to for a new build of MOC classes. It usually does run automatically...
The moc compiler generates the stubs and calls in moc_xxxx.cpp, and generates the vtable stuff
Just Change your Main() as follows:
#include <QtGui/QApplication>
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MyWindow w;
w.show();
return a.exec();
}
Based on andref comment just above, when everything is in one cpp file like stuff.cpp, you need to add at the end of the file:
#include "moc_stuff.cpp"
(this is with Qt 4.7.0)
This issue may be caused by some of the following reasons. I have stumbled on all of them from time to time.
Your class header may be missing the Q_OBJECT macro. Add the macro to the header as already noted by other answers.
class MyWidg : public QWidget
{
Q_OBJECT
Your class header may not be parsed by the moc. Add the header file in the HEADERS definitions of your .pro (or .pri) project file.
HEADERS += file.h
If none of the above is true, then you probably need to run qmake again to make sure moc parses the header again, just in case the Q_OBJECT macro was added in the header after the qmake was run. Just run qmake again.
Related
I cannot get rid of the error "Undefined reference to vtable" when compiling my Linux desktop application.
I did find the thread
Undefined reference to vtable
I have a
set(CMAKE_AUTOMOC ON)
in my CMakeLists.txt
but I receive
AutoMoc warning
---------------
"SRC:/QtGUI/BASIC/SimulatorWindowBasic.cpp"
includes the moc file "SimulatorWindowBasic.moc", but does not contain a Q_OBJECT, Q_GADGET, Q_GADGET_EXPORT, Q_NAMESPACE or Q_NAMESPACE_EXPORT macro.
despite that my definition contains
a Q_Object.
At the end of build, I receive the feared message
/usr/bin/ld: CMakeFiles/Basic_GUI.dir/Basic_GUI.cpp.o: in function `main':
/Myhome/main/BASIC/Basic_GUI.cpp:6: undefined reference to `SimulatorWindowBasic::SimulatorWindowBasic(int, char**, QWidget*)'
/usr/bin/ld: CMakeFiles/Basic_GUI.dir/Basic_GUI.cpp.o: in function `SimulatorWindowBasic::~SimulatorWindowBasic()':
What do I wrong?
Below I show my relevant sources.
(in my previous install using Qt5 and Ubuntu 20.04
I did not experience this issue. The present install uses Ubuntu 22.04 and Qt 6.4.2)
#ifndef SimulatorWindowBasic_H
#define SimulatorWindowBasic_H
#include <QMainWindow>
namespace Ui {
class SimulatorWindowBasic;
}
class SimulatorWindowBasic : public QMainWindow
{
Q_OBJECT
public:
explicit SimulatorWindowBasic(int argc, char **argv, QWidget *parent = 0);
virtual ~SimulatorWindowBasic();
protected:
Ui::SimulatorWindowBasic *ui;
};
#endif // SimulatorWindowBasic_H
and
#include "SimulatorWindowBasic.moc"
#include "SimulatorWindowBasic.h"
#include "uiSimulatorWindowBasic.h"
SimulatorWindowBasic::SimulatorWindowBasic(int argc, char **argv, QWidget *parent) :
QMainWindow(parent),
ui(new Ui::SimulatorWindowBasic)
{
ui->setupUi(this); // This creates the basic splitters
}
SimulatorWindowBasic::~SimulatorWindowBasic
{
}
You have to include "moc_SimulatorWindowBasic.cpp" because you want to have moc run on a header (and not on your source) as described in the cmake documentation
I wrote a little program with a my own class within the main.cpp. Here the code:
#include <QApplication>
#include <QPushButton>
#include <QLabel>
class MyWidget : public QWidget {
//Q_OBJECT
public:
MyWidget(QWidget* parent = 0);
QLabel* label;
QString string;
signals:
public slots:
void setTextLabel();
};
void MyWidget::setTextLabel() {
label->setText("Test");
}
MyWidget::MyWidget(QWidget* parent)
: QWidget(parent) {
}
int main(int argc, char** argv) {
QApplication app(argc, argv);
MyWidget widget;
widget.show();
return app.exec();
}
it seems work but not "completely". My slot doens't work. I suppose i have to put Q_OBJECT. BUT, doing so, I got a list of errors, like this:
undefined reference to `vtable for MyWidget'
........................................
collect2: error: ld returned 1 exit status
make: *** [mywidget] Error 1
I can I manage that? Where the problem?
Signals and slots in Qt are managed through the moc: meta object compiler. Basically, the moc generates additional C++ code for each class containing the Q_OBJECT macro in order to implement effectively the signals and slots mechanisms. The additional code is then linked to the original class declaration.
The problem here is that your class is declared in main.cpp: this conflicts with how the moc is working with your code. You should declare your class in a separate header.
More about the moc
Edit: as hyde pointed, an alternative is to include in your cpp the file generated by the moc: Why is important to include “.moc” file at end of a Qt Source code file?
just append the line #include"main.moc" to your cpp source file should be enough.
More information:
Why is important to include ".moc" file at end of a Qt Source code file?
For some reason the Qt compiler doesn't compile if you try to pass a QObject derived class as the rparent to a QWidget derived class.
What is the correct way to provide a parent to QWidget derived classes in a QObject derived class? I'm thinking of the following solutions:
Use a smart pointer with the QWidget classes, instead of giving the object a parent.
Derive from QWidget instead of QObject (Sounds wrong to me, since the class isn't a widget).
Pass a QWidget instance to the QObject derviced class which already has a parent, as I've tried to demonstrate in the example below:
#include <QApplication>
#include <QtWidgets>
class ErrorMsgDialog;
class Controller;
class MainWindow;
// This is the QWidget class used in the QObject derived class (DataReadController)
class ErrorMsgDialog : public QDialog
{
Q_OBJECT
public:
explicit ErrorMsgDialog(QWidget *parent = nullptr)
: QDialog(parent)
{
errorLbl = new QLabel("An unknown read error occured!");
QHBoxLayout* layout = new QHBoxLayout;
layout->addWidget(errorLbl);
setLayout(layout);
setWindowTitle("Error!");
setGeometry(250, 250, 250, 100);
}
~ErrorMsgDialog() { qDebug() << "~ErrorMsgDialog() destructed"; }
private:
QLabel* errorLbl;
};
// QObject derived class - I want to instatiate Qwidget derived classes here, with this class as parent
class DataReadController
: public QObject
{
Q_OBJECT
public:
DataReadController(QWidget* pw, QObject *parent = nullptr)
: QObject(parent)
{
m_errorMsgDialog = new ErrorMsgDialog(pw);
//m_errorMsgDialog = QSharedPointer<ErrorMsgDialog>(m_errorMsgDialog);
//m_dataReader = new DataReader(this); m_dataReader->moveToThread(m_dataReaderThread); connect(....etc
//simulate that DataReader emits an error msg
QTimer::singleShot(2000, [&]() {
onErrorTriggered();
});
}
public slots:
void onNewDataArrived() {}
// called if reader emits an error message
void onErrorTriggered() { m_errorMsgDialog->show(); }
private:
ErrorMsgDialog* m_errorMsgDialog;
//QSharedPointer<ErrorMsgDialog> m_errorMsgDialog;
//DataReader* m_dataReader;// DataReader is not shown here, it would be moved to a different thread and provide some data
};
// MainWindow
class MainWindow : public QMainWindow
{
Q_OBJECT
public:
MainWindow(QWidget *parent = nullptr)
: QMainWindow(parent)
{
parentWidget = new QWidget(this);
m_dataReadController = new DataReadController(parentWidget, this);
setGeometry(200, 200, 640, 480);
//Close after 5 seconds.
QTimer::singleShot(5000, [&]() {
close();
});
}
private:
QWidget* parentWidget; // QWidget to pass to OBject derive class for parenting QWidgets
DataReadController* m_dataReadController;
};
// Main
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec();
}
#include "main.moc"
This test crashes if I use QSharedPointer with ErrorMsgDialog.
Any suggestions on the way to do this? Maybe none of my suggested solutions is the best practise?
Correct storage and life-time management of dynamically created objects is not quite easy in C++. After a long time of struggling, I started to prefer certain techniques which I still use quite successful:
local variables (storage and life-time managed by scopes)
non-pointer member variables
smart pointers with clear ownership (shared pointer) or non-ownership (weak pointer).
With this, I banned raw pointers from my sources nearly completely resulting in much maintenance friendlier code and less annoying debugging.
Of course, when external libraries (like e.g. widget sets) come into play, then I am bound to their APIs.
Concerning gtkmm 2.4, the above techniques worked quite good as well. gtkmm provides
smart pointers for sharable objects
some kind of ownership for widgets concerning child widgets.
When I switched to Qt, I saw all the news and raw pointers in the tutorial samples which made me afraid a bit. After some experiments, I came to the conclusion that I will be able to write ful-featured Qt applications similar like I did before in gtkmm – without nearly any need of new by (again) defining widgets as local variables (e.g. in main()) or member variables of other classes derived (directly or indirectly) from QWidget.
Beside of this, over the time, I realized the general Qt concept of Object Trees & Ownership but I must admit that I rarely rely on this in daily business.
Concerning the specific problem of OP:
A QWidget is derived of QObject. Hence, the usual ownership principle of QObjects apply. Additionally, a QWidget expects another QWidget as parent. A QWidget may be parent of any QObjects but not vice versa.
Hence, I would suggest the following ownership:
MainWindow is parent of DataReadController
MainWindow is parent of ErrorMsgDialog (which is created in DataReadController).
DataReadController stores a pointer to ErrorMsgDialog as raw pointer. (I believe the ownership provided by a QSharedPointer would collide with the ownership of MainWindow.)
(As already described above, in my own programming, I would try to prevent pointers at all and use (non-pointer) member variables instead. However, IMHO that's a matter of style and personal preference.)
The modified sample of OP testQParentship.cc:
#include <QtWidgets>
class Label: public QLabel {
private:
const QString _name;
public:
Label(const QString &name, const QString &text):
QLabel(text),
_name(name)
{ }
virtual ~Label()
{
qDebug() << _name + ".~Label()";
}
};
class HBoxLayout: public QHBoxLayout {
private:
const QString _name;
public:
HBoxLayout(const QString &name):
QHBoxLayout(),
_name(name)
{ }
virtual ~HBoxLayout()
{
qDebug() << _name + ".~HBoxLayout()";
}
};
class ErrorMsgDlg: public QDialog {
private:
const QString _name;
public:
ErrorMsgDlg(const QString &name, QWidget *pQParent):
QDialog(pQParent),
_name(name)
{
QHBoxLayout *pQBox = new HBoxLayout("HBoxLayout");
pQBox->addWidget(
new Label("Label", "An unknown read error occured!"));
setLayout(pQBox);
setWindowTitle("Error!");
}
virtual ~ErrorMsgDlg()
{
qDebug() << _name + ".~ErrorMsgDlg()";
}
};
class DataReadCtrl: public QObject {
private:
const QString _name;
ErrorMsgDlg *const _pDlgErrorMsg;
public:
DataReadCtrl(const QString &name, QWidget *pQParent):
QObject(pQParent),
_name(name),
_pDlgErrorMsg(
new ErrorMsgDlg(name + "._pDlgErrorMsg", pQParent))
{
//simulate that DataReader emits an error msg
QTimer::singleShot(2000, [&]() {
onErrorTriggered();
});
}
virtual ~DataReadCtrl()
{
qDebug() << _name + ".~DataReadCtrl()";
}
void onErrorTriggered()
{
_pDlgErrorMsg->show();
}
};
class MainWindow: public QMainWindow {
private:
const QString _name;
DataReadCtrl *_pCtrlReadData;
public:
MainWindow(const char *name):
QMainWindow(),
_name(name),
_pCtrlReadData(nullptr)
{
_pCtrlReadData
= new DataReadCtrl(_name + "._pCtrlReadData", this);
//Close after 5 seconds.
QTimer::singleShot(5000, [&]() {
qDebug() << _name + ".close()";
close();
});
}
virtual ~MainWindow()
{
qDebug() << _name + ".~MainWindow()";
}
};
int main(int argc, char **argv)
{
qDebug() << "Qt Version:" << QT_VERSION_STR;
QApplication app(argc, argv);
// setup GUI
MainWindow winMain("winMain");
winMain.show();
// runtime loop
return app.exec();
}
and a minimal Qt project file testQParentship.pro:
SOURCES = testQParentship.cc
QT += widgets
Compiled and tested in cygwin64 on Windows 10:
$ qmake-qt5 testQParentship.pro
$ make && ./testQParentship
g++ -c -fno-keep-inline-dllexport -D_GNU_SOURCE -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtWidgets -isystem /usr/include/qt5/QtGui -isystem /usr/include/qt5/QtCore -I. -I/usr/lib/qt5/mkspecs/cygwin-g++ -o testQParentship.o testQParentship.cc
g++ -o testQParentship.exe testQParentship.o -lQt5Widgets -lQt5Gui -lQt5Core -lGL -lpthread
Qt Version: 5.9.4
After the QTimer::singleshot() in MainWindow is due, the main window is closed. The output of diagnostics illustrates that the object tree is destructed properly (instead of "thrown" away when OS releases process memory).
"winMain.close()"
"winMain.~MainWindow()"
"winMain._pCtrlReadData.~DataReadCtrl()"
"winMain._pCtrlReadData._pDlgErrorMsg.~ErrorMsgDlg()"
"HBoxLayout.~HBoxLayout()"
"Label.~Label()"
Minimal app:
TestProject.pro:
QT += core gui widgets
CONFIG += C++11
QMAKE_CXXFLAGS_RELEASE -= -O
QMAKE_CXXFLAGS_RELEASE -= -O0
QMAKE_CXXFLAGS_RELEASE -= -O1
QMAKE_CXXFLAGS_RELEASE -= -O2
QMAKE_CXXFLAGS_RELEASE *= -O3
QMAKE_CXXFLAGS_RELEASE -= -Os
QMAKE_CXXFLAGS_RELEASE -= -Ofast
TARGET = TestProject
TEMPLATE = app
SOURCES += main.cpp\
mainwindow.cpp
HEADERS += mainwindow.h
main.cpp:
#include <mainwindow.h>
#include <QApplication>
int main(int argc, char* argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec();
}
mainwindow.h:
#ifndef MAINWINDOW_H
#define MAINWINDOW_H
#include <QObject>
#include <QStack>
class Other : public QObject
{
Q_OBJECT
public:
explicit Other(QObject* parent = 0);
virtual ~Other();
void test();
private:
QStack<int> myStack;
};
//--------------------------------------------------------------------------------------------------
#include <QMainWindow>
#include <QPushButton>
#include <QTextEdit>
class MainWindow : public QMainWindow
{
Q_OBJECT
public:
explicit MainWindow(QWidget* parent = 0);
virtual ~MainWindow();
};
#endif // MAINWINDOW_H
mainwindow.cpp:
#include "mainwindow.h"
Other::Other(QObject* parent) :
QObject(parent)
{}
Other::~Other()
{}
void Other::test() //warning on this line
{
myStack.pop(); //but not when this line is commented
}
//--------------------------------------------------------------------------------------------------
MainWindow::MainWindow(QWidget* parent) :
QMainWindow(parent)
{
(new Other(this))->test();
}
MainWindow::~MainWindow()
{}
Compiling with g++ -O3 -Wall gives this warning:
...TestProject/mainwindow.cpp:10: warning: assuming signed overflow does not occur when assuming that (X - c) <= X is always true [-Wstrict-overflow]
void Other::test() //warning on this line
^
Compiling with g++ -O2 -Wall does not.
This question makes sense, as it's for a conditional, but I'm not getting it on a conditional. I'm getting it on a function itself.
I'd like to use the more aggressive optimization, but still compile cleanly if I can. Is there something weird going on with QStack?
Update:
I still don't know what the warning is supposed to mean in this context, but I found a way to get rid of it.
I copied the code from qstack.h and pasted it into my own function, then called it instead of the built-in QStack::pop():
void Other::pop() //warning on this line
{
Q_ASSERT(!myStack.isEmpty());
int t = myStack.data()[myStack.size() - 1];
myStack.resize(myStack.size() - 1);
return t;
}
Still have the warning, but it's moved to the custom pop() function.
Then I played with it a bit and found that caching myStack.size() - 1 for the resize operation kills the warning, but only if it's done before extracting the data():
void Other::pop() //no warning
{
Q_ASSERT(!myStack.isEmpty());
int size = myStack.size() - 1;
int t = myStack.data()[myStack.size() - 1];
myStack.resize(size);
return t;
}
Using the cached value for both operations is also warning-free.
So that's one of probably several ways to get rid of it, but does anyone know why it occurs here?
The warning is telling you that the compiler is not checking if the result of the substraction is negative or not.
Why this matters in this particular line?
myStack.data()[myStack.size() - 1];
Because you are indexing an array (actually using a pointer variable, coming from the data() function, which returns a T*) using the result of a substraction operation, which may result in a negative number, which is, typically, something you don't want.
When you take that substraction and move it to a new variable, then the compiler sees that you are indexing an array directly with an int variable, and not the result of a substraction, so it does not warn anymore if the passed variable is negative or not.
About your comment, you are using the cached data for the resize function. I am not really sure about why this happens, but I guess it may be related that, in -O3 the compiler enables the following flag:
-finline-functions
See http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html for more details.
This flag enables all the inlining functions optimisation. Since you are using all templated classes, the compiler may be inlining all the involved functions, caching some results and somewhere is optimising the signed overflow. Probably in the if sentence in the resizefunction:
template <typename T>
void QVector<T>::resize(int asize)
{
int newAlloc;
const int oldAlloc = int(d->alloc);
QArrayData::AllocationOptions opt;
//Here, asize will be replaced with d->size - 1 after all the inlining.
//So the compiler is assuming that d->size - 1 will not overflow,
// because of undefined behaviour,
// instead of thinking that it may wrap.
if (asize > oldAlloc) {
newAlloc = asize;
opt = QArrayData::Grow;
} else {
newAlloc = oldAlloc;
}
reallocData(asize, newAlloc, opt);
}
But this is just a guess.
I am brand new to programming with Qt. I'm trying to do a simple subtraction of some values fed from an epicsQt widget called QELabel, which simply reads the value of an EPICS channel. I want to subtract values from two QELabels and print it to another QELabel. But, I'm getting 'undefined reference to' errors for these ->
MainWindow::on_qeLabel_dbValueChanged(QString const&) MainWindow::on_ShutterOpen_dbValueChanged(QString const&)
Here is the bit of mainwindow.cpp (I followed the example from this youtube video, especially after about the 15 minute mark)
void MainWindow::on_TopShutter_dbValueChanged(const QString &out)
{
double top,bottom,open;
top=ui->TopShutter->text().toDouble();
bottom=ui->BottomShutter->text().toDouble();
open=top-bottom
ui->ShutterOpen->setText(Qstring::number(open));
}
I'm using QTCreator, so I don't have the usual errors that I've been seeing in other forums. I have the slot declared in the header file, and MainWindow set as a Q_Object (this is the whole mainwindow.h file):
#ifndef MAINWINDOW_H
#define MAINWINDOW_H
#include <QMainWindow>
namespace Ui {
class MainWindow;
}
class MainWindow : public QMainWindow
{
Q_OBJECT
public:
explicit MainWindow(QWidget *parent = 0);
~MainWindow();
private slots:
void on_qelabel_dbValueChanged(const QString &out);
void on_ShutterOpen_dbValueChanged(const QString &out);
void on_TopShutter_dbValueChanged(const QString &out);
private:
Ui::MainWindow *ui;
};
#endif //MAINWINDOW_H
Because they are short, and for completeness, here is the main.cpp, and then the .pro
#include "mainwindow.h"
#include <QApplication>
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec();
}
And the FirstWeatherAlarm.pro:
#-------------------------------------------------
QT += core gui xml
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TARGET = FirstWeatherAlarm
TEMPLATE = app
SOURCES += main.cpp\
mainwindow.cpp
LIBS += -L/usr/lib64/qt5/plugins/designer -lQEPlugin
INCLUDEPATH += /home/jchavez/epicsqt/3.1.0/framework/include
HEADERS += mainwindow.h
FORMS += mainwindow.ui
Have I got everything declared right at the start of all the files? What is missing so that my slots are not right? I created the slot in the gui, using the "right-click" on my QELabel, and selecting "Go to Slot", so I should think all the formatting would be correct. As I've been editing, I've also run qmake and make clean which are other answers I've seen on forums. But nothing is working.
The problem is with two slots:
MainWindow::on_qeLabel_dbValueChanged(QString const&)
MainWindow::on_ShutterOpen_dbValueChanged(QString const&)
They are declared in MainWindow.h file and used somewhere in your project (otherwise you won't get an error).
But they are not implemented in mainwindow.cpp. You should add implementation to this file and the error will go away.
You have implementation for
void MainWindow::on_TopShutter_dbValueChanged(const QString &out)
in mainwindow.cpp, you can add implementation for two more slots. Think about slot as a function. And read more about signals/slots.