Re-appearing tdf#152852. How to trigger: - get bugdoc from tdf#89901 - open - creates a draw - select obj - context menu -> break... - opens the break dialog -> that dialog has a progess counter and a cancel-button due to this action can take a long time and allow the user to see progress (elevator-mirror-effect) or to cancel action. Both is not possible since the Dialog gets no repaints (anymore) Reasonm is that Application::Reschedule(true); instead of ensureRepaint(); is *not* enough in BreakDlg::UpDate (IMPL_LINK( BreakDlg, UpDate, void*, nInit, bool )) to get repaint done - at least not under Win... 1st reopened tdf#152852, but now created new task. Sorry, was not aware that this is necessary.
The cancel button appears to only have an effect during the "processing metafile" stage rather than the "broken down/inserted drawing object" phases but that seems to have been ~always the case and/or not related to Application::Reschedule/ensureRepaint
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b913cec377878ed640582dcf611ccf8eaf21bd85 tdf#131395 handle all outstanding events It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
that seems to work for me for the gen case, which I assume should do the same for win
Hi Caolan - yes, works on in, too :-) Thanks! For comment 1: Yes - strange... DrawingLayer would need some more work again