Issue 42162

Summary: API 'StatusIndicator' interrupted by 'adapting row height' status indicator
Product: Calc Reporter: marinus <mpmoelker>
Component: viewingAssignee: AOO issues mailing list <issues>
Status: ACCEPTED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: issues
Version: 680m74   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
Calc file in which behaviour appears none

Description marinus 2005-02-06 20:51:59 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.
Comment 1 marinus 2005-02-06 20:53:11 UTC
Created attachment 22274 [details]
Calc file in which behaviour appears
Comment 2 frank 2005-02-07 08:59:15 UTC
Hi Stephan,

could you check this please ?

Frank
Comment 3 stephan.wunderlich 2005-02-07 09:21:37 UTC
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.
Comment 4 niklas.nebel 2005-02-09 12:47:41 UTC
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.
Comment 5 andreas.schluens 2006-01-19 09:25:05 UTC
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 .-)
Comment 6 andreas.schluens 2006-01-19 09:27:26 UTC
.
Comment 7 Rob Weir 2013-07-30 02:44:35 UTC
Reset assignee on issues not touched by assignee in more than 1000 days.