In Writer when using a progress bar within a macro it should show progress by a coloured bar, in my case blue, moving steadily to the right.
With Master this is no longer the case.
Steps to reproduce the problem.
Download the files ProgressBarTest.odt document from this bug report.
Start LibreOffice writer with the document ProgressBarTest.odt downloaded in step 1. Note: this file contains a macro so be mindful that some security steps might need to be taken.
The document should open and will include the text “This is a test document” and a button called “ProgressBarTest”
The status bar, bottom of the window, should contain the following text -
“Page 1 of 1 5 words, 23 characters Default Style”
Run the ProgressBarTest macro by pressing the button “ProgressBarTest”
The Status Bar will change to the text “Progressing n of 100”
where 'n' will be a number between 1 and 100. To the right of this text a blue line will rapidly move to the right until it uses all available space and 'n' will repeatedly increment by 1 until it reaches 100.
The Status Bar changes to the text “Progressing n of 100”
where 'n' is a number between 1 and 100. There is no blue line. However, 'n' is repeatedly incremented by 1 until it reached 100.
Created attachment 131577 [details]
This document can be used to test Progress Bar issue
This document contains a button that calls a macro. This macro generates a progress bar on the status line. Well it does on all versions of LibreOffice upto an including 4.3.1.
Clicking on the button doesn't display any bar even on versions before 4.3.1. However, If I run the macro from 'Run Macro' dialog I see the bar with
Build ID: d3676ceeec55a41337ce5e6bc596f4f100d0638e
CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2;
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
You can install it alongsidethe standard version.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Downloaded latest daily master build get no blue line in progress bar. The version is
Build ID: 472f92421b1b15dc765714a7c657704812859868
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: kde4;
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-03-01_23:20:29
Also confirmed on latest master pulled from git
Build ID: 7d2ec4c0136c054923947093e35f4ab074f2b550
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2;
Locale: en-GB (en_GB); Calc: group
For the problem with the button the document might be in “Design Mode”. Try toggling it.
Edit → Design Mode
Hello Alex, *,
thank you very much for reporting this bug :) I cannot - however - confirm it with
OS: Debian Testing AMD64
DE: XFCE 4.12
LO: Version: 220.127.116.11.alpha0+
CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: Standard; VCL: gtk2;
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-02-28_00:23:27
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
, sorry ... :( Does it change, if you start LO from command line with "SAL_USE_VCLPLUGIN=gen", "SAL_USE_VCLPLUGIN=gtk2" or "SAL_USE_VCLPLUGIN=gtk3" in front of /path/to/instdir/soffice? Which distro are you using and which DE/DM?
The progress bar works as expected with LO 5.3.1.
I'm using Slackware 14.2 and KDE 4.14.3
Using "SAL_USE_VCLPLUGIN=gen", "SAL_USE_VCLPLUGIN=gtk2" or "SAL_USE_VCLPLUGIN=gtk3" makes no difference the Progress Bar doesn't display the blue line moving to the right. Though they do change the "look" of the application overall especially "SAL_USE_VCLPLUGIN=gen"
Created attachment 131598 [details]
Results from bisect
This is what I got -
0b08eacd79a2133a07410dfb99bcc04bb9dd2199 is the first bad commit
Author: Jan-Marek Glogowski <email@example.com>
Date: Wed Feb 22 17:08:25 2017 +0100
tdf#104482 Force updating progress bar on safe
I don't know why the progress bar on load is handled differently
then on safe. As a workaround, this converts all Flush() calls
to Update() calls, but we should update the UI on safe correctly.
:040000 040000 1b1c9252201f40b413813903009dd320ee195b0f b409c8b19a9925f29a49044779b059c4f0aa0678 M vcl
Adding Cc: to Jan-Marek Glogowski
*** Bug 111861 has been marked as a duplicate of this bug. ***
As already reported this regression was brought about by commit 0b08eacd79a2133a07410dfb99bcc04bb9dd2199. This was to fix the problem whereby tdf#104482 Force updating progress bar on safe which was about the progress bar not operating when saving a file.
The above fix solved the problem of the missing progress bar when saving a file, but stopped the progress bar displaying when used in a macro to just indicate progress on some arbitrary function.
It appears that the above fix was to semi-backout commit 9f4af777a832d8a0b9a21d793d421fa6228131e0
When I reintroduced similar code to that which was removed in 9f4af777a832d8a0b9a21d793d421fa6228131e0 both the progress bar in the save dialog and the macro work as expected.
Tested in windows 8.1 with LO version 18.104.22.168.alpha0+ and the issue is not present.
Tested on Slackware 14.2 with LO Version: 22.214.171.124.alpha0+
Build ID: ffb4d7b16b386ba13f27722cd78406d5b5c5baca and the issue is not present.
The problem was fixed by patch
> 4b44a42b6a54ddf57635fcdb9cf9c18c5e631ff1 Resolves: tdf#111865 ensure draw after SetProgressValue uses new value
Thanks to CaolÃ¡n McNamara <firstname.lastname@example.org> for fixing this.