If you want only a single instance of your application running you should take a look at QtSingleApplication

When I researched having both a GUI and command line application on Windows I stumbled upon how Microsoft does it itself with devenv. They provide a .exe and a .com at the same time. If you call your software myapp then you should compile the GUI application to myapp.exe and the command line application to myapp.com. When typing myapp on the command line it will launch the .com version. What we did in addition is to have the two application call each other depending on the command line parameters. This is a better user experience than attaching a console. With qmake use an additional CONFIG to select between GUI and console (e.g. CONFIG+=console when calling qmake). In your main() have #ifdefs to switch between command line and GUI during compilation.

@JonB Yeah, I was thinking of doing this because there are signals for both applicationDisplayNameChanged() & applicationNameChanged() this can provide me with an application-wide signal to change users. My application has different modules which are completely independent of each other (I have to develop a lot of custom applications where not each application has to have all modules, and so independent modules are the best idea), the common things among these modules are stored directly inside a namespace (every module is also inside this namespace) and so I need an application-level signal to propagate common settings for my application, i.e. current user master key, current font and current palette. For font and palette, QApplication provides the respective ..changed() signal but there is no way for me to add an application-level signal for the master user key without creating a singleton, which I very much want to avoid, that's why I was thinking of using applicationDisplayName as master user key :) @JonB @SGaist Thanks for the insight, I will figure out a different way then. P.S. It would be nice to have a void QCoreApplication::broadcast(const QString& string) signal, the string could be modified in different ways to provide different values to the broadcast :)

@JonB said in What should I do to solve this error in Qvector?: if you are saying that a properly-compiled 64-bit now bombs out in the same way as 32-bit at what we think is only half a gig of so of memory on a machine with plenty of free RAM, earlier I was doing mistake while creating 64 bit application version. I am using visual studio while creating 64 bit application I was just copied all setting of 32 bit application, So That in Solution platform it was showing x64 but it was creating 32 bit executable file. I created 64 bit application version, which is save very large amount of data in RAM.

For non Qt code I am trying to call Qcoreapplication with help of another thread. Here the code: ApplicationThread.h #pragma once #include <qthread.h> #include "squidstat_dll_global.h" #include <iostream> class SQUIDSTAT_DLLSHARED_EXPORT ApplicationThread:public QThread { void run(); }; class SQUIDSTAT_DLLSHARED_EXPORT ApplicationStarter : public QObject { Q_OBJECT public: ApplicationStarter(); ~ApplicationStarter(); public slots: void onStarted(); }; ApplicationThread.cpp #include "ApplicationThread.h" #include "MainWindow.h" #include "qcoreapplication.h" namespace ToolThreadGlobal { static int argc = 1; static char* argv[] = { QString("SquidState.exe").toLocal8Bit().data(),NULL}; static QCoreApplication *coreApp = nullptr; static ApplicationThread *toolThread = nullptr; }; void ApplicationThread::run() { if (ToolThreadGlobal::coreApp){ std::cout << "\nApplicationThread: thread run method is call"; ToolThreadGlobal::coreApp->exec(); } } ApplicationStarter::ApplicationStarter() { if (ToolThreadGlobal::toolThread == nullptr) { std::cout << "\nApplicationstarter Constructor call"; ToolThreadGlobal::toolThread = new ApplicationThread(); connect(ToolThreadGlobal::toolThread, &ApplicationThread::started, this, &ApplicationStarter::onStarted, Qt::DirectConnection); ToolThreadGlobal::toolThread->start(); } } ApplicationStarter::~ApplicationStarter() { std::cout << "\nApplicationStarter:: destructor is called"; // Ensure that the thread and the QCoreApplication are cleanly shut down: ToolThreadGlobal::toolThread->quit(); ToolThreadGlobal::coreApp->quit(); ToolThreadGlobal::coreApp->deleteLater(); ToolThreadGlobal::coreApp = nullptr; ToolThreadGlobal::toolThread->terminate(); ToolThreadGlobal::toolThread->wait(); ToolThreadGlobal::toolThread->deleteLater(); ToolThreadGlobal::toolThread = nullptr; } void ApplicationStarter::onStarted() { std::cout << "\nApplicationStarter::signal received"; if (QCoreApplication::instance() == NULL) { std::cout << "\nApplicationStarter::call QcoreApplication"; ToolThreadGlobal::coreApp = new QCoreApplication(ToolThreadGlobal::argc, ToolThreadGlobal::argv); std::cout << "\nApplicationStarter::call worker"; MainWindow w; std::cout << "\nApplicationStarter::call before exe"; } } SquidState.h #pragma once #include "squidstat_dll_global.h" #include "ApplicationThread.h" #ifndef _SQUIDSTAT_H_ #define _SQUIDSTAT_H_ namespace AISquid { class SQUIDSTAT_DLLSHARED_EXPORT SquidStat { public: SquidStat(); ~SquidStat(); void startAPP(); void closeAPP(); }; } #endif // !_SQUIDSTAT_H_ SquidState.cpp #include <stdlib.h> #include "SquidStat.h" #include "ApplicationThread.h" AISquid::SquidStat::SquidStat() { std::cout << "\nSquidStat: SquidStat class object is created"; }; AISquid::SquidStat::~SquidStat() { std::cout << "\nSquidStat: SquidStat class object is destriod "; }; void AISquid::SquidStat::startAPP() { }; void AISquid::SquidStat::closeAPP() { }; Testing My dll with help of below code. tester.cpp #include "SquidStat.h" #include "ApplicationThread.h" void main(int argc, char *argv[]) { ApplicationStarter start; AISquid::SquidStat obj; obj.startAPP(); return; } OutPut of Tester: [image: 193cf9f3-9b6c-4f2e-a841-da35fba38003.png] What is wrong am I doing here? I am receiving call for slot onStarted(); once ApplicationStarter start; object is destroy. Any suggestion would be more appreciable.

Hi, Absolutely, in the same creator session I can toggle between toolchains, Desktop is fine, but Raspberry Pi is giving the aforementioned problem. This is my setup. Build settings: [image: c290c213-7a38-4add-9bdc-6e52d0fd6a79.png] [image: f133a4d7-5040-4b61-be94-1cc1f32f3c70.png] PATH: /home/ubuntuvm/raspi/qt5/bin:/home/ubuntuvm/raspi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/arm-linux-gnueabihf/bin Kit: [image: 2e7d508f-5969-414d-ab2d-c6cffe6d3002.png] Device: [image: 84de4e08-e542-460d-ba9c-262d5a4ff498.png] Qt Versions: [image: d2ad4810-0593-4b3c-9a85-519dba5d8e27.png] Compilers: [image: a0a3ee52-708b-42ff-a218-6e53a8446256.png] [image: d5f2ef63-a479-4f9f-a54c-42493222cca8.png] Compiler Path (C & C++): /home/ubuntuvm/raspi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/arm-linux-gnueabihf/bin/gcc Debuggers: [image: f6dbd68c-f15f-44f8-b54c-069630d35c9e.png] Qbs: [image: cafc88c2-128d-4242-af7b-2f5113e6fa6b.png]

Hi, Why do you have to remove these events ?

@ThirdStrand said in Force system QT libraries to use openssl libraries shipped with the application: @JKSH One would do this to ensure that the libraries used are the proper libraries which are expected in the program. In much the same way as we deploy the appropriate versions of Qt libraries, why not use a KNOWN library when deploying the libssl and libcrypto libraries? If you want to use known libraries in your app without the possibility of user interference you should probably use static libraries and not dynamic. Because even if the other libraries are not in the system path there is always at least one user who might want to exchange your library with another one - perhaps optimized for his computer ;) Had this a couple of times on windows with DLLs and a lot with java apps where users just replaced „outdated“ libraries. This has become the bane of my existence, and I am here in search of WHY it will work when it is in QtCreator and NOT work when deployed with the EXACT same loaded library files. I didn‘t see your used OS but I could imagine that Qt Creator uses LD_PRELOAD mechanism to ensure that the specific libs are loaded first. This at least should work an Linux, I don‘t know any trick for that on windows. AFAIK macOS offers a similar mechanism to Linux. By way of venting, this old question gets some new life. I have seen many "answers" which usually consist of "The user should install....", which anyone who has ever actually deployed retail software knows is an absolute NIGHTMARE. Witness ProtonVPN! This commercial application is deployed with a specific (v1.1.1j) set of OpenSSL libraries. Why? Because it is developed with that version and is tested with that version. Why opt to allow the end user to change the libraries and break your application at will? That's just self-defeating. Still this doesn‘t prevent the user from changing the libs themselves. And given the fact that the build environment doesn‘t often change it might very well be that they will be shipping an „outdated“ version - because the app was developed with it - and tested. When I worked on Air Traffic Control Software we almost never updated our libraries - because they were „tested“. As I said earlier: If you want to prevent user modification use static linking. This way the size of your deployed app will also shrink. But be sure to check possible licensing restrictions.

I didn't notice it ... silly mistake. Many thanks for the hint and best regards, Marek

Also, what backtrace to you get from the debugger ?

@Stoyan error: passing 'const Operation' as 'this' argument of 'int Operation::setAttribute(QString, QString)' discards qualifiers [-fpermissive] operations.at(i).setAttribute(Aname,Value); Не мога да разбера защо се получава това съобщение в Task класа, опитвайки се да извикам метода SetAttribute за операция във вектора. Const Operation не знам откъде идва вътре в тази функция конкретно, след като подавам само id-то на операцията. Подобна е грешката и при Task сетване на атрибут: scheduledtopservice\scheduler.cpp:31: error: passing 'const Task' as 'this' argument of 'int Task::setAttribute(QString, QString)' discards qualifiers [-fpermissive] tasks.at(k).setAttribute("state","running"); ПП: Успях да го реша проблема. Разбрах че .at() връща const обект, затова използвах [i] за индекс. task.cpp:17: warning: base class 'class BaseObject' should be explicitly initialized in the copy constructor [-Wextra] Task::Task(const Task &obj) Това как мога да го оправя, четох че създавало още 1 копие на BaseObject така. Но не е като експлицитния конструктор сякаш : BaseObject ( const BaseObject &obj) ако долепя до Copy конструктора на Task. Не съм сигурен, но май просто като сложих : BaseObject() и се изчисти предупреждението. Така ли трябвa да бъде ?

I wanted to copy the contents of qquickwindowmodule.cpp (located in /home/andy/Qt/5.3/Src/qtdeclarative/src/quick/items/qquickwindowmodule.cpp) which contains the error message. I can't figure out why is the error message popping up when I run the application. .... /**************************************************** ** $QT_END_LICENSE$ ** ****************************************************************************/ #include "qquickwindowmodule_p.h" #include "qquickscreen_p.h" #include "qquickview_p.h" #include <QtQuick/QQuickWindow> #include <QtCore/QCoreApplication> #include <QtQml/QQmlEngine> #include <private/qguiapplication_p.h> #include <private/qqmlengine_p.h> #include <qpa/qplatformintegration.h> QT_BEGIN_NAMESPACE class QQuickWindowQmlImpl : public QQuickWindow, public QQmlParserStatus { Q_INTERFACES(QQmlParserStatus) Q_OBJECT Q_PROPERTY(bool visible READ isVisible WRITE setVisible NOTIFY visibleChanged) Q_PROPERTY(Visibility visibility READ visibility WRITE setVisibility NOTIFY visibilityChanged) public: QQuickWindowQmlImpl(QWindow *parent = 0) : QQuickWindow(parent) , m_complete(false) , m_visible(isVisible()) , m_visibility(AutomaticVisibility) { connect(this, &QWindow::visibleChanged, this, &QQuickWindowQmlImpl::visibleChanged); connect(this, &QWindow::visibilityChanged, this, &QQuickWindowQmlImpl::visibilityChanged); } void setVisible(bool visible) { if (!m_complete) m_visible = visible; else if (!transientParent() || transientParent()->isVisible()) QQuickWindow::setVisible(visible); } void setVisibility(Visibility visibility) { if (!m_complete) m_visibility = visibility; else QQuickWindow::setVisibility(visibility); } Q_SIGNALS: void visibleChanged(bool arg); void visibilityChanged(QWindow::Visibility visibility); protected: void classBegin() { QQmlEngine* e = qmlEngine(this); //Give QQuickView behavior when created from QML with QQmlApplicationEngine if (QCoreApplication::instance()->property("__qml_using_qqmlapplicationengine") == QVariant(true)) { if (e && !e->incubationController()) e->setIncubationController(incubationController()); } Q_ASSERT(e); { QV4::ExecutionEngine *v4 = QQmlEnginePrivate::getV4Engine(e); QV4::Scope scope(v4); QV4::ScopedObject v(scope, new (v4->memoryManager) QQuickRootItemMarker(e, this)); rootItemMarker = v; } } void componentComplete() { m_complete = true; if (transientParent() && !transientParent()->isVisible()) { connect(transientParent(), &QQuickWindow::visibleChanged, this, &QQuickWindowQmlImpl::setWindowVisibility, Qt::QueuedConnection); } else { setWindowVisibility(); } } private Q_SLOTS: void setWindowVisibility() { if (transientParent() && !transientParent()->isVisible()) return; if (sender()) { disconnect(transientParent(), &QWindow::visibleChanged, this, &QQuickWindowQmlImpl::setWindowVisibility); } // We have deferred window creation until we have the full picture of what // the user wanted in terms of window state, geometry, visibility, etc. if ((m_visibility == Hidden && m_visible) || (m_visibility > AutomaticVisibility && !m_visible)) { QQmlData *data = QQmlData::get(this); Q_ASSERT(data && data->context); QQmlError error; error.setObject(this); const QQmlContextData* urlContext = data->context; while (urlContext && urlContext->url.isEmpty()) urlContext = urlContext->parent; error.setUrl(urlContext ? urlContext->url : QUrl()); QString objectId = data->context->findObjectId(this); if (!objectId.isEmpty()) error.setDescription(QCoreApplication::translate("QQuickWindowQmlImpl", "Conflicting properties 'visible' and 'visibility' for Window '%1'").arg(objectId)); else error.setDescription(QCoreApplication::translate("QQuickWindowQmlImpl", "Conflicting properties 'visible' and 'visibility'")); QQmlEnginePrivate::get(data->context->engine)->warning(error); } if (m_visibility == AutomaticVisibility) { setWindowState(QGuiApplicationPrivate::platformIntegration()->defaultWindowState(flags())); setVisible(m_visible); } else { setVisibility(m_visibility); } } private: bool m_complete; bool m_visible; Visibility m_visibility; QV4::PersistentValue rootItemMarker; }; void QQuickWindowModule::defineModule() { const char uri[] = "QtQuick.Window"; qmlRegisterType<QQuickWindow>(uri, 2, 0, "Window"); qmlRegisterRevision<QWindow,1>(uri, 2, 1); qmlRegisterRevision<QWindow,2>(uri, 2, 2); qmlRegisterRevision<QQuickWindow,1>(uri, 2, 1);//Type moved to a subclass, but also has new members qmlRegisterRevision<QQuickWindow,2>(uri, 2, 2); qmlRegisterType<QQuickWindowQmlImpl>(uri, 2, 1, "Window"); qmlRegisterUncreatableType<QQuickScreen>(uri, 2, 0, "Screen", QStringLiteral("Screen can only be used via the attached property.")); } #include "qquickwindowmodule.moc" QT_END_NAMESPACE %%%%%%%%%%%%%%%%%55

You need to show some code. Was QCoreApplication constructor called? You might get such effect if it was not or other QObjects were instantiated before QCoreApplication was constructed.

@ChrisW67 Thank you for you help. Probably the thing is, QSerialPort has a problem to work in a new thread. I can handle the other QObject in a new thread very well, and the exception only happens when the Object contains QSerialPort. Also, in my last post, I actually never user QList, although Qt tells me something wrong with QList. I have given up on working serialThread. QSerialPort does work good in the main thread.

I asked the same quesion in stackoverflow. I gues I found out why I am having this problem. http://stackoverflow.com/questions/30686488/qapplication-is-lazy-or-making-other-threads-lazy-in-the-app

OK guys, I was able to solve the problem. The Fedora people changed a configuration file, so that qDebug output wasn't shown to the user anymore, until the user changed the settings like described here: https://bugzilla.redhat.com/show_bug.cgi?id=1227295

@SGaist Fixed it ;)

Hi, Remove CONFIG -= qt Currently you are trying to use Qt in a non Qt project

@shavera I understand what do you mean but honestly I don't think such kind of feature could be useful; you need anyway to do something manually to run in GUI or non-GUI mode.