Issue 80518

Summary: Second y-axis with no series attached has different auto-scaling than the first y-axis
Product: General Reporter: bjoern.milcke
Component: chartAssignee: kla <thomas.klarhoefer>
Status: CLOSED FIXED QA Contact: issues@graphics <issues>
Severity: Trivial    
Priority: P3 CC: IngridvdM, issues, weizhao
Version: 3.3.0 or older (OOo)Keywords: regression
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 72764    
Attachments:
Description Flags
patch_080717
none
patch_080729
none
patch_080909 none

Description bjoern.milcke 2007-08-09 10:59:22 UTC
1. Create a chart (use numbers greater than 12 to see the effect)
2. Check Insert/Axis/Secondary Axes/Y Axis
=> The axis has an auto-scaling that goes from 0 to 12 no matter what the first
y-axis uses as scaling.

The second y-axis should mirror the scaling properties of the first y-axis when
no series are attached to it for all properties that are on "automatic". Note
that e.g. auto-max on the second axis does not mean auto-calculated maximum of
the values, but the maximum of the first y-axis, i.e. if you set max to 17 on
the first axis, the second one should also use 17 when being on auto.
Comment 1 bjoern.milcke 2007-08-09 17:05:29 UTC
Just remembered also this automatism: If all series are attached to the 2nd
y-axis and there is an auto-property at the first y-axis, this must also just
take the value from the 2nd one.

And I suppose the automatisms only affect min, max and auto. Because if you
scale a second y-axis to max==1000, where auto was 10, you don't want to have
the major interval from the other axis when it is on auto.
Comment 2 IngridvdM 2008-01-16 13:41:03 UTC
changed target due to limited resources
Comment 3 IngridvdM 2008-06-04 13:22:04 UTC
changed target due to limited resources
Comment 4 weiz 2008-07-17 02:23:31 UTC
Created attachment 55162 [details]
patch_080717
Comment 5 weiz 2008-07-17 02:24:31 UTC
@iha: The patch for this issue is submitted. Please let me know your 
suggestions. Thanks!
Comment 6 IngridvdM 2008-07-17 08:24:23 UTC
@weiz, please try to avoid the additional parameter xDiagram as it confuses the
interface. One option without interface change would be to change the method
VCoordinateSystem::prepareScaleAutomatismForDimensionAndIndex. When no data is
available fMin and fMax will be NAN.
Comment 7 weiz 2008-07-30 02:33:06 UTC
@iha: The new patch is finished, please let me know your suggestions.
Thank you very much!
Comment 8 weiz 2008-07-30 02:33:46 UTC
Created attachment 55431 [details]
patch_080729
Comment 9 IngridvdM 2008-08-12 15:28:26 UTC
@weiz: Could you also implement the other scenario as described by Björn? When
the first axes has set explicit values the second axes should take that explicit
values as long as the according values at the second axes are set to automatic
and no series are attached to the second axes. Thanks!
Comment 10 weiz 2008-09-09 02:48:02 UTC
Created attachment 56338 [details]
patch_080909
Comment 11 weiz 2008-09-09 02:48:45 UTC
@iha: The new patch is submitted, hope I didn't miss anything. :-)
Please let me know your suggestions. Thanks.
Comment 12 IngridvdM 2008-09-10 10:14:22 UTC
Fixed in CWS chart30.
@weiz, thanks for the patch! I replaced the new method
getExplicitScaleAndIncrementState() by a new method getScale() which is simpler
to understand and allows access to the same information. Further I copied
Orientation and Scaling from the source scale to the target scale to behave like
OOo 2.2 in this case. I also replaced
ChartTypeHelper::allSeriesAttachedToSameAxis with a search about all series.
Searching only the first chart type seems wrong to me. And I added a check to
not set a minimum>maximum. The other parts are fine.
Comment 13 IngridvdM 2008-09-10 16:46:01 UTC
@KLA, please verify in CWS chart30.
Comment 14 kla 2008-09-16 12:46:40 UTC
Seen ok in CWS chart30 -> verified
Comment 15 kla 2008-12-17 14:19:28 UTC
Seen ok in current master -> closed
Comment 16 IngridvdM 2009-04-02 16:30:28 UTC
*** Issue 100656 has been marked as a duplicate of this issue. ***