Apache OpenOffice (AOO) Bugzilla – Issue 42162
API 'StatusIndicator' interrupted by 'adapting row height' status indicator
Last modified: 2013-08-07 15:12:27 UTC
When calling .createStatusIndicator() and running it through .SetValue in a spreadsheet, the status indicator gets interrupted by Calc's status indicator showing 'Adapting Row Height'. This distorts viewing as it blocks the progress indication of a macro. This behaviour is absent in 1.1.4 but consistent through earliers snippets of 2.0. I have attached a spreadsheet showing this problem. (Press SETUP and Re(Create) for an example) Regards, Marinus.
Created attachment 22274 [details] Calc file in which behaviour appears
Hi Stephan, could you check this please ? Frank
sw->nn: just execute the macro in the attached document using the setup-button on the first page. The userdefined statusindicator is bearly visible since calc insists to tell the user that it's adapting the row heights. This worked properly and without interference by calc.
The progress bar from Calc's internal operations has always overridden the API StatusIndicator. It's a bit "random" (timing-dependent) whether a cell operation causes a progress bar to appear, but in principle the situation in OOo 1.1 was the same. To solve this, we would need an API extension to "lock" the user-supplied status indicator content, so following actions don't modify it. MBA agrees this would be useful, but it won't be done for OOo 2.0.
We wont implement such API extension. It must work in the following way: - loadComponentFromURL is asked to load the document - internaly a new status indicator will be created and added to the MediaDescriptor - then the filter (calc) is called and the MediaDescriptor is provided to this filter - now the macro of the document should be triggered and creates it's own status indicator - the feature set of the used StatusIndicatorFactory says now, that the last created status indicator overwrites all progress objects created before on the same factory. So the progress used by the macro should win. If the macro progress is active all requests to the progress used by the calc filter will be ignored (but save the new values and text for it internaly!) - if now the macro progress will be finished (by calling it's API method end()) the current values and text of the calc progress will be shown immediatly. => a) I will investigate into the problem and try to find out, who may be uses it's own progress wrong .-) Such bugs will be fixed then. b) But we wont implement a "lock-feature" here. Because it makes no sense and will make using of a progress to complex. Because everybody involved into the load/save process wish it's own progress interpreted as te most important one .-)
.
Reset assignee on issues not touched by assignee in more than 1000 days.