Refresh application GUI after running external application

[evanol]

Hello,

I'm looking for some advice on how to refresh/redraw my main application after running an external application.

Currently I'm doing the following:

QProcess systemCall;
systemCall.start( externalAppPath, externalAppArgs );
systemCall.waitForFinished( -1 ); //wait indefinitely for process to finish
systemCall.close();
 
QWidget *qwParent = this;
while( (qwParent) )
{
	qDebug() << "repainting parent :" << qwParent;
	qwParent->repaint();
	qwParent = qwParent->parentWidget();
	qDebug() << "next parent :" << qwParent;
}

QProcess systemCall;
systemCall.start( externalAppPath, externalAppArgs );
systemCall.waitForFinished( -1 ); //wait indefinitely for process to finish
systemCall.close();

QWidget *qwParent = this;
while( (qwParent) )
{
	qDebug() << "repainting parent :" << qwParent;
	qwParent->repaint();
	qwParent = qwParent->parentWidget();
	qDebug() << "next parent :" << qwParent;
}

To copy to clipboard, switch view to plain text mode 

As one of the options in my main application I have to launch our external application and wait for it to finish.
On exiting the external application and returning to my main app I need to repaint all parent widgets using the above while loop.

My question is - is there a better way of achieving this?

[anda_skoa]

Well, it is usually very bad to block event processing of a UI application.
Do you have a specific requirement for that?

Cheers,
_

[yeye_olive]

Why do you think you need to explicitly redraw all widgets? Qt handles this as long as you let control return to the event loop. Your current code, which blocks the UI thread until the external process has finished executing, is inelegant because it prevents the user from interacting with your application, and the widgets are not updated. However, if you return to the event loop after the external process has finished executing, the widgets should be updated automatically.

Now, if you want the UI to remain responsive while the external process is running, you need an event loop to be running. Instead of calling QProcess::waitForFinished(), you could connect QProcess::finished() to a slot, then start the process and return to the event loop. Your slot will be executed after the external process has finished executing.

[evanol]

Well, it is usually very bad to block event processing of a UI application.
Do you have a specific requirement for that?

Cheers,
_

Why do you think you need to explicitly redraw all widgets? Qt handles this as long as you let control return to the event loop. Your current code, which blocks the UI thread until the external process has finished executing, is inelegant because it prevents the user from interacting with your application, and the widgets are not updated. However, if you return to the event loop after the external process has finished executing, the widgets should be updated automatically.

Now, if you want the UI to remain responsive while the external process is running, you need an event loop to be running. Instead of calling QProcess::waitForFinished(), you could connect QProcess::finished() to a slot, then start the process and return to the event loop. Your slot will be executed after the external process has finished executing.

See attached image when I launch my external application without blocking the main app. I get the following:
Attachment 11255
alternative link to image
With the above code I am trying to prevent this occurring.

Also, when using the external application, the user should not be interacting with the main application so I felt that waiting for the external application to finish was the best option.

I am open to any/all suggestions on how to achieve this in a better way.
Thanks

[anda_skoa]

As yeye_olive wrote, you don't need any special widget updating, just return from the slot.

I would still not artificially freeze the application.

The option that is closest to your current code is to use a QEventLoop instance and connect the process' finished() signal to the lop's quit() slot.
Then you run exec() with the flag to exclude user input.

Additionally, as a visual clue for the user, I would disable the UI before running the nested loop and re-enable it after exec() returns.

Another option is to use a modal dialog.

Cheers,
_

[yeye_olive]

I cannot download the attachment in your last post. I get an error 'Invalid Attachment specified' when I try to do so.

Globally preventing user interaction is frowned upon, because you do not even let the user close the application. If you want to prevent interaction with specific widgets, call QWidget::setEnabled(false).

Nevertheless, if you insist on preventing user interaction, you could still run a local QEventLoop with the QEventLoop::ExcludeUserInputEvents flag.