Commit e34e9e1d authored by Emmanuel Promayon's avatar Emmanuel Promayon

FIXED (tentative) do not call processEvents() in the loop

See https://doc.qt.io/qt-5/qcoreapplication.html#processEvents
parent ce28948b
......@@ -177,8 +177,14 @@ void WorkingWhenSleepingLinear::process(ImageComponent* comp) {
camitk::Application::setProgressBarValue(100 * n / numberOfWindows);
myMedicalImageViewer->refresh();
Application::refresh();
Application::processEvents();
// In order to see the change in the viewers, the initial idea was to call
// Application::processEvents();
// but, as explained in the Qt documentation:
// > In the event that you are running a local loop which calls this function continuously,
// > without an event loop, the DeferredDelete events will not be processed. This can affect
// > the behaviour of widgets, e.g. QToolTip, that rely on DeferredDelete events to function
// > properly. An alternative would be to call sendPostedEvents() from within that local loop.
Application::sendPostedEvents();
}
// set normal zoom
......
......@@ -108,9 +108,14 @@ void WorkingWhenSleepingRandom::process(ImageComponent* comp) {
// Refresh the Viewers ....
myMedicalImageViewer->refresh();
Application::refresh();
Application::processEvents();
}
// In order to see the change in the viewers, the initial idea was to call
// Application::processEvents();
// but, as explained in the Qt documentation:
// > In the event that you are running a local loop which calls this function continuously,
// > without an event loop, the DeferredDelete events will not be processed. This can affect
// > the behaviour of widgets, e.g. QToolTip, that rely on DeferredDelete events to function
// > properly. An alternative would be to call sendPostedEvents() from within that local loop.
Application::sendPostedEvents(); }
}
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment