Change the variables in a running function from the outside
-
There's an interface, and when you click the start button, the
start
function will execute, and you can see that as long aspaused
is always false,thestart
function will go on forever.Because I add a
CoreApplication:: processEvents ()
, so now the interface is still responsive. When I click the pause button, thepause
function will be called, and thenstart
will exit. I tried this way, and there was nothing wrong with it, but I'm not sure whether there are other dangers that I hadn't seen.I think if this way is feasible, it's unnecessary to use multi-thread.
int n =1; void start() { while (1) { if (paused) return; qDebug() << n++; QElapsedTimer timer; timer.start(); while (timer.elapsed() <= 500) QCoreApplication::processEvents(); // kepp the interface responsive } } void pause() { paused = true; }
-
There's an interface, and when you click the start button, the
start
function will execute, and you can see that as long aspaused
is always false,thestart
function will go on forever.Because I add a
CoreApplication:: processEvents ()
, so now the interface is still responsive. When I click the pause button, thepause
function will be called, and thenstart
will exit. I tried this way, and there was nothing wrong with it, but I'm not sure whether there are other dangers that I hadn't seen.I think if this way is feasible, it's unnecessary to use multi-thread.
int n =1; void start() { while (1) { if (paused) return; qDebug() << n++; QElapsedTimer timer; timer.start(); while (timer.elapsed() <= 500) QCoreApplication::processEvents(); // kepp the interface responsive } } void pause() { paused = true; }
@Limer Well, you can do it this way, but using processEvents() is considered bad design. Depending on what you're doing inside the loop it can be that you are not calling processEvents() often enough to keep your UI responsive. Also, keep in mind that with this approach other slots can be called while start() is running, so you can still have parallel access to variables (not at the same time though). It is still better to move long lasting operations in a thread.
-
@Limer Well, you can do it this way, but using processEvents() is considered bad design. Depending on what you're doing inside the loop it can be that you are not calling processEvents() often enough to keep your UI responsive. Also, keep in mind that with this approach other slots can be called while start() is running, so you can still have parallel access to variables (not at the same time though). It is still better to move long lasting operations in a thread.
-
@Limer
This is an "odd" way to arrange things. I'm not even sure it will do things the way you want.If the
n++
represents "doing your other work", note that it won't be executing once thewhile (timer.elapsed() ...
is executing. It executes once, then it does nothing (other than keep the UI alive) for half a second. If the user does press "Pause" during that time, it continues doing "nothing" till the rest of the half second has elapsed, only then does it exitstart()
. (You might want to change the loop towhile (timer.elapsed() <= 500 && !paused
) -
@Limer as mentioned in previous posts, you're approach isn't seem a good way to go. One advantage of using Qt framework is dealing with signals & slots to avoid dealing with event loops directly.
Given that said, you may find this example about a file downloader interesting regarding the way the cancel action (pause in your case) is handled to stop (pause) an ongoing download.
-
@Limer as mentioned in previous posts, you're approach isn't seem a good way to go. One advantage of using Qt framework is dealing with signals & slots to avoid dealing with event loops directly.
Given that said, you may find this example about a file downloader interesting regarding the way the cancel action (pause in your case) is handled to stop (pause) an ongoing download.
@Pablo-J.-Rogina Thanks for your response.