So I have a qt app running on Linux. When the app is initially launched, QSettings is constantly writing to the settings.conf file even though no changes were made to QSettings. Once a user changes any setting, it stops writing and acts like normal and only writes during changes. Our hardware does not have a power button and so never shuts off and is constantly plugged in so having QSettings constantly writing to the .conf file on start up is a problem.
I looked for timers to make sure no timer was prompting to write and there are none. Tried settings.sync(). I even set a throwaway value on start up, since after changing a value in the app after initial launch it stops writing, but that didn't work. All settings persistence is written this way and after I comment out the settings.setValue at the bottom of the code, the .conf write process works as supposed to. I have no idea why it is writing when values are set from a power button click. Thoughts?
Here is the code and flow:
void MainWindow::onNavBarButtonClicked(int buttonClickedIdAsInt)
{
//.....
case NavBarButton::POWER:
activeScreenContainer->setCurrentWidget(userScreen);
activeScreenContainer ->raise();
navBarFrame->raise();
navBarActiveContainerSeparator->hide();
logoUserScreen->show();
logoUserScreen->raise();
if(orientationSelected == appPersistence::PORTRAIT_ORIENTATION_VALUE) {
timeAndUserFrame->hide();
}
emit userLoggedOut();
}
to
connect(this, &MainWindow::userLoggedOut, musicScreenModel,
&MusicScreenModel::onUserLoggedOut);
to
void MusicScreenModel::onUserLoggedOut()
{
emit userLoggedOutTreble(currentTrebleValue);
}
to
connect(musicScreenModel, &MusicScreenModel::userLoggedOutTreble,
settingsScreenModel, &SettingsScreenModel::onUserLoggedOutTreble);
to
void SettingsScreenModel::onUserLoggedOutTreble(int trebleToStore)
{
settings.setValue(appPersistence::MUSIC_TREBLE_KEY + loggedInUser,
trebleToStore);
}
And main:
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
QCoreApplication::setOrganizationName("Organization");
QCoreApplication::setApplicationName("AppName");
QSettings::setPath(QSettings::Format::NativeFormat,QSettings::Scope::UserScope, "/opt/");
QSettings settings;
int fontFamilyId = QFontDatabase::addApplicationFont(":/fonts/Quicksand-Bold.ttf");
settings.setValue(fontStyle::QUICKSAND_BOLD_FAMILY_ID, fontFamilyId);
if(!settings.value(appPersistence::ORIENTATION_SELECTED_KEY).isValid()) {
settings.setValue(appPersistence::ORIENTATION_SELECTED_KEY, appPersistence::LANDSCAPE_ORIENTATION_VALUE);
}
if(true) {
DevOnlyFunctions::seedRng();
}
testBuild::setIsTestBuild(false);
MainWindow w;
w.show();
return a.exec();
}
So I finally figured out what the was going wrong. We have a timer that shows whether certain Can Bus devices are present. If they are not present we hide the icons and log out the user directly through calling the onUserLoggedOut() method and not through a connect statement. I was constantly searching for a timer and connect statement and not a direct method call nested within a switch that uses a timer.
Related
I'm trying to use QWebPage in a shared library, which means I have to have QApplication in there to get a GUI context for it to run in. I've built my code up to get this in place, however as soon as I run qApp->exec() the Event Loop completely blocks and prevents anything else from executing. This is with the shared library being ran on OS X, I've yet to try any other platforms.
I've tried adding a QTimer in to trigger every 100msecs but that doesn't ever get called, I'd assume to the event loop blocking. I've added my QApplication setup code below. I'd assume I either need to run it in a thread, or I've missed something trivial but I'm completely unsure what.
web_lib.cpp
WebLib::WebLib(int argc, char *argv[])
{
QApplication a(argc, argv, false);
connect(&m_eventTimer, SIGNAL(timeout()), this, SLOT(handleEvents()));
m_eventTimer.start(100);
a.exec();
}
void WebLib::renderFile(QString file
{
...some connection code that's boring here
m_page = new QWebPage;
m_page->mainFrame()->load(file);
}
void WebLib::handleEvents()
{
qApp->processEvents()
}
web_lib.h
class WEBLIBSHARED_EXPORT WebLib: public QObject
{
Q_OBJECT
public:
WebLib();
WebLib(int argc, char *argv[]);
void renderFile(QString fileName);
private slots:
void handleEvents();
private:
QWebPage *m_page;
QTimer m_eventTimer;
};
main.cpp
int main(int argc, char *argv[])
{
WebLib *webLib = new webLib(argc, argv);
svgLib->renderFileFromName("somePath");
return 0;
}
As soon as I run qApp->exec() the event loop completely blocks and prevents anything else from executing.
That's correct. After you're done with your rendering, you should exit the event loop.
The timer is useless, since calling processEvents from a nonblocking slot like handleEvents simply forces the event loop to be re-entered for a short time, for no reason.
Your event loop has nothing to do. You need to make the render file request before calling a.exec(), not afterwards. In other words, you need to make the following changes:
In the WebLib constructor:
1. Remove the call to a.exec().
2. Dynamically allocate the QApplication instead of putting it on the stack. 3. Remove the timer, you don't need it.
In web_lib.cpp:
Add WebLib::run(), which will call a.exec().
In main.cpp:
After the call to renderFile(), call webLib->run().
The exec must be run in a tread. Alternatively, you can call QApplication::processEvents periodically.
I need to process and close QFileDialog in tests of the application.
The dialog invoked by:
QFileDialog::getOpenFileName( ... );
In the test I 'catch' this dialog by:
QApplication::topLevelWidgets();
Then I choose need file by QFileDialog API.
And now I should close the dialog to get valid answer (filename) from QFileDialog::getOpenFileName();
But QDilaog's slots has no effect (accept(), reject(), close()... ). The dialog stays opened.
The solution described here works, but it is no option in my case. I must to use standard dialogs.
Is there a way to close it properly?
QFileDialog::getOpenFileName is a static method, so you're limited by what you can do with it.
If you want more control, I suggest creating an instance of QFileDialog and using that instead. By calling the instance's close() function, you can programmatically close the dialog.
In response to the comment that this doesn't work, here's example code:-
// Must create the FileDialog on the heap, so we can call close and the dialog is deleted
// Set the Qt::WA_DeleteOnClose flag if the instance is still required
QFileDialog* fileDlg = new QFileDialog(this, QString("Select Config file"), QDir::homePath(), QString("Config (*.xml)"));
// One shot timer to close the dialog programmatically
QTimer *timer = new QTimer(this);
timer->setSingleShot(true);
connect(timer, &QTimer::timeout, [=]()
{
fileDlg->close();
timer->deleteLater();
} );
timer->start(3000);
fileDlg->exec();
In order for to display a native dialog, you have to run exec() or call one of the static functions.
Unfortunately, in Windows, this calls a blocking function in the Windows API making the displayed dialog modal, running it's own event loop. Without returning to the Qt event loop, you cannot execute the close() function using the signals/slots interface.
I tried to bypass this by calling the close() function directly from another thread, but this results in Qt trying to send an event to the underlying dialog. Since sending (as opposed to posting) events across thread boundaries is not allowed in Qt, a fatal error is generated.
So, it seems for Windows at least, this is not possible.
I have not tested on platforms other than Windows. The code I used was:
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
QFileDialog* fileDlg = new QFileDialog(0, QString("Select Config file"), QDir::homePath(), QString("Config (*.xml)"));
// spawn a new thread
QtConcurrent::run([=](){
QTimer timer;
timer.setSingleShot(true);
QEventLoop *loop = new QEventLoop;
QObject::connect(&timer, &QTimer::timeout, [=](){
fileDlg->close();
fileDlg->deleteLater();
loop->quit();
});
timer.start(3000);
loop->exec();
delete loop;
});
fileDlg->exec();
return a.exec();
}
In Windows you can use WinAPI to close the dialog:
#define WAIT(A) while (!(A)) {}
HWND dialogHandle, button;
WAIT(dialogHandle = FindWindow(NULL, L"Open")); //write here title of the dialog
WAIT(button = FindWindowEx(dialogHandle, NULL, L"Button", L"&Open")); //write here title of the button to click
SendMessage(button, BM_CLICK, 0, 0);
I'we started experimenting with unit testing in Qt and would like to hear comments on a scenario that involves unit testing signals and slots.
Here is an example:
The code i would like to test is (m_socket is a pointer to QTcpSocket):
void CommunicationProtocol::connectToCamera()
{
m_socket->connectToHost(m_cameraIp,m_port);
}
Since that is an asynchronous call i can't test a returned value. I would however like to test if the response signal that the socket emits on a successful connection (void connected ()) is in fact emitted.
I've written the test below:
void CommunicationProtocolTest::testConnectToCammera()
{
QSignalSpy spy(communicationProtocol->m_socket, SIGNAL(connected()));
communicationProtocol->connectToCamera();
QTest::qWait(250);
QCOMPARE(spy.count(), 1);
}
My motivation was, if the response doesn't happen in 250ms, something is wrong.
However, the signal is never caught, and I can't say for sure if it's even emitted. But I've noticed that I'm not starting the event loop anywhere in the test project. In the development project, the event loop is started in main with QCoreApplication::exec().
To sum it up, when unit testing a class that depends on signals and slots, where should the
QCoreApplication a(argc, argv);
return a.exec();
be run in the test environment?
I realize this is an old thread but as I hit it and as others will, there is no answer and the answer by peter and other comments still miss the point of using QSignalSpy.
To answer you original question about "where the QCoreApplication exec function is needed", basically the answer is, it isn't. QTest and QSignalSpy already has that built in.
What you really need to do in your test case is "run" the existing event loop.
Assuming you are using Qt 5:
http://doc.qt.io/qt-5/qsignalspy.html#wait
So to modify your example to use the wait function:
void CommunicationProtocolTest::testConnectToCammera()
{
QSignalSpy spy(communicationProtocol->m_socket, SIGNAL(connected()));
communicationProtocol->connectToCamera();
// wait returns true if 1 or more signals was emitted
QCOMPARE(spy.wait(250), true);
// You can be pedantic here and double check if you want
QCOMPARE(spy.count(), 1);
}
That should give you the desired behaviour without having to create another event loop.
Good question. Main issues I've hit are (1) needing to let app do app.exec() yet still close-at-end to not block automated builds and (2) needing to ensure pending events get processed before relying on the result of signal/slot calls.
For (1), you could try commenting out the app.exec() in main(). BUT then if someone has FooWidget.exec() in their class that you're testing, it's going to block/hang. Something like this is handy to force qApp to exit:
int main(int argc, char *argv[]) {
QApplication a( argc, argv );
//prevent hanging if QMenu.exec() got called
smersh().KillAppAfterTimeout(300);
::testing::InitGoogleTest(&argc, argv);
int iReturn = RUN_ALL_TESTS();
qDebug()<<"rcode:"<<iReturn;
smersh().KillAppAfterTimeout(1);
return a.exec();
}
struct smersh {
bool KillAppAfterTimeout(int secs=10) const;
};
bool smersh::KillAppAfterTimeout(int secs) const {
QScopedPointer<QTimer> timer(new QTimer);
timer->setSingleShot(true);
bool ok = timer->connect(timer.data(),SIGNAL(timeout()),qApp,SLOT(quit()),Qt::QueuedConnection);
timer->start(secs * 1000); // N seconds timeout
timer.take()->setParent(qApp);
return ok;
}
For (2), basically you have to coerce QApplication into finishing up the queued events if you're trying to verify things like QEvents from Mouse + Keyboard have expected outcome. This FlushEvents<>() method is helpful:
template <class T=void> struct FlushEvents {
FlushEvents() {
int n = 0;
while(++n<20 && qApp->hasPendingEvents() ) {
QApplication::sendPostedEvents();
QApplication::processEvents(QEventLoop::AllEvents);
YourThread::microsec_wait(100);
}
YourThread::microsec_wait(1*1000);
} };
Usage example below.
"dialog" is instance of MyDialog.
"baz" is instance of Baz.
"dialog" has a member of type Bar.
When a Bar selects a Baz, it emits a signal;
"dialog" is connected to the signal and we need to
make sure the associated slot has gotten the message.
void Bar::select(Baz* baz) {
if( baz->isValid() ) {
m_selected << baz;
emit SelectedBaz();//<- dialog has slot for this
} }
TEST(Dialog,BarBaz) { /*<code>*/
dialog->setGeometry(1,320,400,300);
dialog->repaint();
FlushEvents<>(); // see it on screen (for debugging)
//set state of dialog that has a stacked widget
dialog->setCurrentPage(i);
qDebug()<<"on page: "
<<i; // (we don't see it yet)
FlushEvents<>(); // Now dialog is drawn on page i
dialog->GetBar()->select(baz);
FlushEvents<>(); // *** without this, the next test
// can fail sporadically.
EXPECT_TRUE( dialog->getSelected_Baz_instances()
.contains(baz) );
/*<code>*/
}
I had a similar issue with Qt::QueuedConnection (event is queued automatically if the sender and the receiver belongs to different threads). Without a proper event loop in that situation, the internal state of objects depending on event processing will not be updated. To start an event loop when running QTest, change the macro QTEST_APPLESS_MAIN at the bottom of the file to QTEST_MAIN. Then, calling qApp->processEvents() will actually process events, or you can start another event loop with QEventLoop.
QSignalSpy spy(&foo, SIGNAL(ready()));
connect(&foo, SIGNAL(ready()), &bar, SLOT(work()), Qt::QueuedConnection);
foo.emitReady();
QCOMPARE(spy.count(), 1); // QSignalSpy uses Qt::DirectConnection
QCOMPARE(bar.received, false); // bar did not receive the signal, but that is normal: there is no active event loop
qApp->processEvents(); // Manually trigger event processing ...
QCOMPARE(bar.received, true); // bar receives the signal only if QTEST_MAIN() is used
Environment: Ubuntu, Qt Creator
In my Qt app, I found that sometimes Qt doesn't respond to my key press event immediately, but if I wait a while, it eventually responds.
I think something is blocking the UI.
As I know, if a Qt's component (QWidget etc.) is being destroyed, the Qt UI will be blocked. I have checked my code, there is no component being destroyed at the time I'm pressing the up/down key.
I really want to know is there any other things can block Qt UI.
{
...
connect(webViewWidget, SIGNAL(loadfinished()), this, SLOT(addItem()));
...
}
void addItem()
{
delete webViewWidget; // will this delete block UI?
mListWidget = new ScrollWidget();
mScrollArea = new ScrollArea(this);
for(int i=0; i<Datalen; i++)
{
mListWidget->addSubItem(itemWidget);
}
}
void keyPressEvent(QKeyEvent *event)
{
switch(event->key)
{
case UP_KEY:
scroll up;
break;
case DOWN_KEY:
scroll down;
break;
default:
break;
}
}
In general, your key press event will not be processed before all other events which were put into the application's event queue before pressing your key are processed.
Therefore it could be any kind of event which has not finished processing. Maybe you can figure out if there are any events, e.g. by using QApplication::hasPendingEvents or by inheriting from QApplication and adding debug output whenever an event is added or fully processed.
Destruction of objects is usually not a concern, unless you are doing a lot of work in the destructor. Destroying a webview may take long. You probably should not be destroying it like you do. Instrument that delete (see code below) and see how long it takes.
Your own code may be calling APIs that block. Are you calling any third party libraries? Are you calling any wait... methods in Qt's own API?
If you're unsure, you can instrument every slot and every reimplemented virtual method like xxxEvent(...). You'd need to instrument only slots and reimplemented QObject/QWidget methods, not every method in your code.
You may be producing an event storm, perhaps by posting lots of events in a loop, or by sending a lot of signals that are hooked up to slots connected via a Qt::QueuedConnection. Make sure you're not calling repaint() from within paintEvent() for example.
The instrumentation example below uses RAII and is very easy to apply. Alternatively, you can use a profiler.
#include <QElapsedTimer>
#define INSTRUMENT() Instrument instr__ument(__FUNCTION__)
#define INSTRUMENTLIM(lim) Instrument instr__ument(__FUNCTION__, (lim))
class Instrument {
QElapsedTimer timer;
int limit;
const char * function;
public:
Instrument(const char * name, int timeLimitMs = 20) :
function(name), limit(timeLimitMs) { timer.start(); }
~Instrument() {
if (timer.elapsed() > limit) {
qDebug("%s was slow, took %d ms", function, timer.elapsed());
}
}
}
void slot(...)
{
INSTRUMENT();
...
}
void addItem()
{
INSTRUMENT();
delete webViewWidget; // will this delete block UI?
mListWidget = new ScrollWidget();
mScrollArea = new ScrollArea(this);
for(int i=0; i<Datalen; i++)
{
mListWidget->addSubItem(itemWidget);
}
}
Im making a console application where Im getting user input
with std::getline() (in a while loop). Im also using QextSerialPort (inherits QIODevice). Thus
I need an event loop so I'm using QCoreApplication and calling a.exec().
The problem is getline() blocks event loop and, while it's blocked, I can't receive anything from serial port. I tried to use
QCoreApplication::processEvents() in the while(1){getline()} loop, but found that's not a good solution. Then, I tried to call
QCoreApplication::processEvents() in a QThread but it didn't
work.
Here's the code Im using:
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
Base *base = new Base();
Commander *commander = new Commander(base);
QObject::connect(commander, SIGNAL(end()), &a, SLOT(quit()));
QTimer::singleShot(0, commander, SLOT(run()));
return a.exec();
}
void Commander::askToConnect()
{
if(base->connect() == false){
cout << "Failed to open port." << endl;
}
}
void Commander::run{
string inputline;
askToConnect();
while(1){
QCoreApplication::processEvents(); // ???
cout << endl << "> ";
getline(cin, inputline);
// ...
}
}
How can I have a getline() (or similar method) without blocking event loop?
Yes, i got similar experiences with the ProcessEvent() method called from the main thread. The problem is that it's just put on top of the current call stack and that can have other nasty side effects like endless calling depth or re-entrance problems.
I would just add a few threads to your application to create a clean solution. Since getLine() belongs to the (console) user interface, I would keep it in the main thread and move the networking code into an extra thread but other solutions are also possible (spawning threads for all kinds of interactions and just maintaining them from the main thread).