I'm trying to thread wx.ProgressDialog. I got a Progress threading class
class Progress(threading.Thread):
def __init__(self):
threading.Thread.__init__(self)
def run(self):
max = 1000000
dlg = wx.ProgressDialog("Progress dialog example",
"An informative message",
maximum = max,
parent=None,
style = wx.PD_CAN_ABORT
| wx.PD_APP_MODAL
| wx.PD_ELAPSED_TIME
| wx.PD_ESTIMATED_TIME
| wx.PD_REMAINING_TIME
)
keepGoing = True
count = 0
while keepGoing and count < max:
count += 1
wx.MilliSleep(250)
if count >= max / 2:
(keepGoing, skip) = dlg.Update(count, "Half-time!")
else:
(keepGoing, skip) = dlg.Update(count)
dlg.Destroy()
which gets called when I push a button by
class MiPPanel ( wx.Panel ):
[...]
def runmiP(self, event):
thread1 = Progress()
thread1.start()
When I run thread1.start() I get 100s of warnings of the type 2012-12-01 00:31:19.215 Python[3235:8807] *** __NSAutoreleaseNoPool(): Object 0x11a88f300 of class NSConcreteAttributedString autoreleased with no pool in place - just leaking
and the progress bar doesn't show up.
How can I use threading with wxPython to make a progress bar?
All wxPython widgets and manipulation should be in a single thread. If you want to have a dialog controlled by another thread then you will have to use timers and queues to message the dialog from the other thread.
Another way I understand is supposed to work (I have not tested this) it to create a completely separate wxApp in another thread just for your dialog. You will have to communicate somehow back to the main thread still.
Edit:
Here is a link to more information. It has some info at the bottom about using wx.CallAfter to update progress of a worker thread. It also shows how to run a single function in a separate thread without creating a separate class.
wxPython Threading
It looks like it's complaining about argument 4 not being a wxWindow (hence the argument 4 of type 'wxWindow *' part of the error).
Looking at your call, argument 4 is passing parent=self. So, what is self? In other words, what class is the method with this code a part of? Is it something that's a wx.Window or subclass of one, or is it something like an Application or a Progress that isn't?
(Actually, given that you're passing parent as a keyword argument, it's just a coincidence that it happened to be in the 4th position in your call to the wx.ProgressDialog constructor and also be in the 4th position to the call to the underlying C++ function, which is what's actually complaining. You'd get the same error if you switched maximum and parent, and I think it would still say argument 4 instead of argument 3.)
To verify this, try taking out the parent=self in the call that fails, and it should work, or adding parent=object() to the call with just None that works, and it should fail.
Of course that doesn't actually fix the problem. But to do that, you have to figure out what you wanted the parent to be and pass that instead of self.
PS, I don't think the problem has anything to do with your threading at all.
Related
My issue follows: I've a main GUI that manages different connections with an instrument and elaborates the data coming from this latter according to the user choices. I designed a class InstrumentController that manages all the methods to speak with the instrument (connect, disconnect, set commands and read commands).
Obviously I'd like to make the instrument management to work parallel to the GUI application. I've already explored the QThread, and in particular the moveToThread option widely detailed on the Internet. However, though it works, I don't like this strategy for some reason:
I don't want my object to be a thread (subclass QThread). I'd like to maintain the modularity and generality of my class.
...even if it has to be, it doesn't solve the next point
QThread, obviously, works on a single callback base. Thus, I've an extra workload to either create a thread per each InstrumentController method or accordingly configure a single thread each time a method is called (I'm not expecting the methods of the object to work concurrently!)
As a consequence, I'm seeking a solution that allows me to have the InstrumentController entity to work like a separate program (deamon?) but that must be strongly linked to the main GUI (it has to continuously communicate back and forth), so that I need signals from GUI to be visible by this object and viceversa. I was exploring some solution, namely:
Create an extra event loop (QEventLoop) that works parallel to the main loop, but the official docs is very slim and I found little more on the Internet. Therefore I don't even know if it is practicable.
Create a separate process (another Qt application) and search for an effective protocol of communication.
Aware that venturing into one of these solution might be time-consuming and possibly -waisting, I'd like to ask for any effective, efficient and practicable suggestion that might help with my problem.
The first thing to consider is that a QThread is only a wrapper to a OS thread.
moveToThread() does not move an object to the QThread object, but to the thread that it refers to; in fact, a QThread might have its own thread() property (as Qt documentation reports, it's "the thread in which the object lives").
With that in mind, moveToThread() is not the same as creating a QThread, and, most importantly, a QThread does not work "on a single callback base". What's important is what it's executed in the thread that QThread refers to.
When a QThread is started, whatever is executed in the threaded function (aka, run()) is actually executed in that thread.
Connecting a function to the started signal results in executing that function in the OS thread the QThreads refers to.
Calling a function from any of that functions (including the basic run()) results in running that function in the other thread.
If you want to execute functions for that thread, those functions must be called from there, so a possible solution is to use a Queue to pass that function reference to ensure that a command is actually executed in the other thread. So, you can run a function on the other thread, as long as it's called (not just referenced to) from that thread.
Here's a basic example:
import sys
from queue import Queue
from random import randrange
from PyQt5 import QtCore, QtWidgets
class Worker(QtCore.QThread):
log = QtCore.pyqtSignal(object)
def __init__(self):
super().__init__()
self.queue = Queue()
def run(self):
count = 0
self.keepRunning = True
while self.keepRunning:
wait = self.queue.get()
if wait is None:
self.keepRunning = False
continue
count += 1
self.log.emit('Process {} started ({} seconds)'.format(count, wait))
self.sleep(wait)
self.log.emit('Process {} finished after {} seconds'.format(count, wait))
self.log.emit('Thread finished after {} processes ({} left unprocessed)'.format(
count, self.queue.qsize()))
def _queueCommand(self, wait=0):
self.queue.put(wait)
def shortCommand(self):
self._queueCommand(randrange(1, 5))
def longCommand(self):
self._queueCommand(randrange(5, 10))
def stop(self):
if self.keepRunning:
self.queue.put(None)
self.keepRunning = False
class Test(QtWidgets.QWidget):
def __init__(self):
super().__init__()
self.startShort = QtWidgets.QPushButton('Start short command')
self.startLong = QtWidgets.QPushButton('Start long command')
self.stop = QtWidgets.QPushButton('Stop thread')
self.log = QtWidgets.QTextEdit(readOnly=True)
layout = QtWidgets.QVBoxLayout(self)
layout.addWidget(self.startShort)
layout.addWidget(self.startLong)
layout.addWidget(self.stop)
layout.addWidget(self.log)
self.worker = Worker()
self.worker.log.connect(self.log.append)
self.startShort.clicked.connect(self.worker.shortCommand)
self.startLong.clicked.connect(self.worker.longCommand)
self.stop.clicked.connect(self.worker.stop)
self.worker.finished.connect(lambda: [
w.setEnabled(False) for w in (self.startShort, self.startLong, self.stop)
])
self.worker.start()
app = QtWidgets.QApplication(sys.argv)
test = Test()
test.show()
app.exec()
I'm getting familiar with python / wxpython.
I've created a class for the panel / grid.
But I want to "paint" the grid and only after all is loaded / shown, I want to start to run a method / function to count running processes in Windows. Code snippet:
self.sb.SetStatusText('Initialising application...')
self.SetTitle('Computer Check v0.1')
self.Centre()
self.Show()
self.onStart()
def onStart(self):
self.sb.SetStatusText('Counting processes')
count = 0
for process in c.Win32_Process():
count +=1
self.sb.SetStatusText('Found '+str(count)+' running processes')
but it looks like things are following eachother to fast, meaning that the application is being painted and the "onstart()" is already running...
Another thing is that the application "hangs" during the onstart(), it seems quite heavy to use the WMI...or maybe the code is just crap from my side ;-)
Can't find an event to use to initiate the onstart after the application has loaded.
How to do this in a proper way?
thank you!
You can use wx.CallAfter to run a callable when the wx event loop "has free time", or wx.CallLater to run something after some period of time.
wx.CallAfter(self.onStart)
I do not know if Win32_Process takes a long time, if so, it will certainly block the UI. The best thing would be to start a new thread to perform the computation (Win32_Process), and then for example wx.CallAfter to update the UI. Remember, you may not update the UI from other threads.
When your thread calculates the value, you can for example
def thread_run_function(self):
# perform the calculation...
wx.CallAfter(self.update_ui, calculated_value)
def update_ui(self, calculated_value):
self.some_widget.SetLabel("Value: %s" % calculated_value)
Or:
def thread_run_function(self):
# perform the calculation...
self.calculated_value = calculated_value
wx.CallAfter(self.update_ui)
def update_ui(self):
self.some_widget.SetLabel("Value: %s" % self.calculated_value)
Im trying to send a signal from a non-main thread in PyQt but i dont know what am doing wrong! And when i execute the program it fails with this error:
QObject::connect: Cannot queue arguments of type 'QTextCursor'
(Make sure 'QTextCursor' is registered using qRegisterMetaType().)
here is my code:
class Sender(QtCore.QThread):
def __init__(self,q):
super(Sender,self).__init__()
self.q=q
def run(self):
while True:
pass
try: line = q.get_nowait()
# or q.get(timeout=.1)
except Empty:
pass
else:
self.emit(QtCore.SIGNAL('tri()'))
class Workspace(QMainWindow, Ui_MainWindow):
""" This class is for managing the whole GUI `Workspace'.
Currently a Workspace is similar to a MainWindow
"""
def __init__(self):
try:
from Queue import Queue, Empty
except ImportError:
while True:
#from queue import Queue, Empty # python 3.x
print "error"
ON_POSIX = 'posix' in sys.builtin_module_names
def enqueue_output(out, queue):
for line in iter(out.readline, b''):
queue.put(line)
out.close()
p= Popen(["java -Xmx256m -jar bin/HelloWorld.jar"],cwd=r'/home/karen/sphinx4-1.0beta5-src/sphinx4-1.0beta5/',stdout=PIPE, shell=True, bufsize= 4024)
q = Queue()
t = threading.Thread(target=enqueue_output, args=(p.stdout, q))
t.daemon = True # thread dies with the program
t.start()
self.sender= Sender(q)
self.connect(self.sender, QtCore.SIGNAL('tri()'), self.__action_About)
self.sender.start()
I think that my way of send parameter to the thread is wrong...
I need to know how to send parameters to a thread, in my case i need to send q to the worker thread.
Quite new to PyQt5, but this appears to happen when you try to do a GUI operation from a thread which is not the "application thread". I put this in quotes because it appears to be a mistake to think that, even in a fairly simple PyQt5 app, QApplication.instance().thread() will always return the same object.
The thing to do is to use the signal/slot mechanism to send any kind of data from a worker thread (a thread created in my case by extending QtCore.QRunnable, one other pattern apparently being QtCore.QThread and QtCore.QObject.moveToThread, see here).
Then also include a check in all your slot methods which are likely to receive data from a non-"application thread". Example which logs messages visually during execution:
def append_message(self, message):
# this "instance" method is very useful!
app_thread = QtWidgets.QApplication.instance().thread()
curr_thread = QtCore.QThread.currentThread()
if app_thread != curr_thread:
raise Exception('attempt to call MainWindow.append_message from non-app thread')
ms_now = datetime.datetime.now().isoformat(sep=' ', timespec='milliseconds')
self.messages_text_box.insertPlainText(f'{ms_now}: {message}\n')
# scroll to bottom
self.messages_text_box.moveCursor(QtGui.QTextCursor.End)
It's all too easy to just call this inadvertently and directly from a non-"application thread".
Making such a mistake then raise an exception is good, because it gives you a stack trace showing the culprit call. Then change the call so that it instead sends a signal to the GUI class, the slot for which could be the method in the GUI class (here append_message), or alternatively one which then in turn calls append_message.
In my example I've included the "scroll to bottom" line above because it was only when I added that line that these "cannot queue" errors started happening. In other words, it is perfectly possible to get away with a certain amount of non-compliant handling (in this case adding some more text with each call) without any error being raised... and only later do you then run into difficulties. To prevent this, I suggest that EVERY method in a GUI class with GUI functionality should include such a check!
Make sure 'QTextCursor' is registered using qRegisterMetaType().
Did you try to use qRegisterMetaType function?
The official manual says:
The class is used as a helper to marshall types in QVariant and in
queued signals and slots connections. It associates a type name to a
type so that it can be created and destructed dynamically at run-time.
Declare new types with Q_DECLARE_METATYPE() to make them available to
QVariant and other template-based functions. Call qRegisterMetaType()
to make type available to non-template based functions, such as the
queued signal and slot connections.
I would like to add the following notes to the #mike rodent's post which solved my problem (I'm using PyQt5):
Custom signals and slots can be used to avoid directly modifying GUI from thread other than "application thread" (I'm using Python threading module and the equivalent there to that is probably "main thread"). I find this website very useful for basic custom signal and slot setup. Pay attention to using a class (and not an instance) attribute.
To avoid the QObject::connect: Cannot queue arguments of type 'QTextCursor' message I needed to find the following locations and add some code:
Before the function __init__ of the class MainWindow: definition of class attribute; I needed to use something like class_attribute = pyqtSignal(str).
In the function __init__: self.class_attribute.connect(self.slot_name)
Inside of a thread (I mean the thread which is not the main thread): self.class_attribute.emit(str)
In the slot inside the main thread: "safety mechanism" proposed by #mike rodent.
For example:
class DemoFrame(wx.Frame):
def __init__(self):
Initializing
...
self.TextA = wx.StaticText(MainPanel, id = -1, label = "TextAOrWhatever")
self.TextB = wx.StaticText(MainPanel, id = -1, label = "TextBOrWhatever")
...
def StaticTextUpdating(self, ObjectName, Message):
ObjectName.SetLabel(Message)
def WorkerA(self):
while True:
Work on something
UpdatingThread = threading.Thread(target = self.StaticTextUpdating, args = (self.TextA, "Something for TextA", ))
UpdatingThread.start()
time.sleep(randomSecs)
def WorkerB(self):
while True:
Work on something
UpdatingThread = threading.Thread(target = self.StaticTextUpdating, args = (self.TextB, "Something for TextB", ))
UpdatingThread.start()
time.sleep(randomSecs)
...
def StartWorking(self):
Spawn WorkerA thread
Spawn WorkerB thread
...
As you can see, I always update StaticText in new threads, and I'm 100% sure at a whatever certain time point there's only one thread updating a specific object, but the problem is, every now and then after running for a while, some objects just disappear. Why is this happening? Does it mean GUI updating is not thread safe? Maybe only one object can be updated at a certain time point?
Added:
OK, wx.CallAfter should be a good solution for above codes. But I got another question, what if a button event and SetLabel happens at the same time? Wouldn't things like this cause troubles although I don't see any?
Most wx methods are not thread-safe. Use wx.CallAfter if you want to invoke a wx method from another thread; replace
ObjectName.SetLabel(Message)
with:
wx.CallAfter(ObjectName.SetLabel, Message)
Edit: Some Background Information
In wx (And in most other UI platforms) all the UI updates get executed in a single thread called main thread (Or UI Thread). This is to make the UI work faster by avoiding the performance hit of thread synchronization.
But the down side of this is that If we write code to update the UI from a different thread the results are undefined. Sometimes it may work, sometimes it may crash, sometimes some other thing may happen. So we should always go to UI thread to do the UI updates. So we use CallAfter function to make UI update function execute in the UI thread.
UI thread in java
UI thread in C#
The main thing to remember is that you shouldn't update anything in wxPython without using a threadsafe method, such as wx.CallAfter, wx.CallLater or wx.PostEvent. See http://wiki.wxpython.org/LongRunningTasks or http://www.blog.pythonlibrary.org/2010/05/22/wxpython-and-threads/ for more information.
I have a QThread which runs, but will often need to be killed, then recreated. The problem is I'm getting an untraceable TypeError that pops up and I have no idea what's causing it. I presume I'm not exiting the thread properly or destroying it properly or some such sillyness, but I just haven't a clue what's causing it. Here's some code snippets:
Here's the code together:
class getHistory(QThread):
def __init__(self):
QThread.__init__(self)
self.killSwitch = 0
def kill(self):
self.killSwitch = 1
self.wait()
def run(self):
try:
for x in theloop:
hist = QTreeWidgetItem()
hist.data = dataStuff
self.emit(SIGNAL('histItem'), hist)
if self.killSwitch == 1: break
except: pass
self.emit(SIGNAL('string'), 'done')
return
class Main(QtGui.QMainWindow):
def __init__(self, args):
QtGui.QMainWindow.__init__(self)
self.runTheThread()
def doFunction(self, string):
if not string == 'done':
doThreadStuff
else:
doFinishedThreadStuff
def runTheThread(self):
self.theThread= getHistory()
self.connect(self.theThread, QtCore.SIGNAL("string"), self.doFunction)
self.theThread.start()
Then to try to kill it before looping, I kill theThread with self.theThread.kill()
All the proper things as far as killing the thread appear to be happening, except, if the thread is killed and restarted fast enough, I'll get an untraceable error:
TypeError: doFunction() takes exactly 2 arguments (1 given)
Also, on a slightly related note, is it wise/smart/right to check if a thread is done by emitting a string such as "Done" that is picked up by doFunction, or is there a better way to do it?
As doFunction is part of a Qt application, the two parameters are self, string. The code works until it is spammed, really, and only then does it present the error.
Thanks in advance.
Well, as error states clearly: You are sending self.doFunction just one parameter (the string "AllDone" in this case):
self.emit(SIGNAL('string'), 'AllDone')
but, I'll take a wild guess (since you didn't share the definition of doFunction) that it is defined as taking two parameters. So, anytime you emit the "string" signal you are bound to get that error.
As for the signal, if it's sole purpose is to shout that the thread is completed its run, QThread already has a "finished()" signal that is emitted when run is completed. Just use that.
On a side note: If you are using PyQt4.5+ consider using new-style signal and slots. They are more pythonic.