Just started learning PySide and is having problem with QTimer
I have this
#!/usr/bin/python
from PySide.QtCore import QThread;
from classes import Updater;
if __name__ == "__main__":
thread = QThread();
thread.start();
update = Updater();
update.moveToThread(thread);
update.run();
and this
class Updater(QObject):
def update_mode(self):
#do something
pass;
def run(self):
timer = QTimer();
timer.timeout.connect(self.update_mode);
timer.start(10);
I want my script to do some work periodically using QTimer (wanted to try QSystemAlignedTimer but that looks even more complicated to me for now...). Not sure what is wrong at the moment because I am getting this error
QObject::startTimer: QTimer can only be used with threads started with QThread
QEventLoop: Cannot be used without QApplication
QThread: Destroyed while thread is still running
QTimer, along with all other event based classes, need there to be a QApplication instance.
In:
thread = QThread();
thread.start();
update = Updater();
update.moveToThread(thread);
update.run();
First of all, get rid of the semicolons. Python programmers don't like those.
If you take a close look at what your code is doing, you are making a QThread, starting it, making an Updater, moving it to the thread, running it, and ending the program. There is no command here telling Python to keep the program running, so it ends, and the QThread complains about being destroyed.
What you should do is make a QApplication, with something like
app = QApplication(sys.argv)
and the call app.exec_() to start it. In this case, this is essentially equivalent to time.sleep(9999999999...), but what it actually does is it processes events (signals/slots) endlessly. With time.sleep(9999999999...), QTimers will never do anything when they time out.
As a QApplication is an infinite loop, you will have to manually exit within your code.
Related
In the main thread of a Gui Application I am starting a QProcess of another GUI application that will log some messages over time in stdout using fputs(). The problem is that after some time the GUI application started with QProcess will freeze because it's output is not consumed by the parent. I know that this is the problem because if I am starting the QProcess with QIODevice::NotOpen or QIODevice::Unbuffered argument, it will not get stuck but the output will never be reached.
I've tried to connect the readyRead, readyReadStandardError, readyReadStandardOutput signals of the subprocess to a slot in the parent, but for some reasons the signals are never emitted. I am also flushing the stdout after each write.
My question is how to force QProcess to send some data in real time without closing it?
The connection of the signals, (T- is a wrapper for QProcess):
process->setWorkingDirectory(workingDir);
process->start(prog, argumentsList);
process->waitForStarted();
T* reciver = new V8QProcess(process);
QObject::connect(process, &QProcess::readyRead, reciver, &V8QProcess::OnMessageRecieved);
QObject::connect(process, &QProcess::readyReadStandardError, reciver, &V8QProcess::OnMessageRecieved);
QObject::connect(process, &QProcess::readyReadStandardOutput, reciver, &V8QProcess::OnMessageRecieved);
The code of the subprocess that will log in stdout:
QByteArray bytes = LogMsg::getDisplayable(logMsg, 0).toUtf8();
fputs(bytes.constData(), stdout);
fflush(stdout);
The code of the OnMessageRecieved:
if (!p) { // p is the QProcess
return;
}
QByteArray output;
output.append(p->readAllStandardError()).append(p->readAll());
QString message = QString::fromStdString(output.toStdString());
This approach is working when running a shell script or other simple program.
I found out what the problem was on my case:
Because I was starting the QProcess in a std::Thread, the events(signals) that occur were skipped because std::Thread don't have a queue of events as QThread or QApplication does.
The solution that I use is:
1. Use QThread instead of std::thread
2. Call QCoreApplication::proccesEvents() from time to time.
The proper solution is to use QThread::exec() in order to create an event loop, but this approach would block the GUI Application, so in my case is no good.
I have a PyQt program that hosts 2 widgets. The idea is to interface with my Arduino and display the Arduinos info in the program. I can't really attach my whole program but I'll give the highlights.
The Arduino takes a command over serial via ser.write and returns the subsequent information using ser.read()
So a simple function to continuously read the information from the Arduino would be
while True:
ser.write(command.encode()
time.sleep(.1)
resp=ser.read()
data=struct.unpack('<b',resp)
Now I want to use the information in data in my PyQt program however I cannot continuously run a loop in my Qt program because it will never display the program. I've tried using QThread by making a demo program however it crashes with error QThread: Destroyed while thread is still running. This is my demo program which should have similar functionality to the actual program.
import sys
import urllib
import urllib.request
import serial
import time
from PyQt4 import QtCore, QtGui
class CmdThread(QtCore.QThread):
def __init__(self):
QtCore.QThread.__init__(self)
BASIC="\x24\x4d\x3c\x00"
self.ser=serial.Serial()
#ser.port="COM12"
self.ser.port='COM12'
self.ser.baudrate=115200
self.ser.bytesize = serial.EIGHTBITS
self.ser.parity = serial.PARITY_NONE
self.ser.stopbits = serial.STOPBITS_ONE
self.ser.timeout = 0
self.ser.xonxoff = False
self.ser.rtscts = False
self.ser.dsrdtr = False
self.ser.writeTimeout = 2
self.ser.open()
print('Initializing in 10 seconds...')
time.sleep(10)
def run(self):
self.ser.write(self.BASIC.encode())
time.sleep(0.1)
resp=self.ser.read()
datalength=struct.unpack('<b',resp)[0]
data=self.ser.read(datalength+1)
data=data[4:-1]
temp=struct.unpack('<'+'h'*(int(len(data)/2)),data)
self.ser.flushInput()
self.ser.flushOutput()
print((temp[0]/10,temp[1]/10,temp[2]))
class MainWindow(QtGui.QWidget):
def __init__(self):
super(MainWindow, self).__init__()
self.list_widget = QtGui.QListWidget()
self.button = QtGui.QPushButton("Start")
self.button.clicked.connect(self.start_cmd)
layout = QtGui.QVBoxLayout()
layout.addWidget(self.button)
layout.addWidget(self.list_widget)
self.setLayout(layout)
def start_cmd(self):
downloader = CmdThread()
downloader.start()
if __name__ == "__main__":
app = QtGui.QApplication(sys.argv)
window = MainWindow()
window.resize(640, 480)
window.show()
sys.exit(app.exec_())
Can anyone explain why this is happening or maybe a solution on how to incorporate the simpler while loop into a Qt widget? Thanks so much!
You need to store a reference to the QThread so that it isn't garbage collected. Like this:
def start_cmd(self):
self.downloader = CmdThread()
self.downloader.start()
However be warned that clicking the button a second time will replace the original reference with a new one. And so the first thread may get garbage collected (which is probably fine if it is finished). You may want to eventually consider a more complex architecture where you always have a thread running and send commands from the main thread to the arduino thread via Qt signals/slots.
On another note, I assume at some point you will be using the results from the arduino to update a widget. Please make sure you don't directly access the widget from the thread (Qt GUI objects should only ever be accessed from the main thread). Instead you need to emit a signal (with a parameter that contains your data) from the thread which connects to a slot in the main thread. This slot is then able to safely access the GUI objects.
This shows a more complex example with two way communication between the main thread and a worker thread (albeit without sending data along with the signal emission, but that is a reasonably trivial change)
Hello I've been using PyQt 4.8 on windows to create a simple gui application. The gui(main window) has one button, and one QLineEdit widget. Pressing the button simply calls a function to process the contents of the QLineEdit widget.
So far it works well. My main looks like this
class StartQt4App(QtGui.QMainWindow):
def process_stuff(self,param):
#Do stuff here
if __name__="__main__":
app=QtGui.QApplications(sys.argv)
myapplication=StartQt4App()
myapplication.show()
sys.exit(app.exec_())
Using py2exe I can create an windows executable e.g mygui_app.exe
However I want to adapt it so that it can be run from the windows command line. i.e if the user types
Run mygui_app.exe "c:\text_file.txt"
The application launches, this time without the GUI and automatically processes the parameter that was entered when the application was called.
So far this is what I have come up with
class StartQt4App(QtGui.QMainWindow):
def process_stuff(self,param):
#Do stuff here
def process_stuff_again(self,param):
#Do stuff here
return
if __name__="__main__":
if len(sys.argv)==1:
app=QtGui.QApplications(sys.argv)
myapplication=StartQt4App()
myapplication.show()
sys.exit(app.exec_())
else:
app=QtGui.QApplications(sys.argv)
myapplication=StartQt4App()
myapplication.process_stuff_again(param)
sys.exit(app.exec_())
Essentially if the application has been called with parameters I don't want/need to show the gui, simply call the processing function. Once processing is done exit cleanly
Currently it works, at least as far as processing the file goes. However it does not exit, once the processing is complete. Instead the program remains active (I can see it using the Windows Task Manager).
My question is how do I programatically quit the application? so that once done it cleanly shuts itself down.
I have experimented with
app.quit()
app.exit()
myapplication.exit()
myapplication.quit()
None work, essentially the application is still alive and kicking. In desperation I removed the
sys.exit(app.exec_())
from the else portion of the code and now it just crashes, as it it processes the file and then promptly crashes. Very consistently crashes.
Any suggestion as to how to cleanly get the application to close nicely when its called from the command line?
Not really familiar with PyQt, probably you're doing something wrong in your processing function which leads your app crashed.
Also, in case you processing something synchronously, your
app.quit()
called before
app.exec_()
and doesn't have any effect because event loop (that started with app.exec_()) not started yet.
If you still need to have event loop started before your processing function called (i.e. you're using event loop in your processing function), you can do a quirk like this (it's C++, I'm not familiar with PyQt):
#include <QCoreApplication>
#include <QTimer>
#include <QDebug>
class MyApp : public QObject
{
Q_OBJECT
public slots:
void process()
{
qDebug() << "Processing...";
qDebug() << "Quit application...";
qApp->quit();;
}
};
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
MyApp myapp;
QTimer::singleShot(0, &myapp, SLOT(process()));
int rc = a.exec();
qDebug() << "app finished with" << rc << "code";
}
#include "main.moc"
Also, QMainWindow class doesn't have quit/exit methods (at least in C++).
If you don't need to show the GUI, do you even need to run the QApplication event loop at all? You could just make process_stuff_again a staticmethod
class StartQt4App(...):
#staticmethod
def process_stuff_again(param):
...
app = QtGui.QApplication(sys.argv)
StartQt4App.process_stuff_again(param)
If you're not using any of the Qt classes in process_stuff_again, you don't even need to create the QApplication.
Or if you really need to create an instance of the main window and you absolutely need the event loop, just make sure to call .close on the window at the end of the method. By default, the QApplication should exit when no windows are left open.
def process_stuff_again(self, param):
...
self.close()
I have a Qt GUI-based full application but now I need to use this application in a sort of pipeline in batch mode (console). I've tried several approaches but none of them worked as expected. Here is what I have now:
QApplication a(argc, argv);
MyMainWindow *w = new MyMainWindow();
a.connect(&a, SIGNAL(lastWindowClosed()), &a, SLOT(quit()));
a.exec();
Here is what I need:
QApplication a(argc, argv);
QString project_path = argv[1];
MyMainWindow *w = new MyMainWindow();
a.connect(&a, SIGNAL(lastWindowClosed()), &a, SLOT(quit()));
w->loadPrjFile(project_path);
w->analyze();
w->exportResults();
a.exec();
So, basically what I need is to allow the application to get the project_path through command line (not file dialogs) and execute the methods that a user would usually follow using the GUI. The problem is that these methods should block, in the sense that one should wait for the previous one to finish.
The application itself should block, in the sense that, when executed in the shell, it should wait for the whole execution to finish before quitting. As it should work as a console application the interface should also be hidden.
If you know a way to do that, I would really appreciate a code sample of how this can be done.
The problem you have is that you're trying to develop a console app, but still using Gui widgets, such as QMainWindow. You need to start by separating the Gui classes from everything else in your main project.
I recommend you create a class, derived from QObject, which handles the processing of what you need; loadPrjFile, analyze and exportResults.
Then use an instance of this new class in your MainWindow for the GUI project and use it directly for the console project.
class Worker : public QObject
{
Q_OBJECT
public:
void loadPrjFile(const QString& path);
void analyze();
void exportResults();
};
class MyMainWindow : QMainWindow
{
private:
Worker m_pWorkerObject;
};
If you're developing a console project that doesn't need a Gui, you can use QCoreApplication, instead of QApplication.
Be aware that calling app.exec() starts Qt processing messages, so you only need that if you need a message loop to process events, which may not be the case for a console application, depending on what your app does.
This answer shows the solution that I came up with after a while. I'll put it here because it can be useful to others. The code looks like this:
QApplication a(argc, argv);
QString project_file = argv[1];
MyMainWindow *w = new MyMainWindow();
w->setVisible(false);
a.connect(&a, SIGNAL(lastWindowClosed()), &a, SLOT(quit()));
w->setBatchMode(true);
QObject::connect(w,SIGNAL(loadingFinished()),w,SLOT(analyze()));
QObject::connect(w,SIGNAL(analysisFinished()),w,SLOT(exportResults()));
QObject::connect(w,SIGNAL(exportingFinished()),w,SLOT(close()));
w->loadPrjFile(project_file);
a.exec();
The main considerations are:
w->setVisible(false) was used to hide the MainWindow as also pointed out by #Dissident penguin.
w->setBatchMode(true) was used to set a class variable that is used to supress all the other dialogs throughout the code as also pointed out by #Dissident penguin. Inside the functions I just wrapped the dialog code with an if statement like:
if (!_batchMode) { //show dialog }
Meeting the requirement of sequencial execution was not that easy. I had to create two signals: loadingFinished(), analysisFinished() and exportingFinished(). Then I emit them in the end of loadPrjFile(), analyze() and exportResults() functions respectively. This way I garantee that they are executed in order and that one waits for the other. This is needed because slots are executed asynchronously in Qt.
Finally, I could not take out the method a.exec() because if I do that the program doesn't run properly. I think this is because I'm still using the GUI, it's just hidden. This way, a.exec() is still needed.
To read arguments from the command line in an app with a GUI, you can use the global pointer qApp anywhere in your code. This is particularly useful if you want, for example, to be able to associate your GUI application with a file type, since the file name will be pipleined by the OS to your app (at least it works in Windows).
You can see a detailed answer I gave to the same question in this thread, together with the links to the appropriate documentation, which for some reason is not in the latest versions of Qt.
The second part is not that easy.
You can use w->setVisible(false) before calling a.exec(); to hide your main window, but you will have, to the best of my knowledge, to modify every method that has a dialogue to either react to the command line argument if detected, and disable the dialogue, or use the normal dialogues if no related arguments are detected.
If you only need to call methods of the main window that have no interaction with the user, then it won't be that much work, and you might get away with not calling a.exec (if and only if no part of your code is using signals and slots in batch mode), which in reality starts the main loop of the GUI and won't be needed in that case.
Something like this might work:
QApplication a(argc, argv);
MyMainWindow *w = new MyMainWindow();
if(1 < qApp->arguments().count()) //Command line arguments detected
{
QString project_path = qApp->arguments().at(1);
w->loadPrjFile(project_path);
w->analyze();
w->exportResults();
}
else //No command line arguments detected
{
a.connect(&a, SIGNAL(lastWindowClosed()), &a, SLOT(quit()));
a.exec();
}
If, on the other hand, the functions loadPrjFile(), analyze(); and exportResults() are slots and not, as your code suggests, methods of your main window, they will not be called sequentially and you will have no choice but using signals and slots so each function can notify the next one that it finished its job, and therefore will have to call a.exec
I am trying to create a client application in QT which requires both threads for processing and a variable amount of window instances. But I am having a hard time trying to figure out how to create a new window inside one of the processing thread. I understand that all ui elements must be created in the same thread as the QApplication class, but I need to be able to instantiate, or at least have a reference to a QDialog in another thread.
Communicating between the thread and QDialog can be done using signals, I am not worried about this, but actually creating the window is another matter. I could use signals to tell the main thread to create an instance to the window, and then retrieve the pointer to it somehow, but to me that seems a bit to complicated and ugly. Is there a better way to accomplish such a task? To create a QDialog outside the main thread were the QApplication class exists?
Edit : I have tried the Q_INVOKABLE method but it does not work across threads. I have created a view factory class which can create a QDialog of a type I specify and returns a pointer to it. This class has been instantiated in the main GUI thread and a reference to this class is sent to any worker threads. The problem is that, when a thread invokes the create method from the factory using Qt::BlockingQueuedConnection, the invoke method fails. If I change it to Qt::DirectConnection, the invoke method calls the right create method but in the current thread as the worker thread.
My main function looks like this :
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
ViewFactory vFactory;
vFactory.registerCreator(Util::W_CONNECT, new ConnectWindow::ConnectCreator());
ClientApp app;
if(!app.Initialize(&vFactory))
return 0;
app.start();
a.exec();
.............................
}
And my run function from the ClientApp thread looks something like this :
void ClientApp::run()
{
QDialog * tmp = NULL;
QMetaObject::invokeMethod(this->_vFactory, "create", Qt::BlockingQueuedConnection,
Q_RETURN_ARG(QDialog*, tmp), Q_ARG(int, 0));
}
Like I said, the invokeMothod will not fail if I change the connection type to Qt::DirectConnection, so the params are not the problem, but rather calling the method across a separate worker thread.
You can only do Gui stuff in the gui thread. The obvious solution is for the worker thread to send a message to the gui thread = a signal in Qt terms.
If a worker thread needs to ask a question it should send a message to the gui thread and then block until it gets a signal back.
AFAIK, signals (or just a dynamically callable method, using Q_INVOKABLE) or an event is the way to go.
Note that, using QMetaObject::invokeMethod() (with Qt::BlockedConnection), you can call a function safely across threads and get a return value back without too much coding.
It seems like QObject::moveToThread can solve this problem. This function moves event processing loop to another thread.
Example from Qt documentation:
myObject->moveToThread(QApplication::instance()->thread());