Issue 59745 - Cell notes do not move when cells are sorted in Calc
Summary: Cell notes do not move when cells are sorted in Calc
Alias: None
Product: Calc
Classification: Application
Component: ui (show other issues)
Version: OOo 2.0.1
Hardware: All All
: P3 Trivial with 40 votes (vote)
Target Milestone: ---
Assignee: oc
QA Contact: issues@sc
Keywords: oooqa, regression, usability
: 67076 72872 75478 76735 80174 (view as issue list)
Depends on:
Reported: 2005-12-24 22:37 UTC by bdimm
Modified: 2013-08-07 15:14 UTC (History)
18 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

Demonstrates the problem. Column A is before sort (notes on A2 and A101). Column C is after sort. (8.77 KB, application/vnd.oasis.opendocument.spreadsheet)
2006-01-01 21:17 UTC, bdimm
no flags Details
Image was made from two screenshots. In OOo 1.1.5 notes are placed near to the corresponding cells. (32.45 KB, image/png)
2007-12-29 10:11 UTC, dma2002
no flags Details
A way to fix this issue, but don't know whether it will lead any problem. If so, let me know please. (3.17 KB, text/plain)
2008-05-08 09:53 UTC, yun_jt
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description bdimm 2005-12-24 22:37:40 UTC
If you sort a bunch of cells, the position of the notes for those cells does not
change, which can leave the notes very far from the cells that they describe
(maybe not even on the same screen) with very long arrows.

I would suggest moving the notes so that their position relative to the cells
they describe is preserved during the sort (with some adjustment to avoid having
any notes move off of the edge of the spreadsheet).  This approach may be
imperfect, but the current approach is very annoying if the region being sorted
is large.
Comment 1 lars 2005-12-31 21:49:04 UTC
for me the notes are moved with the cells when using Data->Sort...
can you give a step-by-step description?
Comment 2 bdimm 2006-01-01 21:17:39 UTC
Created attachment 32819 [details]
Demonstrates the problem.  Column A is before sort (notes on A2 and A101).  Column C is after sort.
Comment 3 bdimm 2006-01-01 21:21:44 UTC
I've added an attachment that demonstrates the problem (before and after sort).
 I simply created a column full of numbers ranging from 100 down to 1.  I then
put a note on the first and last cell.  I copied the A column to the C column,
selected cells C2-C101, and did an ascending sort (which flips the rows -- top
moves to bottom an vice versa).  If you hold your mouse over cell C2, the arrow
for the note points all the way down to around row 101.
Comment 4 lars 2006-01-01 21:53:55 UTC
confirmed on Windows XP Pro SP2 with OOo 2.0.1: the note fields seem to stay in 
place of their original creation thus the arrow pointing from the note field to 
a new note (mark) position can be very long.
Comment 5 frank 2006-01-31 14:44:29 UTC

not a bug but an enhancement.

Comment 6 cianoz 2006-02-02 10:10:21 UTC
I do not agree that this is not a bug, but just a enhancement, if you work with
a large amount of data/rows the use of notes become pratically unusable. It's
very different from a simple "annoying" issue, it's a real problem.

As many other features or issues, this one is not very relevant if you use OOo
at home or for non critical jobs, but if you intend to promote OOo as a real
alternative for Office use this has to be considered important.
I spent a lot of time in my organization in creating spreadsheets that work with
large amount of data and are frequently sorted, or have rows inserted or deleted.
We are used to WORK with OOo, not to use it for the books and movie collections!

I want to guess that this would be fixex very soon.
Comment 7 glumelle 2006-03-03 06:51:21 UTC
Hi! I'm new around. I have this very boring problem of having all my notes 
showing themselves but in the window I'm looking in after a sorting. 
Everything is alike as described.
fst wrote down that it is an it a joke or not? If yes, could 
you explain why and what can be done to settle the notes where they can be 
viewed without spending the rest of the day to move them around.
Thank you.
Comment 8 avagula 2006-04-12 12:29:14 UTC
Can please someone set this back to DEFECT?
Comment 9 cianoz 2006-04-12 13:52:40 UTC
I agree with Vagula, this is definitively a DEFECT, or if you prefer, a bug.
It's not possible to work with Calc if you are used to make large use of cell
notes in the way that Calc currently handles them.
Please do something !
Comment 10 bdimm 2006-04-12 14:37:37 UTC
This probably goes without saying, but I agree with everyone here that is asking
this to be classified as a DEFECT rather than an ENHANCEMENT.  Of course, I
probably wouldn't have gone to the trouble of submitting this bug if I didn't
find it to be a huge pain in the neck.  The OOo definition for defect says:
"Defect is a problem with an existing feature that is either not developed to
spec or does not work as designed."  OOo 1.1.4 did not have this problem (I just
checked), so OOo 2 is either off spec (hence a defect), or the spec changed in a
retarded way, or the spec was too ambiguous to prohibit behavior that makes calc
unusable.  Any way you look at it, something that used to work well now works
badly.  It should be fixed.
Comment 11 frank 2006-07-13 09:17:37 UTC
*** Issue 67076 has been marked as a duplicate of this issue. ***
Comment 12 frank 2006-07-14 14:38:18 UTC

it's an enhancement as it is not specified that the note position on a sort has
to change too. But it's specified that the note position and size has to be
saved. So it's clearly an enhancement even if you think it's a defect.

Comment 13 cianoz 2006-07-14 17:39:51 UTC
I was used to hear these magic words from Micro$oft... "this is not a bug, it's
a feature"; it looks like here we're going to something similar now, just a
little different.

Maybe tomorrow another version of OOo will write only lowercase and someone will
tell us "writing also uppercase is not a defect, it's an enhancement..., we're
considering for future versions"

Meanwhile some M$ Office users are laughing about this...
Comment 14 glumelle 2006-07-15 08:30:14 UTC
Hi! Frank,
With all my respect, your kind of logic scares me a bit. It seems that many of 
us don't understand it. I guess when we do a sorting of a group of cells, 
those with attached note, have their note following them, not left behind. 
Saving the position and the size of the note, doesn't make the note follow the 
cell when it is moved around. Lets see it from a practical point of view: 
enhancement or not, in fact, the result is : it's not working properly, 
period. It's so disturbing for me that I'm figuring out to stop converting to 
calc. Thanks anyway.
P.s. May I suggest, should you consider asking to one of your colleages if his 
logic fits yours.
Comment 15 frank 2006-07-17 08:20:11 UTC
Be sure this is discussed with development before set to enhancement.
Comment 16 cianoz 2006-10-13 08:09:44 UTC
This bug still occurs in OOo v.2.0.4
Will it ever be considered or it will be remain a P99 priority ?
It is an *important* feature for who use OOo in enterprise environment.
What we have to do to make this be comprehended by (you) develepers ?
Comment 17 cianoz 2006-12-13 15:16:44 UTC
Problem still persists in OOo 2.1.0.
Will it never be solved ?
Comment 18 glumelle 2006-12-13 19:43:29 UTC

Eric Belley wrote:
> Hi,
> The issue 59745 has been classified as enhancement. Many people 
> disagree with that decision and the problem is a real one when we use 
> calc with many notes and we have to sort the sheet.

Si cela a été classé comme un amélioration c'est que le développement 
n'avait pas prévu de traiter les notes lors d'un tri, cela n'en est pour 
antant pas moins génant. Le fait que cela soit classé comme une 
amélioration ne dit pas cependant que cela ne sera pas intégré à une 
prochaine version. Nous intégrons de nouvelles fonctionnalités tous les 
6 mois.
> Is there a council to review a decision about an issue or is the 
> decision final forever?

La décision est prise par le développeur de la fonctionnalité. Le 
community council ne statue pas sur cela.
> Would you be kind enough to take a look at this and inform me about 
> what options we have in such a case.

Les moyens de faire que cette fonctionnalité soit développée sont les 
suivants :

- amener un nombre de votes suffisant pour que des ressources soient 
allouées plus rapidement
- amener des ressources pour que ce développement soit réalisé.

Remettre un développement qu'il soit correction de bug ou amélioration 
ne se fait jamais de façon légère.
Nos ressources sont limitées et nous essayons de les répartir au mieux. 
Certaines issues ont plus de votes que celle-ci mais ne sont pas pour 
autant traitées plus vites car soit elles nécessitent de gros 
développement, soit d'autres développements sont plus importants.

Sophie Gautier
Responsable du projet francophone
Membre du Community Council
Comment 19 frank 2007-01-16 15:06:56 UTC
*** Issue 72872 has been marked as a duplicate of this issue. ***
Comment 20 kpalagin 2007-03-21 20:25:22 UTC
*** Issue 75478 has been marked as a duplicate of this issue. ***
Comment 21 jamescrompton 2007-05-15 19:17:55 UTC
This is a defect. Any sensible interpretation of the 'position' of a note *to a
cell* will take it as indicating the position of the note *relative to the
cell*. This is not currently preserved, which makes notes unusable under normal
operating conditions.
Comment 22 kpalagin 2007-06-02 13:34:49 UTC
*** Issue 76735 has been marked as a duplicate of this issue. ***
Comment 23 pmike 2007-06-22 10:46:23 UTC
Hi, Frank
Please consider re-scheduling this RFE to milestone 2.3 or at least 2.4
Reason: there is no workaround for this issue, even with macros.
Comment 24 frank 2007-07-30 12:53:38 UTC
*** Issue 80174 has been marked as a duplicate of this issue. ***
Comment 25 gunyball 2007-07-30 13:22:53 UTC
totaly agry with most of you - its a defect
its sad, to see this issue opened for almost 3 years ;(
Comment 26 gunyball 2007-07-30 13:24:53 UTC
in some cases this problem makes OpenOffice totally unusable ;(
Comment 27 undecidable 2007-12-17 05:32:52 UTC
A comment on the bug,
 issues this bug causes, 
and a workaround that works 
(with some issues)
but breaks my mother's heart when I use it.

1.  It is the same issue as 80174, 63671, 67076 and 61253
where the same thing happens on adding rows/cols, resizing rows etc.  
Notes are being tied to an absolute position 
(that of a particular cell that was once-upon-a-time near the 'noted' cell )
rather than a position always relative to the 'noted' cell.

2.  It is especially egregious for finance and accounting use.
For example, at the beginning of every year finance people may add 14 more
columns (12 new months, year and budget)
to large spreadsheets.   Almost all cells have notes 
and all notes are effectively lost as they are so far off screen they are not

For this reason I am casting 3 of the 5 votes I was given on registering,
for this bug.  

3.  A workaround:
(which feels a bit like mentioning the name of Lord Voldemoort
and offered slightly tongue-in-cheek), is:
before adding rows or columns,
close the spreadsheet, open it in Excel,
add the rows or columns in Excel, then close it again and continue work in OOO.  
Notes are handled properly,
ie positioned relative to the 'noted' cell, in Excel.

It is not perfect, as not all formats are transcribed perfectly,
but it is better than losing access to the notes.  
Of course if you don't have access to excel...

4.  The argument above that this bug is really an 'enhancement'
because the present behavior is as per specification
is simply an argument that the bug is in the specification
not in the coding.  

I think both specification and coding issues ought be addressed here. 
Comment 28 undecidable 2007-12-19 09:47:22 UTC
A Real Workaround!
(& excellent repair!)

Copy / pasting the affected cells, even in situ repairs the position of the notes. 
(Moving the cells does the same).

Method 1 - Fine
So after inserting/deleting the new rows/columns, the notes are all in the wrong
place.  Select the cells affected by the insertion (eg all cells below the new
lines inserted) do a control-C followed by a control-V, which copies and pastes
the cells in situ (in their places).  The notes are now where they should be.  

Method 2 - Gross
For large sheets, you can just select the whole sheet (click on the top left
corner of the sheet) and do the same control-C followed by a control-V, which
copies and pastes the whole sheet in situ.

copy/paste and move handle note positions correctly,
insert/delete rows/columns, sorting etc do not. 
I have only verified this in 2.3.1. 

If I had found this repair years ago my children would not know so many curse

Hope this is helpful to some other irritated souls!
Comment 29 gunyball 2007-12-19 10:52:58 UTC
copy/paste solution is a great solution, but (!) after the use of copy/paste
method you get the wrong size (heigth and width) of note in the right place.. 

verified on OOO 2.1
Comment 30 undecidable 2007-12-20 07:50:26 UTC
Agree.  That appears to be a bug in copy/paste that happens whether the cells
are being pasted to the same place or not, and is independent of the bug under
discussion here.   For me, at least in 2.3.1, the new size of the note after
copy/paste is still acceptable.  

In fact this issue is filed as bugs 64665 and 50266, and is classified as
"Defect".  Yet this much more serious (and painful) 59745 is classified as

It is this great variety of the human intellect that makes us such an
interesting species.  
Comment 31 dma2002 2007-12-29 10:07:32 UTC
Dear developers!

I've opened this file on OOo 1.1.5 and I've seen, that the notes are placed
correctly (screenshot attached). Therefore I mean, that it isn't an RFE, but a
DEFECT and regression too.
Comment 32 dma2002 2007-12-29 10:11:07 UTC
Created attachment 50598 [details]
Image was made from two screenshots. In OOo 1.1.5 notes are placed near to the corresponding cells.
Comment 33 kpalagin 2007-12-29 10:28:46 UTC
are we really on track for 2.x with this issue?
Please do not simply change target as cell notes is usefull feature and it is 
important for the note to keep it's relative position. And with our growing 
installed base the number of suffering users grows by days.

Importance of this RFE (it's reallly a bug, even if classified otherwise) 
illustrated by 37 votes, 4 duplicates and also

Thanks a lot for your effort.
K. Palagin.

P.S. Based on DMA's finding I set keyword regression.
P.P.S. The fact that 1.1.5 is able to display notes correctly tell me that 
this issue is cosmetic by nature and would not require too much development 
Comment 34 adamspiers 2008-01-01 19:58:24 UTC
I agree with the other commenters that this is definitely a bug not an enhancement.
Comment 35 Martin Hollmichel 2008-01-22 07:49:39 UTC
move target from 2.x to 3.0
Comment 36 pmike 2008-02-28 06:32:02 UTC
Can I ask about status of this issue?
There is a lot of negative feedback from end users about currently annoying
behavior of notes in Calc.
Comment 37 canis 2008-03-25 20:22:08 UTC
Dear developers!
There is a little time to fix all the issues set fot 3.0.
I wonder if you draw attention at this issue - it's realy annoying.
Thank you!
Comment 38 mark_hof 2008-03-25 22:14:31 UTC
is this bug gonna be fixed in the 3rd version of OOo?
Comment 39 undecidable 2008-03-30 09:54:54 UTC
I wouldn't be optimistic:

a.  The announcements for v3 focus on featuritis, rather than fixing things that
don't work.  

b.  I get the sense that the person responsible for notes doesn't actually use
them.  Notes are the buggiest feature in Calc - they lose position, they lose
size, they disappear if they lose focus before you enter data, etc.  

c.  It is still marked as "enhancement" despite:
   (i)   working properly in Excel, Gnumeric and KSpread, and even earlier
versions of OOO.  The only place Notes don't work is OOO. 
  (ii)  It has 7 separate bugs filed, all related to the same issue (59745 +
64665, 50266, 80174, 63671, 67076, 61253) & numerous duplicates (72872, 75478,

d.  Finally, it is not marked as started - still marked as "new", despite being
opened in 2005.  
Comment 40 cianoz 2008-04-17 10:01:08 UTC
It's really hard to accept such a resistance from developers to understand that
this is a BUG that really needs to be solved. Latest posts here summarize a
clear annoyance by many people and it's really incredible that a BUG (IT'S A
BUG!) like this has been snubbed by developers for more than 2 years!
Undecidable's post summarizes perfectly the situation, in a very clear way.

I am a user and a supporter of OOo since beginning of the project mainly in 
office/enterprise environment. These kind of things are those that make all care
and effort to make OOo well accepted at work very hard.

Do you know what it means to have people at work (not-at-home), mabye your boss,
telling you: "Why the hell you have made me to compile my 1000 rows spreadsheet
with this Now i have all my notes lost around the sheet! Repair
it, right now!"
Comment 41 yun_jt 2008-05-08 09:53:38 UTC
Created attachment 53475 [details]
A way to fix this issue, but don't know whether it will lead any problem. If so, let me know please.
Comment 42 kpalagin 2008-05-13 12:06:59 UTC

To all developers,
please see if this patch is OK.
Comment 43 kyoshida 2008-05-14 00:44:36 UTC
Hey yun_jt,

I've tested your patch, and it seems to work pretty well.  There are two things
I need to mention about your patch:

1) I had trouble applying it (the 2nd hunk failed).  It would help to make sure
the patch applies against a reasonably recent milestone.

2) We have switched to using whitespace for indentation, so all new lines should
use whitespace, instead of tab characters.

But these are minor cosmetic issues.  Otherwise the patch looks good.  You did a
great job on that.
Comment 44 frank.loehmann 2008-05-22 09:33:21 UTC
This issue is important and listed on the quarterly review for Calc:
Comment 45 kpalagin 2008-05-29 07:33:19 UTC
Shall we fix integration issues and get this patch into master please?
Thanks a lot!
Comment 46 kpalagin 2008-06-04 11:13:09 UTC
could you, please, enlighten us why this highly voted regression with patch is 
retargeted? I mean beyond usual "not enough time|resources"?
Comment 47 daniel.rentz 2008-06-04 11:16:29 UTC
by error...
Comment 48 daniel.rentz 2008-06-04 14:14:01 UTC
DR->JUN_JT: the patch does not take horizontal sorting into account (sort by
columns, see second tab page in Sort dialog). There, visible notes become
invisible, and the position of the notes does not change. Therefore, due to the
near deadline for OOo 3.0 code changes, this issue is retargeted to OOo 3.1 again.
Comment 49 mikerutter 2008-06-11 14:20:54 UTC
the whole issue of note positions is a big setback for any business users using
calc for any kind of finance applications, or document registers.  You just HAVE
to be able to see your notes on the same page (not 200 rows away) if you have
sorted or filtered a list or it is pretty unusable.  I was considering filing an
issue for the same symptom when you use the Autofilter (notes stay where they
were relative to the corner of the sheet, not to the cell they relate to) but as
this is almost certainly a duplicate.

I think the whole "defect" or "enhancement" argument raging across this issue is
a little unhelpful.  It is an important usability feature that is missing from
Calc that "just works" in  almost all other apps.

Speaking from 3 years battling for the adoption of in a small
group of companies, this particular point is a major p.i.t.a. for a number of
key users.

If anyone can tell me if and how to raise this as an issue that might be acted
upon instead of argued over (and no, I don't have the time or skillsets to fix
it myself - sorry all you coders out there) I'll gladly post it in the right place.
Comment 50 lead_pipe 2008-06-16 19:16:36 UTC
I don't see why this is considered an enhancement.  Why would anybody want to
put notes on a cell, then after the cell moves to another position (insertions,
deletions, hide) the note does not move?  

How about a compromise?  Give the user some type of option of the note to remain
in it's absolute position or let its position stay relative to cell.  
Comment 51 kpalagin 2008-06-18 04:41:10 UTC
please review comments from dr Wed Jun 4 13:14:01 +0000 2008 and see if you 
can fix the problem he refers to.

Thanks a lot for your effort.
With best regards,
K. Palagin.
Comment 52 kyoshida 2008-09-03 20:10:55 UTC
The last two if statements in the patch causes a crash if the sort range
includes empty cells.

Is this line in the first if statement

  if(pCell1 && pCell2->GetNote(aCellNote) && aCellNote.IsShown())

meant to be this line instead by any chance?

  if(pCell2 && pCell2->GetNote(aCellNote) && aCellNote.IsShown())

(and the same for the second if stament?)

If I swap those pCell1/pCell2 in those if statements, it will still appear to
work (still only vertically though) and will not cause a crash with a range with
empty cells.
Comment 53 kyoshida 2008-09-03 20:24:26 UTC
Ah, nevermind, it doesn't work in all cases.  Some notes still don't move with
that change.
Comment 54 daniel.rentz 2008-09-04 07:32:30 UTC
kohei: I didn't use the patch, and already have a working solution for both
sorting directions, with empty cells etc.
Comment 55 kyoshida 2008-09-04 13:47:19 UTC
dr: ah, that's good to know.  Is that gonna make it in for 3.1?
Comment 56 daniel.rentz 2008-09-04 13:53:27 UTC
yes. see CWS dr66 for a collection of issues regarding cell notes...
Comment 57 daniel.rentz 2008-10-15 14:00:06 UTC
fixed in CWS DEV300/dr66 (OOo 3.1)

the following scenarios have been fixed:
- Inplace sorting by columns or by rows (visible and hidden notes are adjusted)
- External sorting (output result to another position) by columns or by rows
(visible and hidden notes are cloned and adjusted)

- Undo of inplace sorting restores old note positions
- Undo of external sorting removes cloned notes

- Redo of inplace sorting restores new note positions

Not fixed: Redo of external sorting inserts two caption objects for the same
note, one is not connected to the cell, will write another issue, once the OOo
website is up

As a side effect, the following scenario has been fixed too:
- Create data range to be sorted, insert a drawing object (e.g. rectangle)
completely inside
- Sort to another position
- Undo
Old behaviour: Undo will not remove the inserted drawing object (and redo
inserts a new copy above the old object). Now fixed: all drawing objects are
correctly removed in undo.
Comment 58 kpalagin 2008-10-16 08:07:34 UTC
Thank you very much!!!!
Comment 59 daniel.rentz 2008-10-16 08:26:19 UTC
For the records: see issue 94976 for the external sort redo problem.
Comment 60 Joe Smith 2008-11-03 18:05:17 UTC
This problem does not seem to affect OOo 2.4.2--at least the sample document no
longer shows the problem.

Surprising, since the fix here is targeted for 3.1 and not shown as integrated yet.
Comment 61 daniel.rentz 2008-11-06 16:35:49 UTC
has been fixed with another (Sun-internal) issue for 2.4.2
Comment 62 daniel.rentz 2008-12-04 16:37:45 UTC
back to QA
Comment 63 oc 2009-01-16 12:30:32 UTC
verified in internal build cws_locales30
Comment 64 oc 2009-01-16 12:32:51 UTC
cws_dr66 of course 
Comment 65 vladimir_hitekschool 2009-04-01 00:58:14 UTC
Issue 59745 has been fixed in master version OOo-dev 3.1 .0 (OOO310m7 
Build:9393) for Windows XP and can be closed.
Comment 66 oleghitekschool 2009-04-01 05:34:55 UTC
Checked and closed by HitekSchool Group 1 as a part of Issue Hunting Party 
regression check.
Comment 67 burgwinkel 2010-03-16 21:59:47 UTC
Unfortunately, this issue remains an impediment on my system.  All new notes are
located (and point to a cell) 11 rows above their target cell.  Former fixes
involved copying the entire sheet and pasting it in place.  This no longer works.  

I suspect this particular spreadsheet (originally created in OOo 2.1) may be
perpetuating this annoyance beyond its fix in OOo 3.1.  If so, rebuilding it
from scratch in 3.1 might work. But it might not, and this spreadsheet is too
big to rebuild without a certainty of improvement. 

Just wanted to let you know that this little 'offset-note' annoyance is
continuing into the second decade of the second millennium.

System info:
Linux joesbox 2.6.28-16-generic #57-Ubuntu SMP Wed Nov 11 09:49:32 UTC 2009
x86_64 GNU/Linux

OpenOffice version: 3.1.1
OOO310m 19 (Build:9420)

(.deb) package version
1:3.1.1-5ubuntu1.1 (karmic-updates)