Bug 106440 - Inserting a row/column before a frozen row/column does not shift the referenced frozen row/column location as expected
Summary: Inserting a row/column before a frozen row/column does not shift the referenc...
Status: RESOLVED DUPLICATE of bug 99570
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: All Linux (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Cell-Management Cell-Reference
  Show dependency treegraph
 
Reported: 2017-03-08 16:59 UTC by Ben
Modified: 2017-07-18 07:23 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ben 2017-03-08 16:59:54 UTC
Description:
Basically, I expected that any time I insert a row/column into a frozen cell region, none of the existing frozen row/columns should get "bumped" out of this region. It seems the frozen cells are hard referenced to the initial selection. It is easy enough to reset the frozen cell region after row/column insertion so this is really just a feature request, but perhaps there is a reason (beyond me) that it functions this way.


Steps to Reproduce:
1. Select column "C" and choose "View > Freeze > Freeze Rows and Columns"
2. Insert Column between columns "A" and "B"

Actual Results:  
Only two columns are frozen: "A" and the new column "B". The old column "B"'s contents (now column "C") are shifted beyond the frozen cell region.

Expected Results:
Three frozen columns: "A", new "B" and old "B" (now "C"). Columns "D" and beyond are not frozen.


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-us) AppleWebKit/537+ (KHTML, like Gecko) Version/5.0 Safari/537.6+ Midori/0.4
Comment 1 Buovjaga 2017-03-14 12:05:08 UTC
(In reply to Ben from comment #0)
> It is easy enough to reset the frozen cell region after
> row/column insertion so this is really just a feature request, but perhaps
> there is a reason (beyond me) that it functions this way.

Eike: is there a reason for this?
Comment 2 Gabor Kelemen 2017-07-18 07:23:02 UTC

*** This bug has been marked as a duplicate of bug 99570 ***