Solved proper design for first project
-
Aren't you connecting two slots there ?
buttonPressed should be a signal.
-
Here's what I was trying to do: get the button clicked signal to fire a slot function within the widget, and that slot would also be a signal to the worker.
From your question, I gather that this isn't right, so how do I connect the button press to the worker?
-
Ohhh...I think I just realized something: the signal isn't a routine defined by me. It just gets created for me (by the MOC?).
So, I made these changes:
void SimulatorWidget::buttonPressed() { emit notifyWorker(); }
and in main:
QObject::connect(widget, &SimulatorWidget::notifyWorker, worker, &SimulatorWorker::startStopTimer);
The worker slot now gets called when the button is pressed.
Now, though, my worker slot for the timer:
QObject::connect(&counterTimer, &QTimer::timeout, this, &SimulatorWorker::signalCounterChange);
isn't working. The slot signalCounterChange() is never called. Any ideas here?
Thanks.
-
I'd check that
counterTimer.start(1000)
is really called. -
Yeah, that was basically it. When I stitched together the examples from above, I neglected to notice that my worker object had two timers declared, and I wasn't consistent on which I used.
Works now. I've tested multiple starts and stops, and verified that the "finished" signal works, too. I do believe I have a functional example. I also modified the program so the worker passes the value to the widget for display.
So, to summarize what I've learned here:
- run at least two threads: one for the UI and one to do work. This prevents compute-intensive tasks from blocking the UI updates.
- create a class for the worker, and instantiate an object in main().
- use moveToThread to move the worker object to another thread.
- make your worker interrupt-driven (work depends mostly on signals from UI).
- use the arguments in the signal/slot routines to pass data.
I think I have a basis for reasonable design now. Thank you to everyone who participated in this.