diff options
| author | Jan-Marek Glogowski <glogow@fbihome.de> | 2017-08-29 10:29:51 +0200 |
|---|---|---|
| committer | Jan-Marek Glogowski <glogow@fbihome.de> | 2017-09-26 13:53:28 +0200 |
| commit | 9679fb26558ea42e47ac9936cef329115a8fdf65 (patch) | |
| tree | eee6c65d50667fc5b9924f98ce8f87a6df9d707a /svx | |
| parent | 808d048694630303d895e818cfd5fb48c9d16738 (diff) | |
tdf#112288 Clarify Reschedule implementations
Application::Reschedule(true) must just process all currently
pending events and ignore all new events generated while processing
them. In contrast to Scheduler::ProcessEventsToIdle, this way it
can't busy-lock the application with background jobs.
This way we also can drop nMaxEvents from the Windows backend. This
limit was also never implemented on OSX and for the KDE4 backend
it's actually impossible to handle single events, and a call to
QAbstractEventDispatcher::processEvents works like this.
Also changes various call sites to just process all pending events
instead of some made up number of times.
Change-Id: I1ab95df89b079cc8c6319a808194fe3127144d1c
Reviewed-on: https://gerrit.libreoffice.org/42659
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Diffstat (limited to 'svx')
| -rw-r--r-- | svx/source/form/fmsrcimp.cxx | 24 |
1 files changed, 3 insertions, 21 deletions
diff --git a/svx/source/form/fmsrcimp.cxx b/svx/source/form/fmsrcimp.cxx index 596e942f2348..75b04fabd1cd 100644 --- a/svx/source/form/fmsrcimp.cxx +++ b/svx/source/form/fmsrcimp.cxx @@ -311,13 +311,7 @@ FmSearchEngine::SearchResult FmSearchEngine::SearchSpecial(bool _bSearchForNull, bool bMovedAround(false); do { - Application::Reschedule(); - Application::Reschedule(); - // do 2 reschedules because of #70226# : some things done within this loop's body may cause an user event - // to be posted (deep within vcl), and these user events will be handled before any keyinput or paintings - // or anything like that. So within each loop we create one user event and handle one user event (and no - // paintings and these), so the office seems to be frozen while searching. - // FS - 70226 - 02.12.99 + Application::Reschedule( true ); // the content to be compared currently iterFieldLoop->xContents->getString(); // needed for wasNull @@ -376,13 +370,7 @@ FmSearchEngine::SearchResult FmSearchEngine::SearchWildcard(const OUString& strE bool bMovedAround(false); do { - Application::Reschedule(); - Application::Reschedule(); - // do 2 reschedules because of #70226# : some things done within this loop's body may cause an user event - // to be posted (deep within vcl), and these user events will be handled before any keyinput or paintings - // or anything like that. So within each loop we create one user event and handle one user event (and no - // paintings and these), so the office seems to be frozen while searching. - // FS - 70226 - 02.12.99 + Application::Reschedule( true ); // the content to be compared currently OUString sCurrentCheck; @@ -476,13 +464,7 @@ FmSearchEngine::SearchResult FmSearchEngine::SearchRegularApprox(const OUString& bool bMovedAround(false); do { - Application::Reschedule(); - Application::Reschedule(); - // do 2 reschedules because of #70226# : some things done within this loop's body may cause an user event - // to be posted (deep within vcl), and these user events will be handled before any keyinput or paintings - // or anything like that. So within each loop we create one user event and handle one user event (and no - // paintings and these), so the office seems to be frozen while searching. - // FS - 70226 - 02.12.99 + Application::Reschedule( true ); // the content to be compared currently OUString sCurrentCheck; |