Created attachment 92202 [details] The attachments demonstrate the misbehavior of the steps described in the Long Description. Problem description: When editing the beginning of the sequence of the Data Ranges the custom formated data points shift. The customized choice should be anchored to the specific points. It is the case when the latest data points are edited. Steps to reproduce: 1. Entering Data points A1 through A20:1,2,3,4,5,6,7,8,9,10...20 2. Entering Data points B1 through B20:1,2,3,2,4,5,3,4,5,6,7,8,7,6,5,6,7,8,9,8 3. Highlighting/ choosing A1 through B20. 4. Charting: Chart type> Line > Points and Lines. 5. Format Data Series: Pick color: Light Blue. 6. Format some of the Data Points: change color to Light Red of the following Data Points: B4, B7, B13, B14, B15, B20. 7. Save. (Attachment 'Calc_Bug_Report_001') 8. Edit Data Ranges: from $Sheet1.$A$1:$B$20 to: $Sheet1.$A$2:$B$20 9. Observe: B4 became Light Blue; B5 became Light Red and so on. (Attachment 'Calc_Bug_Report_002') 10. Go back to step 7 (Attachment 'Calc_Bug_Report_001'). 11. Edit Data Ranges: from $Sheet1.$A$1:$B$20 to: $Sheet1.$A$1:$B$19. 12. Observe: B4 retains Light Red; B5 retains Light Blue and so on. (Attachment 'Calc_Bug_Report_003'). It is the was supposed to be. Current behavior:When editing the beginning of the sequence of the Data Ranges the custom formated data points shift. Expected behavior:The customized choice should be anchored to the specific points. It is the case when the latest data points are edited. Operating System: Mac OS X Version: 4.1.4.2 release
Questionable. What if you change the data range to a totally new place ? The current choice of libO seems to be : preserve rank relative to table top-left, Your demand is : preserve association of a cell with a data point format. Am I right ?
One more remark : what if the whole data range moves down (data range with/without the $) due to insertion of new rows at the top of the worksheet ?
Dear Mr. Boutry, thank you for your reply. You wrote that my bug report is 'questionable'. I do not follow you. Does it mean that you don't believe that the situation which I described is a problem or that such situation exists at all? Anyhow, I have enclosed the attachments so you could see the problem for yourself. You wrote:"The current choice of libO seems to be : preserve rank relative to table top-left, Your demand is : preserve association of a cell with a data point format." Well, that's what it seems. I don't know if you could call it a 'demand' but a wish, it's for certain. When one works with data points and one wishes to assign certain data labels to the specific points - let's say temperature values but then if you move the data ranges - suddenly the point that suppose to be 5 deg. moves to the point that suppose to indicate 25 deg - it seems that it'll create a problem. You have asked "what if the whole data range moves down (data range with/without the $) due to insertion of new rows at the top of the worksheet ?" There are attachments for you to see and to have answers for the "what if" questions. I just tried the 'if scenario' which you described and the problem is still there. Thank you for your help, Vaditus
My answer was : IMHO it is a enhancement/wish/demand, not a characterised bug. So we have to open a pro/con analysis before any change in LibO. I gave some issues regarding this analysis, you gave some too (in your initial description and your answer), which are absolutely valuable also. Other people (developers and others) may too give their opinion to the open question "what is the best specification for this issue". That why I qualified "questionnable" this issue. Best regards D Boutry
Oh, I see, Mr. Boutry. Thank you for your explanation. I totally agree. Cheers! Vaditus
(In reply to comment #0) > 8. Edit Data Ranges: from $Sheet1.$A$1:$B$20 to: $Sheet1.$A$2:$B$20 > 9. Observe: B4 became Light Blue; B5 became Light Red and so on. (Attachment > 'Calc_Bug_Report_002') This behaviour confirmed under GNU/Linux using v3.5.7.2 and v4.4.0.0alpha+ (2014-07-19) as well as MacOS 10.6.8 using v4.3.0.3 Build ID: fcd3838c4097f7817b5b3984fd88a44e1edd8548. As Dominique Boutry has indicated though there are possible problems associated with changing the current interpretation, thus this would more likely seem to be an enhancement request (for additional functionality). Note that the new property mapping feature of v4.3 may offer a potential workaround / alternative: https://wiki.documentfoundation.org/ReleaseNotes/4.3#Property_Mapping Unfortunately, I can't get this feature to activate under MacOS + LO v4.3.0.3 for the provided test file ("Add Property Mapping" button remains greyed out). Vaditus, can you check if the property mapping feature of v4.3 works for you / offers what you require? Status set to NEEDINFO. Please set status back to UNCONFIRMED once the request information is provided. Thanks. Summary edited for clarity.
Owen, unfortunately it does not work for me either. The reason it does not work is the same one as you indicated: "Add Property Mapping" button remains greyed out. The Property Mapping is very promising though.
This should be set to confirmed. Whether or not a dev decides to take it as an enhacement request is up to them.