i'm new to QT API and the QT IDE, i was following this tutorial: http://developer.nokia.com/community/wiki/Creating_an_HTTP_network_request_in_Qt, but when i try to compile i get this errors, the usually cause of the problem is: the compiler couldn't
find the .cpp/.lib archive where the code for the methods are, but in this case, the api would be already configured, i can't understand why i'm getting this error, and also i couldn't find the project properties, here is my test code:
#include <QMainWindow>
#include <QUrl>
#include <QtNetwork/QNetworkAccessManager>
#include <QtNetwork/QNetworkRequest>
#include <QtNetwork/QNetworkReply>
this is the headers included on the mainwindow.hpp file, now the mainwindow.cpp:
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
QNetworkAccessManager* nam;
nam = new QNetworkAccessManager(this);
QObject::connect(nam, SIGNAL(finished(QNetworkReply*)),
this, SLOT(finishedSlot(QNetworkReply*)));
QUrl url("http://www.forum.nokia.wiki");
QNetworkReply* reply = nam->get(QNetworkRequest(url));
}
finishedSlot method:
void MainWindow::finishedSlot(QNetworkReply* reply)
{
//nothing
}
so this is the code, if someone can help i'll thank you :)
Do you have QT += network in the .pro project file?
Edit:
fixed typo, was config instead of QT
I solved this for CMake by appending following lines to the CMakeLists.txt:
find_package(Qt5Network REQUIRED)
target_link_libraries(${PROJECT_NAME} Qt5::Network)
If you are using Cmake just add ${QT_QTNETWORK_LIBRARY} to TARGET_LINK_LIBRARIES.
Related
I need to transition from qmake to CMake for a large C++ project, but while working through a toy example I encountered some behavior that I don't understand. The example code features a single header file, and when that header file is moved into a subdirectory, I get a missing vtable error for the MainWindow class.
CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
project(HelloCMake)
set(CMAKE_INCLUDE_CURRENT_DIR ON)
set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTOUIC ON)
find_package(Qt5Widgets CONFIG REQUIRED)
include_directories("include")
set(INCLUDES include/mainwindow.h)
set(SOURCES
main.cpp
mainwindow.cpp
mainwindow.ui
)
add_executable(hello-cmake ${SOURCES}) # error
# add_executable(hello-cmake ${SOURCES} ${INCLUDES}) # no error
target_link_libraries(hello-cmake Qt5::Widgets)
include/mainwindow.h (boilerplate)
#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:
Ui::MainWindow *ui;
};
#endif // MAINWINDOW_H
mainwindow.cpp (boilerplate)
#include "mainwindow.h"
#include "ui_mainwindow.h"
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
}
MainWindow::~MainWindow() {
delete ui;
}
main.cpp (boilerplate)
#include "mainwindow.h"
#include <QApplication>
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec();
}
Here's what I see when I run make (after first running cmake .):
[ 20%] Automatic MOC and UIC for target hello-cmake
[ 20%] Built target hello-cmake_autogen
[ 40%] Linking CXX executable hello-cmake
Undefined symbols for architecture x86_64:
"vtable for MainWindow", referenced from:
MainWindow::MainWindow(QWidget*) in mainwindow.cpp.o
MainWindow::~MainWindow() in mainwindow.cpp.o
NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [hello-cmake] Error 1
make[1]: *** [CMakeFiles/hello-cmake.dir/all] Error 2
make: *** [all] Error 2
If I add the header to the target by swapping the second add_executable command for the first one in CMakeLists.txt, the error goes away. I can also make the error go away by moving the header into the base directory with the .cpp files. However, I'd like to know what's actually going on here. I understand the general value of including the header files in the target, but why is a missing vtable error generated when I don't do this? Unless I grossly misunderstand, all the contents of mainwindow.h should be available while mainwindow.cpp is being compiled by virtue of the #include, whether or not the header is part of the add_executable statement.
--
EDIT
Here are the contents of ui_mainwindow.h, in case they're somehow relevant.
/********************************************************************************
** Form generated from reading UI file 'mainwindow.ui'
**
** Created by: Qt User Interface Compiler version 5.10.1
**
** WARNING! All changes made in this file will be lost when recompiling UI file!
********************************************************************************/
#ifndef UI_MAINWINDOW_H
#define UI_MAINWINDOW_H
#include <QtCore/QVariant>
#include <QtWidgets/QAction>
#include <QtWidgets/QApplication>
#include <QtWidgets/QButtonGroup>
#include <QtWidgets/QHeaderView>
#include <QtWidgets/QMainWindow>
#include <QtWidgets/QMenuBar>
#include <QtWidgets/QPushButton>
#include <QtWidgets/QStatusBar>
#include <QtWidgets/QToolBar>
#include <QtWidgets/QWidget>
QT_BEGIN_NAMESPACE
class Ui_MainWindow
{
public:
QWidget *centralWidget;
QPushButton *pushButton;
QMenuBar *menuBar;
QToolBar *mainToolBar;
QStatusBar *statusBar;
void setupUi(QMainWindow *MainWindow)
{
if (MainWindow->objectName().isEmpty())
MainWindow->setObjectName(QStringLiteral("MainWindow"));
MainWindow->resize(393, 307);
centralWidget = new QWidget(MainWindow);
centralWidget->setObjectName(QStringLiteral("centralWidget"));
pushButton = new QPushButton(centralWidget);
pushButton->setObjectName(QStringLiteral("pushButton"));
pushButton->setGeometry(QRect(10, 10, 113, 32));
MainWindow->setCentralWidget(centralWidget);
menuBar = new QMenuBar(MainWindow);
menuBar->setObjectName(QStringLiteral("menuBar"));
menuBar->setGeometry(QRect(0, 0, 393, 22));
MainWindow->setMenuBar(menuBar);
mainToolBar = new QToolBar(MainWindow);
mainToolBar->setObjectName(QStringLiteral("mainToolBar"));
MainWindow->addToolBar(Qt::TopToolBarArea, mainToolBar);
statusBar = new QStatusBar(MainWindow);
statusBar->setObjectName(QStringLiteral("statusBar"));
MainWindow->setStatusBar(statusBar);
retranslateUi(MainWindow);
QObject::connect(pushButton, SIGNAL(released()), pushButton, SLOT(hide()));
QMetaObject::connectSlotsByName(MainWindow);
} // setupUi
void retranslateUi(QMainWindow *MainWindow)
{
MainWindow->setWindowTitle(QApplication::translate("MainWindow", "MainWindow", nullptr));
pushButton->setText(QApplication::translate("MainWindow", "Do not press", nullptr));
} // retranslateUi
};
namespace Ui {
class MainWindow: public Ui_MainWindow {};
} // namespace Ui
QT_END_NAMESPACE
#endif // UI_MAINWINDOW_H
I was able to migrate my real project to CMake with exactly one hiccup: the linker wasn't happy with any of the signal functions in my QObject-derived classes. (For those not familiar with Qt, a meta-object compiler, moc, magically converts certain empty functions marked as signals in a header file into real functions that the C++ compiler can use.) My conclusion is that both problems resulted from CMake not seeing the header files for a QObject-derived class, and so they were not sent to the moc in spite of the CMAKE_AUTOMOC setting.
The upshot is, if moc (or uic or rcc) needs to compile a file, then CMake has to know it exists before building any dependent targets. The crude solution I used for my project was to grep Q_OBJECT in the directory with all my header files, and copy/paste this list into a long set command in CMakeLists.txt
set(MOC_SOURCES
include/applewidget.h
include/borangewidget.h
...
)
and then add ${MOC_SOURCES} to my add_executable line. There may be a more sophisticated solution that involves building these objects separately, but my use of CMake has not yet reached that level of sophistication.
Meta object compiler (moc) generates moc_*.cpp files from headers. So the build system needs to know which headers to feed it. Similar to C++ compiler that needs to know which files to process. So when working with CMake and Qt you need to consider the header files as source files. CMake is smart enough to not ask C++ compiler to compile them so there's no harm in adding them for other libraries too.
Unfortunately neither Qt-CMake nor CMake-Qt documentation state this explicitly but you should always add headers to the list of sources in add_executable/add_library for CMAKE_AUTOMOC to work.
Another important thing is the minimal required version of CMake. CMake 2.6 does not support Qt5. Neither does CMake 2.8. The official Qt documentation claims the minimal CMake version to be 3.1.0. However CMake 3.0 already has Qt5 support. Still those version are way too old, slow, and buggy so consider updating the requirement. I'd recommend 3.11 or latest stable.
I am programming with Qt Creator on a Mac (High Sierra 10.13.4). My projects seem to spontaneously break after a few days of work.
The linker error given is: "symbol(s) not found for architecture x86_64".
There is nothing wrong with the code - I open, run, close, and reopen projects and they are suddenly broken. I have also tested this with Qt's provided examples, to the same effect. I can copy-paste the code to a new project and compile it with no problem, but it will eventually do the same thing again.
I have attempted deleting the whole debug output folder of the project to give it a fresh start, but it did not make a difference. Same error.
Has anyone had this issue with QtCreator before? Is there a solution?
I have looked up a lot of very similar questions on here, but they all seem to be errors with the code. Just in case it's the same with me, this is all my code:
//main.cpp
#include "display.h"
#include "frame.h"
#include <QApplication>
int main(int argc, char * argv[])
{
QApplication a(argc, argv);
Display w;
w.show();
return a.exec();
}
Display.h & Frame.h are auto-generated.
//display.cpp
#include "display.h"
#include "ui_display.h"
#include "frame.h"
Display::Display(QWidget *parent) : QMainWindow(parent), ui(new Ui::Display)
{
ui->setupUi(this);
QWidget * f = new Frame(this);
setCentralWidget(f);
}
Display::~Display()
{
delete ui;
}
Frame.cpp last:
#include "frame.h"
#include "ui_frame.h"
Frame::Frame(QWidget *parent) : QFrame(parent), ui(new Ui::Frame)
{
ui->setupUi(this);
}
Frame::~Frame()
{
delete ui;
}
It is not that the linker error is as given. There's way more to it, and you're not including the meat of the message that actually carries meaningful information allowing to debug this issue. Your problem is possibly with the project becoming internally binary-incompatible, and qmake build system not catching onto it. The issue has nothing to do with Qt Creator. The build is done by qmake and make. You'll see those problems if you build from the command line - which I highly advise you to do.
Assuming the sources are in /Users/mycaptain/src/myproject, and that you're using Qt from macports, proceed as follows in terminal:
$ mkdir ~/src/build-myproject
$ cd ~/src/build-myproject
$ /opt/local/libexec/qt5/bin/qmake ../myproject
$ make
My problem is that I want to create a Qt3DWindow which I embed in my program using QWidget::createWindowContainer.
I now upgraded to Ubuntu 17.10 but as soon as I add the container widget my CPU load goes up to 100% constant.
This worked already under Ubuntu 16.04 and Windows.
Does anyone know this issue or maybe even have a solution? Or do I have to downgrade to Ubuntu 16.04 again?
A minimally working example is creating a new project in Qt Creator and selecting Qt Widgets Application and, finally, replacing the code in the mainwindow.cpp with the following:
#include "mainwindow.h"
#include "ui_mainwindow.h"
#include <QHBoxLayout>
#include <Qt3DExtras/Qt3DWindow>
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
ui->centralWidget->setLayout(new QHBoxLayout());
Qt3DExtras::Qt3DWindow *window = new Qt3DExtras::Qt3DWindow;
QWidget *widget = QWidget::createWindowContainer(window);
ui->centralWidget->layout()->addWidget(widget);
}
MainWindow::~MainWindow()
{
delete ui;
}
Now add 3dextras to QT += core gui in the .pro file of your project and run it. This produces the high CPU load on my machine.
i am struggling a bit with my project and the thing that is making me really annoyed right now is QWebview. So i tried to create a new project. In this new project all have is blank Qt widget application with one webview added from Qt Designer.
The problem is as the header says, my webview is not willing to load any webpage
i have tried all sorts of possibilities for webpage:
http://google.com
https://google.com
http://www.google.com
https://www.google.com
www.google.com
None of which works, all just give blank page as if about:blank
this is the code
#include "mainwindow.h"
#include "ui_mainwindow.h"
#include <QtWebKitWidgets/QWebView>
#include <QUrl>
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
ui->webView->load(QUrl("http://www.google.com"));
}
MainWindow::~MainWindow()
{
delete ui;
}
I didn't forgot to put QT+= webkitwidgets in pro, also included all libs.
Any suggestions?
Oukey i resolved my problem.
Still dont know what was wrong with QWebView instead i used QWebEngineView and that worked like a charm.
Maybe since its chromium that is the reason.
Thanks all for their inputs.
#include "mainwindow.h"
#include "ui_mainwindow.h"
#include "dialog.h"
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
setCentralWidget(ui->plainTextEdit);
}
MainWindow::~MainWindow()
{
delete ui;
}
void MainWindow::on_actionDoit_triggered()
{
Dialog D;
D.setModal(true);
D.exec();
}
This small piece of code is giving me linker errors LNK2019 and LNK1120
If I remove the three lines in function void MainWindow::on_actionDoit_triggered(), it works. The tutorial I am following didn't warn of linker problems
Apparently, you got it working without changing the code just by re-running qmake explicitly.
The reason is most likely the fact that you modified your qmake project file(s), and QtCreator has issues with knowing when to re-run qmake properly.
There is a long-standing bug about it:
Creator should know when to rerun qmake