Issue 104110 - Oo calc, inserted rows gets format from row above.
Summary: Oo calc, inserted rows gets format from row above.
Status: CONFIRMED
Alias: None
Product: Calc
Classification: Application
Component: formatting (show other issues)
Version: 4.1.0-dev
Hardware: PC Windows, all
: P3 Trivial with 2 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: needmoreinfo, oooqa
Depends on:
Blocks:
 
Reported: 2009-08-09 00:38 UTC by j_dale14
Modified: 2013-11-28 14:01 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
file with different row heights (7.00 KB, text/plain)
2010-10-30 03:55 UTC, tab
no flags Details
Excel vs. Gnumeric vs. Calc (202.69 KB, image/jpeg)
2013-11-28 14:00 UTC, Edwin Sharp
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description j_dale14 2009-08-09 00:38:19 UTC
In OO -Calc, when inserting a row, the format used
in the new row is from the row above it, instead from the row 
you have marked. 
Maybe a good side effect but confusing.
Comment 1 Regina Henschel 2009-08-09 11:57:47 UTC
The description is not clear to me. Please give a step by step description.
Please describe thereby exactly
(1) what do you set in Tools > Options > Calc > General > item "Expand Formatting"
(2) whether you have set formatting by using a cell style or by assigning a hard
formatting via button or Format > Cell
(3) whether you use drag-drop or copy via clipboard
(4) whether you insert a empty row or use one of the shift options.

You have chosen issue type 'Enhancement', but you do not describe the desired
behavior or additional feature or help text or ... do you want.

Comment 2 j_dale14 2009-08-10 00:04:14 UTC
(1) Q: what do you set in Tools > Options > Calc > General > item "Expand 
Formatting"
ans: is unset
(2) Q: whether you have set formatting by using a cell style or by assigning a 
hard formatting via button or Format > Cell
ans: Used format for border on cells via the toolbar. 
(3) Q: whether you use drag-drop or copy via clipboard. 
Ans: no. 
(4) Q: whether you insert a empty row or use one of the shift options.
Ans: empty row. 

Q:
You have chosen issue type 'Enhancement', but you do not describe the desired
behavior or additional feature or help text or ... do you want.

Ans:
Disired behavior is that rows gets its formatting from the cell currently 
marked when inserting a new row. Maybe it should be marked as an improvement. 

Scenario: 
Sheet with some cells formated with borders. 
The borders from the cells right above where you insert a row, is copied to the 
new row. 
Comment 3 tab 2010-10-30 03:55:34 UTC
Created attachment 72788 [details]
file with different row heights
Comment 4 tab 2010-10-30 03:58:06 UTC
In NewRow.ods, click aa, insert row; new row is 1 cm high. OK.
Now, select rows bb and cc, insert row: new rows are 1-cm high; why? I expected 
the format of the 'mother ' rows (bb, cc; 0.45 cm), not the row above, to be 
copied.
'Squenson' (Forum) replied: 'This is how Excel 2003 behaves.' Flimsy excuse. (If 
Stupid does it, follow him...)
OK, I propose this enhancement: If a block of cells is selected, copy the format 
above (current behaviour).
	But, if one (or several) entire 'mother' row is selected, then copy its 
format into the new row(s). In the case of multiple rows, the individual formats 
could be reproduced. For example, 3 rows of heights 10mm, 15mm and 8 mm would 
make 3 new ones of heights 10mm, 15mm and 8 mm. If that's not what's wanted, the 
current behaviour would still be available.
Comment 5 duncan_clee 2012-09-05 12:07:07 UTC
I am also finding this behaviour totally illogical and ultimately disruptive to my workflow as I have to unpick on a regular basis when adding a row below one I'm using as a sub-heading in a long list.  To quickly re-illustrate:

1) Open a new spreadsheet
2) Drag row 1 to a deeper height and give it a coloured background (for example)
3) Position the cursor in row 2 and click Insert Row
4) A new row 2 with the formatting of row 1 is created

Logic and common sense both demand, surely, that the new row should mimic the selected. ;D

See this thread for a recent revival of the discussion and some very inventive workarounds:
http://user.services.openoffice.org/en/forum/viewtopic.php?f=9&t=56071&p=246604#wrap

Cheers,
C
Comment 6 duncan_clee 2012-09-05 12:12:19 UTC
I meant add: AOO 3.4.1, Windows 7 HP 64-bit
Comment 7 Rob Weir 2013-02-02 03:00:58 UTC
This Issue requires more information ('needmoreinfo'), but has not been updated
within the last year. Please provide feedback as requested and re-test with the the latest version of OpenOffice - the problem(s) may already be addressed. 

You can download Apache OpenOffice 3.4.1 from http://www.openoffice.org/download

Please report back the outcome of your testing, so this Issue may be closed or
progressed as necessary - otherwise the issue may be Resolved as Invalid in the
future.
Comment 8 duncan_clee 2013-02-02 13:49:34 UTC
Is this still alive?  A snail moves faster...

I don't understand what the problem is here - it surely falls into the category of what Basil Fawlty might have called the bleedin' obvious.  Initial descriptions were perfectly clear, Comment 4 (https://issues.apache.org/ooo/show_bug.cgi?id=104110#c4) provides an excellent enhancement to the original request.

This bug - and such it must be as it offends common sense - seems to have got on the wrong foot with Comment 1 (https://issues.apache.org/ooo/show_bug.cgi?id=104110#c1).  The suggestions therein make me wonder whether the contributor had bothered to try it out for herself.  Bit of a call-centre response, really...

From this chair, it doesn't really add to the glory of the project, does it?  

And by the way, yes - it's still happening under 3.4.1.  It's exactly the same as it's always been.
Comment 9 Edwin Sharp 2013-11-28 14:00:00 UTC
Created attachment 82001 [details]
Excel vs. Gnumeric vs. Calc

right click row 3 (formerly row 2) - insert row -> newly added row 2 has format of row 1.
Comment 10 Edwin Sharp 2013-11-28 14:01:06 UTC
Despite comment 9 - IMHO good suggestion.