Issue 8302 - Allow to insert/delete into/from the middle of merged cells.
Summary: Allow to insert/delete into/from the middle of merged cells.
Status: CLOSED FIXED
Alias: None
Product: Calc
Classification: Application
Component: ui (show other issues)
Version: OOo 1.0.1
Hardware: All All
: P3 Trivial with 119 votes (vote)
Target Milestone: ---
Assignee: oc
QA Contact: issues@sc
URL:
Keywords:
: 8363 14769 35705 36479 39911 49941 67359 76861 79995 88632 94024 95936 99444 103195 104325 104426 (view as issue list)
Depends on:
Blocks: 72764
  Show dependency tree
 
Reported: 2002-10-13 21:06 UTC by jmills
Modified: 2014-05-20 17:29 UTC (History)
27 users (show)

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


Attachments
Fix this issue, but missing a really clean undo part. (4.08 KB, text/plain)
2007-05-20 13:56 UTC, mloiseleur
no flags Details
A new version of the patch, which allows to undo/redo in one action (4.56 KB, text/plain)
2007-07-14 14:52 UTC, mloiseleur
no flags Details
updated version : no more performance problem (13.67 KB, patch)
2008-08-28 23:02 UTC, mloiseleur
no flags Details | Diff
The patch file is about i8302#-Insertcells_v1 (18.67 KB, text/plain)
2009-02-13 08:27 UTC, yonggang.mao
no flags Details
The patch file is about i8302#-Insertcells_v2 (16.66 KB, text/plain)
2009-03-02 07:04 UTC, yonggang.mao
no flags Details
Update the patch about v2. (16.81 KB, text/plain)
2009-03-02 15:06 UTC, yonggang.mao
no flags Details
Update the patch again. (13.16 KB, text/plain)
2009-03-03 04:06 UTC, yonggang.mao
no flags Details
The patch file is about i8302#-v3. (25.00 KB, text/plain)
2009-03-06 08:21 UTC, yonggang.mao
no flags Details
Additional patch for the undo action (647 bytes, text/plain)
2009-03-10 18:43 UTC, niklas.nebel
no flags Details
TestCaseSpecification (7.83 KB, text/html)
2009-05-14 08:57 UTC, oc
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description jmills 2002-10-13 21:06:18 UTC
see attached spreadsheet to issue 8300

What I want to be able to do is insert a new "entry" into
the top table at, say, column P

What I want to do is to

select 04:P18 (or even O3:P19), right-click, Insert Cells
Shift cells right.

but you can't.

I don't see why this should be be allowed.

I could perhaps understand if the table edge was on row P, but it isn't.
Comment 1 oc 2003-09-17 09:40:48 UTC
Hi Bettina, one4you
Comment 2 bettina.haberer 2003-12-01 13:37:52 UTC
Hello Niklas, please give approval for this evaluated OO.o 2.0 flagged
issue. 
If you confirm with the target OO.o 2.0, then please keep it on your
owner (or the owner of the concerning developer) for implementation.
In case you want this issue for 'OOo Later', then please reset the
target milestone. If you decline the issue finally, please set the
resolution to 'Wontfix' (but do not close). In case of 'OOo Later' or
'Wontfix' please reset it on Bettina's owner. Thank you.
Comment 3 niklas.nebel 2004-01-26 11:37:44 UTC
This is not on the list of features that we're going to do for 2.0. We need to
focus on the enhancements from the PCD document.
Comment 4 frank 2004-10-18 13:44:16 UTC
*** Issue 35705 has been marked as a duplicate of this issue. ***
Comment 5 frank 2004-11-02 08:55:57 UTC
*** Issue 36479 has been marked as a duplicate of this issue. ***
Comment 6 frank 2005-01-05 11:04:58 UTC
*** Issue 39911 has been marked as a duplicate of this issue. ***
Comment 7 frank 2005-05-27 09:41:30 UTC
*** Issue 49941 has been marked as a duplicate of this issue. ***
Comment 8 dieeasy 2005-12-23 10:09:54 UTC
I think OS field for this issue sould be "all OSes" and maybe version is "all"
IMO this issue deserves some attention, because I found it preventing many users
from switching to OOo...

I understand there may be many reasons for not having the feature implemented
yet, I'm not complaining, it's a suggestion.

Let me thank you all guys for your excellent work! As soon as I get my
colleagues used to OpenOffice I'll do my best to donate what we can to help
support development...
Comment 9 dieeasy 2006-02-06 08:12:38 UTC
this issue and 14769 are about the same thing, but they're both still open
Comment 10 gercokees 2006-07-05 11:08:25 UTC
*** Issue 14769 has been marked as a duplicate of this issue. ***
Comment 11 gercokees 2006-07-05 11:11:20 UTC
I closed the duplicate issue 14769
There were 24 votes on issue 14769, so, can someone please transport those votes
to this issue?

Also, i think this issue should be confirmed...
Comment 12 ivanmomm 2006-07-11 14:31:32 UTC
It would be important in document formating easily insert and delete columns 
when there is one or more merged cells in range. Actually is necessary unmerge 
cells, delete (or insert) row (or column) and then re-merge cells again. Very 
difficult. In version 2.03 the problem remains. In M$ Excel this is possible so 
it is important to solve the problem in Ooo.
Note that this issue and issue 14769 are about the same thing and have 31 
votes. This issue is also very old.
Comment 13 frank 2006-07-14 07:58:29 UTC
*** Issue 67359 has been marked as a duplicate of this issue. ***
Comment 14 dieeasy 2006-07-17 07:21:07 UTC
I wanted to ask if this is really a WindowsXP-only issue. It seems to me that 
this sould be an all-OS feature request.
Comment 15 gercokees 2006-07-17 07:53:00 UTC
Changed os to all
Comment 16 dieeasy 2006-07-25 13:57:43 UTC
I noticed this thing...

initial situation: a first cell made up of some merged cells, say A1:C1, and a 
second cell made up of similar merged cells, say A3:C3

action to do: copy A1:C1 over A3:C3

result: I can't, because I can't insert cells into merged cells

this is an annoying behaviour, because 1)a user coming from Excel gets 
disappointed and instantly gets back to MS Office 2)how can I do this if I need 
to format a sheet (joining cells and the like) and then copy&pasting formulas 
across groups of merged cells? I have to unmerge all of them and then do the 
copy&paste work, which is really time comsuming compared to a straight 
replication of a group of cells across an entire sheet (for example)

---
I said this here because I think this behaviour and this issue are tightly 
related, and I want to say my opinion is: this behaviour is preventing many 
people from using OpenOffice.org and makes some duties hard to do, compared to 
MS Excel. Otherwise it would be helpful having a paper describing how do to 
those operations and why it is better.

my 2 cents
Comment 17 barretconsulting 2006-12-06 21:09:35 UTC
This function is highly needed.  This is one stickler that will not help us
migrate to OO from M$ office.  This should be a high priority.  Standard users
will not think ahead when planning a spreadsheet.  Therefore, this function will
be required on a steady basis.

I have many spreadsheets that I would like to port over and modify. I am
currently modifying in M$.  Therefore, kinda pointless to completely move away
from M$.

Comment 18 tanstaafl 2007-02-20 13:04:27 UTC
Are there any plans on implementing this? I cannot believe this issue has been
around this long.

This one thing KILLED a migration I had begun for one of my clients - as soon as
the owner of the company ran into this, he threw up his hands, and killed the
project - at least for now.

Please, please, please - this is such a pain in the butt, and should be so easy
to fix...
Comment 19 frank 2007-05-03 10:49:54 UTC
*** Issue 76861 has been marked as a duplicate of this issue. ***
Comment 20 mloiseleur 2007-05-20 13:56:15 UTC
Created attachment 45274 [details]
Fix this issue, but missing a really clean undo part.
Comment 21 mloiseleur 2007-05-20 14:04:10 UTC
Hi,

   I have made a patch which fix this issue. I have taken for sample document
the attached spreadsheet of issue 8300.
   When I do those things :
- select Q18:Q3
- Right Clic->Insert Cells 
- Choose  Shift Cells right
   Calc do what you naturally want him to do. All overwhelming merged ranges in
the way are unmerged, the cells are inserted, and those ranges are then remerged
with the new cells.

  This patch is not complete, in its current state. I have the 'undo' problem.
When you try to undo, it takes you 5 steps before having the original table. And
I suspect that more than one step is not acceptable.

-> bh : Can you take care of this point ? Or give me a great hint so I can do it
myself ?

Regards,
Comment 22 nitro100 2007-05-22 08:25:43 UTC
Ok, I have a patch, but how can i apply this patch 2 my OO ?
Comment 23 mloiseleur 2007-05-22 08:31:52 UTC
nitro100 : you can't. This is a patch only applies on source code, on a dev
source release (m212) and is not complete. 
   You have to know how to build OOo and how to a apply a source code patch in
order to see it in action on your desktop.

Regards,

Comment 24 niklas.nebel 2007-05-25 15:37:27 UTC
I think the approach is valid and can be used. Some details:

- The order of the undo actions has to be unmerge-insert-merge (add the "insert"
action before the MergeCells calls), otherwise there's an invalid state after redo.

- As mentioned on IRC, the actions can be grouped together using
EnterListAction/LeaveListAction.

- Why is the inserting of whole columns excluded? That seems to be the more
common case. The determination of the merged ranges would then have to be
changed from the nested loop to something more efficient.

- If inserting is possible, something similar should be done for deleting cells.
Comment 25 mloiseleur 2007-05-25 15:49:11 UTC
-> nn : 
> I think the approach is valid and can be used. Some details:
Thanks.

> - The order of the undo actions has to be unmerge-insert-merge (add the
"insert" action before the MergeCells calls), otherwise there's an invalid state
after redo.
It seems to me that's what the order which was executed. I'll take a more deeper
look at it.


> - As mentioned on IRC, the actions can be grouped together using
EnterListAction/LeaveListAction.
Yes, I have planned to improve it during next week end.


> - Why is the inserting of whole columns excluded? That seems to be the more
common case. The determination of the merged ranges would then have to be
changed from the nested loop to something more efficient.
I am not really confortable with it. Don't really know what to expect and so
what code I should write. I have tried with the calc on issue 8300 and it was so
messy that I left it for the moment.


> - If inserting is possible, something similar should be done for deleting cells.
hmm... yes ... one thing after another, right ? :)  Let's finish this one first.




Thanks for all your comments Niklas,
Comment 26 frank 2007-06-07 11:19:09 UTC
Hi Niklas,

you're involved and as it is a PATCH now, please have a look at it and proceed.

Frank
Comment 27 rail_ooo 2007-06-13 22:45:48 UTC
mloiseleur: thanks for the patch. Seems like it is working ;). Just tested it on
Linux, Windows and FreeBSD. Works better than "Cannot insert". :)

It would be great to see enhanced version and push this feature upstream.

Add CC.
Comment 28 mloiseleur 2007-06-14 09:08:17 UTC
rail -> I am bit under a mountain of works. Maybe this week end, and the next
one. Thanks for your feedback. I'll try to improve it as soon as I can.
Comment 29 mloiseleur 2007-07-14 14:52:49 UTC
Created attachment 46784 [details]
A new version of the patch, which allows to undo/redo in one action
Comment 30 mloiseleur 2007-07-14 14:58:52 UTC
Hi all,
  Here is a new version of the patch. It allows user to insert in the middle of
a merged cells without any problem, in a "natural" way.
  It works both for lines or columns (shit cells right,shift cells down, entire
row or entire column). It was ported to m219, too.
  I don't have anymore the "undo problem", thanks to Niklas knowledge.

  I now think the patch is ready. 
-> Niklas : can you say to me what am I missing, or better, integrate it ? ;)

Thanks,
Comment 31 frank 2007-07-24 20:15:13 UTC
*** Issue 79995 has been marked as a duplicate of this issue. ***
Comment 32 andreschnabel 2007-10-21 10:08:51 UTC
as we have a patch available, I'd like to speed up this a little. 

@mloiseleur: can you provide a binary for testing your patch? (Windows or
Linux). Would be helpfull, as long we do not have a cws for this.
Comment 33 mloiseleur 2007-10-21 12:59:53 UTC
Well the patch is integrated in ooo-build since last-week. Just use their last
dev build and you should see it. I have also made the work for deletion.
Now, I am doing a bit of refactoring, a lots of things are needed anymore. 
I'll put the final patch on go-oo and on this issue when it will be ready.
Comment 34 rail_ooo 2007-10-23 14:41:37 UTC
mloiseleur.

Can you reproduce the following:
1. Add a text into A1
2. Merge A1:B1
3. Select A column and insert a column
result: entered text disappeared, A1:C1 merged
4. unmerge A1:C1
result: entered text (see 1) is in B1

Seems like you need to check if there is a text in affected merged cells and
make it visible (move to the first cell of merged cells?).
Comment 35 frank.loehmann 2008-02-20 11:15:02 UTC
Set target to 3.x due to high number of votes and patch being present.
Comment 36 tanstaafl 2008-02-20 12:24:59 UTC
Wow, this is great that this will finally be possible. This is one of the most
frustrating issues for some of our power users...

Thanks guys!!!
Comment 37 hidden 2008-04-10 12:43:03 UTC
Oh, when will this happen?
Comment 38 dingfelder 2008-05-01 23:40:53 UTC
still occurring in 2.4    any plans to add this feature for an upcoming release?
 it is blocking my migration from msoffice to openoffice :(
Comment 39 tanstaafl 2008-05-02 14:05:57 UTC
Since the target milestone is 3.x, why would you bother reporting that it
doesn't work in 2.4?

Patience is a virtue...
Comment 40 frank.loehmann 2008-05-22 09:30:49 UTC
This issue is important and listed on the quarterly review for Calc:
http://wiki.services.openoffice.org/wiki/2008_Q2_Review_of_Spreadsheet_Project
Comment 41 frank 2008-08-21 08:34:41 UTC
*** Issue 88632 has been marked as a duplicate of this issue. ***
Comment 42 canis 2008-08-26 12:21:28 UTC
Hey guys. What about 3.1?
Comment 43 tanstaafl 2008-08-26 13:33:57 UTC
3.1?! What about 3.0??

The patch already exists, so if this isn't in 3.0, then I'm quickly losing faith
in the sanity of the OOo devs, and will start looking at other builds like GoOOg...
Comment 44 ooo 2008-08-28 11:23:29 UTC
@tanstaafl: you should get acquainted with the release schedule (see
http://wiki.services.openoffice.org/wiki/OOoRelease30 ) before accusing, let
alone insulting, anyone. Code freeze for OOo3.0 already passed some time ago and
only show stoppers are being fixed now. Yes, this patch should had been reviewed
and maybe integrated earlier, but now it is too late for OOo3.0
Comment 45 tanstaafl 2008-08-28 15:40:44 UTC
> @tanstaafl: you should get acquainted with the release schedule
> (see http://wiki.services.openoffice.org/wiki/OOoRelease30 )

Ok...

> before accusing, let alone insulting, anyone.

I didn't 'accuse' or 'insult' anyone my friend - and I don't think I was even
rude - I simply pointed out a somewhat painful fact.

> Code freeze for OOo3.0 already passed some time ago

Well, not *that* long ago... 4 months (April 2008), according to the link you
provided.

So... code freeze happened in April 2008, and the patch for this functionality
was originally uploaded in May of *2007* - 9 *months* (almost a full *year*)
before the code freeze, and 8 *months* before the feature freeze. Not only that,
according to this thread, it was integrated in ooo-build in October of 2007, a
full 6 *months* before the code freeze.

So, how much time, exactly, do the devs need before merging a patch into the
official build that has as many votes as this one has, *and* has a *working
patch* that someone was willing to write to implement it?

> and only show stoppers are being fixed now. Yes, this patch should had
> been reviewed and maybe integrated earlier, but now it is too late for OOo3.0

Too late because the OOo devs are extremely unresponsive to user requests for
features they (the devs) don't deem 'important', *even when a patch is provided*.

This (the official OOo devs being slow and often unresponsive to accept patches
from 'outside' devs) is a well known fact, and the primary reason that Novell
started the go-ooo offering.

Don't shoot the messenger... maybe your time would be better spent *listening*.

I'm a *long* time OOo user - 7+ years in fact (we used Staroffice 5.2 before
changing to a pre 1.0 version of Openoffice.org) - and Admin who rolls it out on
all 60+ machines in our office - and I *do* appreciate very much the effort
involved with developing and providing OOo - but there is also a very large
level of frustration with OOo development (see above).
Comment 46 yak777 2008-08-28 18:50:40 UTC
This issue in a first place of 2008 Q2 Review of Spreadsheet Project.
http://wiki.services.openoffice.org/wiki/2008_Q2_Review_of_Spreadsheet_Project
This feature must present in OO.o 3.0!
Comment 47 niklas.nebel 2008-08-28 19:41:26 UTC
mloiseleur, on Oct 21 you commented that you would attach a final patch when
it's ready. Do you have a final one by now?
Comment 48 mloiseleur 2008-08-28 23:02:46 UTC
Created attachment 56072 [details]
updated version : no more performance problem
Comment 49 mloiseleur 2008-08-28 23:16:05 UTC
->nn : not a final one, but it's still much better. It was developped against a
dev300 code base.
   It's heavy merged sheet' proof but it's not dumb's proof : that's what the
final version is about, isn't it ? ;). It works fine as long as you don't have
at the same time a vertical merged range or an horizontal merged range in an
insertion box of at 2+ cols & 2+ Rows.

   I did not find yet time & motivation to finish it, but here are the wise
comments of Kohei about this patch (my personal advise is preceded by a '>'):
8<----------------------------------------------------------------------
So, I took a deeper look of your patch & have a few comments.

1) I think it's far more efficient to directly manipulate the merged
cell attributes during the cell insertion operation, instead of calling
UnmergeCells() and MergeCells() before and after the cell insertion,
because these two calls are somewhat expensive & potentially hurt
performance.
> +1, but not sure how to do this properly

2) Instead of using EnterListAction() and LeaveListAction(), sticking
with just the ScUndoInsertCells instance will make the code a little
cleaner maintenance-wise.
> +1, I have tried but failed on this one, I had very strange behaviour.

3) In terms of behavior, I think the most logical behavior would be the
following:

  * for column insertion case, to take the leftmost column's merged
state and copy it right for the inserted column(s) except when the
selection overlaps the anchor cell of the merged range (i.e. the topleft
cell).  When the selection overlaps the anchor cell, the merged range
simply gets shifted & there is no need to expand that merged range.

  * for row insertion case, similar to the column insertion case but
copy the topmost row's merged state down.  The same rule applies when
the selection overlaps the anchor cell of a merged range.

4) Additionally, we probably should enforce the following rules:

  * check all the merged ranges that the selection overlaps.  If there
is at least one merged range whose vertical range goes outside the
vertical range of the selection, then the users should not be allowed to
insert columns or insert cells & shift right.
> -1 : The main point of my patch is to get rid of those ridiculous message box.

  * Similarly, if there is at least one merged range whose horizontal
range goes outside the horizontal range of the selection, then the users
should not be allowed to insert rows or insert cells & shift down.
> -1 : same reason.

For example, say C5:E5 is merged, and D3:D7 are selected.  In this case,
because the selection's horizontal range does not entirely encompass the
horizontal range of the merged region, the users are not allowed to
insert row(s) or insert cells & shift down.  I think this is important,
otherwise a very weird behavior would ensue.
  
So, if I were you I would:

1) remove the merged cell checking code entirely from
ScDocFunc::InsertCells(), 

2) write new attributes to the inserted cells according to the above
behavior.  The right place for this would probably be
ScTable::InsertCol() for column insertion, and ScTable::InsertRow() for
row insertion.

3) adjust the code in ScUndoInsertCells to make the undo/redo work.

4) look into disabling certain menu items in the column/row header
context menus & the insert cells context menu, based on the above rules.

5) maybe more that I forget ...

P.S. Excel doesn't need to worry about handling stuff like this, since
Excel's range selection always expands to entirely overlap any merged
regions.  So, inserting cells while a merged region is partially
selected would never happen.  I personally like Excel's range selection
behavior though.  It takes away a lot of worries.  Anyway, I digress.
> +10 : maybe it's the right answer to this problem.
8<----------------------------------------------------------------------

  Niklas, Kohei or who ever, feel free to pursue, improve or break this patch. I
am currently on mail merge performance in Writer, and it's enough to busy me all
the day.


Regards,
Comment 50 discoleo 2008-09-06 16:07:21 UTC
Lets start devising a specification. I will offer a starting point for the
features I feel need to be implemented within this request (but feel free to
express a different opinion):

A.) Insert into Merged Cells
 - A1-D1 is merged
 - we want to insert a column between column B & C

This should be possible.
Columns A & B remain unmodified. Columns C & D get shifted to the right.
Though, what should happen with the merged A1-D1 cell and the newly inserted
newC1 cell?

There are 2 options:
 i.)  merge C1-D1 with the newC1 cell
      the 2 contents should be appended OR
      the old content should be overwritten
 ii.) the new cell (newC1) acts as a splitter, i.e.
      A1-D1 gets split into:
        A1-B1 and
        C1-D1 which gets shifted to D1-E1
        the new, unmerged cell gets inserted between A1-B1 and D1-E1

I strongly support both options presented at i.). Because cell A1 would inherit
all the content anyway, I do not see any strong indication for ii.).
[A possible utility arises when more cells are merged, like IF A1:D2,
 then after inserting we have:
  A1:B2 and D1:E2 and the unmerged cells C1 and C2.
  All the initial content would be in A1:B2,
  while C1 & c2 would preserve their own content.]

A dialog should pop up for choosing the appropriate option from point i.), BUT
if the merged cells are empty, then NO dialog is needed.

B.) Delete Merged Cells
Similarly, suppose cells A1-D1 are merged, and we want to delete column B. What
should happen with the cell A1-D1?
 i.)  Cell A1-D1 becomes A1-C1
       - content is deleted from this cell
       - content is preserved
 ii.) Whole cell A1-D1 is deleted
       - cells E1-... are shifted left
 iii.)A1-D1 is split into:
        A1 and
        C1:D1 which gets shifted to B1:C1
        A1 inherits the content

Again, I do not see a strong case for ii.)-iii.), while option i.) seems
sensible and needs a dialog to ask for the proper action (delete/preserve
content). IF the whole merged cell is selected and deleted, then NO dialog is
needed (and is already working in Calc).
Comment 51 discoleo 2008-09-09 16:39:50 UTC
TO everyone: This is the 2nd call.

Please have a look at my previous post.

In order to get a feature implemented into OOo, we need to write a specification.

That is why I brought into discussion the way this feature should work.

I started also a discussion on the UX-list, see:
http://ux.openoffice.org/servlets/ReadMsg?list=discuss&msgNo=2336
[But NO responses either.]

To explain some of my rationale:
When we have merged cells, we may want to insert some cells or delete some
cells. Because inserting/deleting a limited selection creates a lot of ambiguity
(by allowing different options to shift cells up/right/...), I decided to start
with inserting/deleting whole rows or columns. This is more easily handled and
behaves predictably.

A number of scenarios are possible even when inserting or deleting a whole
row/column, see my previous message.

When inserting: new cell would be added to the merged complex.
Should the new content replace or be appended to the existing content?

When deleting:
Delete content from merged cells, or leave content untouched?

Some further options are discussed in the other posts. Feel free to add any
other opinion/option.

I actually favour both options in both instances, so a dialog is warranted. For
inserting/deleting only a limited selection of cells, the "shift"-options could
be disabled, allowing only insert/delete whole row/column (and of course a
CANCEL button).
Comment 52 tanstaafl 2008-09-09 19:46:24 UTC
Personally, I see no reason to reinvent the wheel.

How does the evil alternative do it? Do it that way, at least at first. If there
is room for improvement, improve it, but lets just get it done. This one issue
has been driving a movement to replace Openoffice on all 55+ of our PCs with
MSO, and I'd really like to NOT see that happen. I've been putting people off
with 'its coming in an upcoming release' for a while now, because there was a
patch and it appeared to have been accepted into the codebase, but I'm very
disturbed to find out thats not the case.
Comment 53 discoleo 2008-09-09 20:06:17 UTC
The "evil alternative", IF you are referring to MS Office, doesn't do it at all
under some circumstances. I do have access only to Office XP at home, and cannot
test it today on Office Vista, but these are my findings:

1.) merge some cells, e.g. A1:D2
2.) enter some text
3.) enter some text into F1:F2

A.) MOVING
4.) select column F
5.) move over merged area
=> ERROR: Cannot change part of a merged cell.

B.) COPY/PASTE
4.) select column F
5.) COPY
6.) PASTE over column B
7.) content is pasted outside of merged cells
    BUT NOT inside the merged cells
=> NOT necessarily what the user wants
[Also, NO notification to the user that something went wrong.]

C.) CUT/PASTE
4.) select column F
5.) CUT
6.) PASTE over column B
7.) "This operation will cause some of the merged cells to unmerge"

I would like to do it better in Calc than in Excel. That is why I started the
discussion.

I do not want i.) to unmerge cells, or ii.) to loose content. I hope everyone
agrees.
Comment 54 bsector 2008-09-25 17:17:47 UTC
Who could tell in the version of OOO we fix this?
Comment 55 yak777 2008-10-21 09:46:37 UTC
Version 3.01 can include fix of this issue?
Comment 56 tanstaafl 2008-10-21 12:20:33 UTC
I absolutely agree that data loss should never happen, and at worst, if a
condition exists that would result in data loss is encountered, an appropriate
error should be provided.

I also agree that, if possible, the calc implementation should be better, if
there are limitations in the way Excel does it that can be addressed...

But, regardless of making it 'better', we need basic functionality *now*.

I am already fighting what appears to be a losing battle with the management
here to roll out MSO for everyone. The only real reason they haven't done so yet
is the cost... but the louder the users yell about 'Office can do all these
things that OOo can't!', the less of a reason the cost becomes.

This issue is one of the biggest complaints we have right now about Calc...

And now I have to contend with the TOTAL loss of any way to manage file
associations (admittedly this is an admin (meaning, MINE) problem rather than an
end user problem, but it is a serious one...
Comment 57 frank 2008-11-07 10:06:15 UTC
*** Issue 95936 has been marked as a duplicate of this issue. ***
Comment 58 ajbwork 2008-11-07 13:33:36 UTC
If you have merged cells spanning columns you cannot insert a new column unless 
you unmerge the cells first.

For instance say you have 4 cells merged (A1, B1, C1, & D1) and you need to add 
a new column between columns B & C you cannot unless you unmerge the cells 
mentioned.

This is a definite limitation and needs addressed. Excel has let you inert 
columns between merged cells as far back as at least 97. 

I have recently switched my office over to OpenOffice 3 from MS Office 2000 and 
have been getting this complaint often.
Comment 59 yonggang.mao 2008-12-06 07:25:55 UTC
Accepted
Comment 60 yonggang.mao 2008-12-06 07:26:27 UTC
Accepted
Comment 61 yak777 2009-01-11 20:29:01 UTC
Extension CalcEasyToolbar can able to insert into the middle of merged cells.
http://extensions.services.openoffice.org/project/CalcEasyToolbar

Comment 62 az77 2009-01-12 01:51:51 UTC
I think being able to insert into a block of merged cells is an excellent idea.
(It removes a major inconvenience associated with merged cells)

The idea of deletion across merged cells is potentially hazardous.
If that is allowed, there must be controls (confirmation, etc) to ensure no
unwanted loss of data.
Maybe allow deletion across merged cells if the data in the region being deleted
has already been deleted.  (Making deletion a two-step process -- still much
faster, and easier to maintain the merged areas than unmerging/remerging.
Comment 63 yonggang.mao 2009-02-13 08:27:26 UTC
Created attachment 60136 [details]
The patch file is about i8302#-Insertcells_v1
Comment 64 niklas.nebel 2009-02-17 18:32:13 UTC
Some notes on the last patch:
- That's a lot of code and handling of different cases. Is all of that necessary?
- Finding the merged cells is slow (about 1 second) if a whole row is selected.
- The "Undo" call at the end restores only the first merge range if cells can't
be inserted.
Comment 65 yonggang.mao 2009-02-19 09:09:21 UTC
Accepted
Comment 66 mloiseleur 2009-02-19 10:19:17 UTC
Hi maoyg,

   I have been finally unable to build a 3.1 version of OOo. And your patch
works really well. I am able to insert rows/columns, even partial rows/columns
in the spreadsheet in issue 8300 without any hitch.
   I really hope you can push it upstream.

Regards,
Comment 67 Rainer Bielefeld 2009-02-21 11:45:52 UTC
*** Issue 99444 has been marked as a duplicate of this issue. ***
Comment 68 yonggang.mao 2009-02-26 15:40:34 UTC
I have tested some problems from my first patch,for example,the merged cells 
is from B2:D2,B3:D3,B4:D4 etc...,when I selected C column,click Insert 
Columns,the merged cells will be cancelled,the first patch still exist some 
potential problems,I will update the patch file about Insertcells later,I hope 
you can test it,because the merged cell's accomplishment is very complicated,
if there are any problems for the patch,please tell me. thanks! :)
Comment 69 yonggang.mao 2009-03-02 07:04:41 UTC
Created attachment 60572 [details]
The patch file is about i8302#-Insertcells_v2
Comment 70 yonggang.mao 2009-03-02 15:06:04 UTC
Created attachment 60598 [details]
Update the patch about v2.
Comment 71 yonggang.mao 2009-03-03 04:06:44 UTC
Created attachment 60626 [details]
Update the patch again.
Comment 72 yonggang.mao 2009-03-03 04:11:39 UTC
Hi Niklas,
I have deleted some reduplicate code.
Comment 73 yonggang.mao 2009-03-06 08:21:22 UTC
Created attachment 60771 [details]
The patch file is about i8302#-v3.
Comment 74 yonggang.mao 2009-03-06 08:23:16 UTC
Thanks for lvyue's help.
Comment 75 norbert2 2009-03-06 08:31:09 UTC
Please adjust summary to:
"allow to insert/delete into/from the middle of merged cells"
Comment 76 niklas.nebel 2009-03-10 15:46:33 UTC
maoyg, you said that deleting rows is slow with the patch. I don't see that. For
me it works well.
Comment 77 niklas.nebel 2009-03-10 18:41:20 UTC
The problem with "redo" if you delete the first row of a merged cell existed
before. It can be fixed in the undo action with a small additional patch.
Comment 78 niklas.nebel 2009-03-10 18:43:11 UTC
Created attachment 60872 [details]
Additional patch for the undo action
Comment 79 yonggang.mao 2009-03-11 05:17:22 UTC
Thanks for Niklas's guidance. :)
Comment 80 niklas.nebel 2009-03-12 10:07:06 UTC
taking the issue
Comment 81 niklas.nebel 2009-03-12 10:09:47 UTC
I added the patch to CWS "calc49".
Comment 82 niklas.nebel 2009-04-03 08:58:32 UTC
reassigning to QA for verification
Comment 83 yonggang.mao 2009-04-28 03:49:40 UTC
*** Issue 94024 has been marked as a duplicate of this issue. ***
Comment 84 yonggang.mao 2009-04-28 03:56:33 UTC
*** Issue 8363 has been marked as a duplicate of this issue. ***
Comment 85 oc 2009-05-14 08:57:22 UTC
Created attachment 62257 [details]
TestCaseSpecification
Comment 86 oc 2009-05-14 09:04:24 UTC
verified in internal build cws_calc49
Comment 87 amy2008 2009-06-01 07:08:40 UTC
Verified in DEV300m49 on WinXP. Works well
Closing
Comment 88 tanstaafl 2009-06-02 15:35:31 UTC
So.... does this mean that this feature will definitely be available in 3.2?

Thanks for getting this done! It is/was uncomfortably close to a showstopper for
us...
Comment 89 sgautier.ooo 2009-06-30 10:08:22 UTC
*** Issue 103195 has been marked as a duplicate of this issue. ***
Comment 90 Regina Henschel 2009-08-22 16:56:49 UTC
*** Issue 104426 has been marked as a duplicate of this issue. ***
Comment 91 hagar_de_lest 2010-02-26 17:33:48 UTC
To all voters: don't forget to report your votes to other issues since this one
is fixed!
Comment 92 Rainer Bielefeld 2014-05-20 17:29:19 UTC
*** Issue 104325 has been marked as a duplicate of this issue. ***