Download it now!
Bug 39212 - Loss of OpenOffice default behavior for copying formulas EDITING
Summary: Loss of OpenOffice default behavior for copying formulas EDITING
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.4.4 release
Hardware: x86-64 (AMD64) Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: target:4.2.0
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-13 16:21 UTC by Rmax
Modified: 2015-01-06 16:07 UTC (History)
6 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 Rmax 2011-07-13 16:21:21 UTC
In earlier versions of LibreOffice, you could use the range of an adjacent column to copy a range of formulas, using SHIFT and CTRL-down.

Example of earlier correct behavior in LibreOffice 3.3.2: you have a range of values in A1:A1000. You wish to copy a formula (any formula) from B1 to B2:B1000. You copy the formula in B1 using CTRL-C, then move the cursor to B2, press SHIFT and (keeping SHIFT depressed), move the cursor to the left using the left arrow, then pressing CTRL-down. The range extends automatically to the cell A1000. You move the cursor (still depressing SHIFT) to B1000 using the right arrow key, then press CTRL-V to copy the formula. This behavior was highly useful for effortlessly copying formulas in large spreadsheets.

This desirable behavior no longer works in LibreOffice 3.4.1

Instead, there is a slavish devotion to the way MS Excel works, which requires manually extending the range in B2 using the mouse or repeatedly pressing the down arrow. This is a real pain in large spreadsheets. (Try it).

I tried enabling OpenOffice.org legacy behavior from the Tools/Optins/LibreOffice Calc/Compatibility menu to no avail. The irritating MS Excel-like behavior continued.

!!!THIS IS REALLY AGGRAVATING TO A LONG-TERM OOo/LibreOffice USER!!! and makes LibreOffice just as useless for serious spreadsheet work as MS Excel. 

This is a MAJOR inconvenience. Please restore the previous functionality for copying using adjacent columns in LibreOffice 3.4.2
Comment 1 Jeffrey 2011-07-14 22:01:10 UTC
Failed to reproduce on LibreOffice 3.4  340m1(Build:103) for OpenSuse Linux.

I opened LO calc and the SHIFT+CTRL+DOWN functionality works. However, when I try to copy a formula through such a large number of cells, LO hangs. But I would just like to point out that the functionality for effortlessly selecting cells work.
Comment 2 Rmax 2011-07-15 07:17:42 UTC
I observed the problem using LibreOffice 3.4.1 on Windows. I'll check on Ubuntu over the weekend.
Comment 3 Lorieul 2011-10-14 05:26:11 UTC
I also found that bug on my computer (LO3.4.3, Ubuntu 11.04 , Gnome 2.31)

Note that not only "Ctrl+Arrowkey" does not behave properly but "Ctrl+Arrowkey" does not work either (when editing a formula).
Comment 4 Lorieul 2011-10-14 05:28:02 UTC
(In reply to comment #1)
> Failed to reproduce on LibreOffice 3.4  340m1(Build:103) for OpenSuse Linux.
> 
> I opened LO calc and the SHIFT+CTRL+DOWN functionality works. However, when I
> try to copy a formula through such a large number of cells, LO hangs. But I
> would just like to point out that the functionality for effortlessly selecting
> cells work.

The "Crtl+ArrowKey" command works well except when used while editing a formula.
Did you try the "Crtl+ArrowKey" function when editing a formula ?
Comment 5 Cor Nouws 2011-10-14 08:40:24 UTC
.
Comment 6 Lorieul 2011-10-21 08:50:35 UTC
@Cor Nouws
Does "." in your last comment (2011-10-14 08:40:24 PDT) means the bug was solved ?
The bug status is still "NEW" isn't it ?
Or does it mean enough information has been collected and no more comment should be added ?
Comment 7 Rainer Bielefeld Retired 2011-11-05 12:07:57 UTC
Reported effects are more or less reproducible with "LibreOffice 3.4.4RC2  - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:402)]". 

We have a changed behavior in 3.4 compared to 3.3 (an OOo), but I doubt that it's a bug.

I compared behavior of this version, OOo 3.1.1, "LibreOffice Portable 3.3.0  - WIN7  Home Premium (64bit) German UI [OOO330m19 (Build:6 Tag 3.3.0.4)]", Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID:  d3d1481-3f8994a-2ba0a9f)]" (110909). Master seems to behave as 3.4.

The first test with OOo 3.1.1


a) Tests with OOo, Steps to reproduce:

0. Preparations: Open new spreadsheet, type an "x" to A10, B11, C12, E14, F5, F6

11. Click A1
12. <Shift+4x-arrowright>   
   (A1:A5 highlighted)
13. <Control+arrowdown>
   Cursor jumps to E14, what SEEMS in accordance with Help for that version: 
    "...Moves the cursor to the bottom of the current data range". E14 is the
    most bottom cell containing data, empty column D will be ignored, what 
    is a good solution, a jump to the bottom of the table is useless

14. Redo from 1, but with selected A1:F1
   Now cursor will move to F5, that's not something with "Data Range", but 
   simply the FIRST next cell containing Data below cursor. I would have 
   expected cursor jumping to F14 of at least F5

New test with OOo 3.1.1
21. Click A1
22. <Shift+4x-arrowright>   
   (A1:A5 highlighted)
23. <Shift+Control+arrowdown>   Instep 3 marked range A1:E14, 
   Cursor jumps to E14, A1:E14 selcted / highlighted, Cell Cursor E14
   what SEEMS in accordance with Help for that version: 
    "...Moves the cursor to the end of the current data range containig data". 
    E14 is the
    most bottom cell containing data, empty column D will be ignored, what 
    is a good solution, a jump to the bottom of the table is useless

24. Redo from 21, but with selected F1:A1
    F1:A10 will become marked, I would have expected F1:A14, because Row 14 is
    the last one containing data.

New test with OOo 3.1.1
31. Click E1
32.  <Shift+4x-arrowleft>   
   (A5:A1 highlighted)
33. <Control+arrowdown>
    Cursor Jumps to 'A10'. I would have expected A14 (Data Range), but cursor
    simply jumps to the next cell containing data.
34. Redo from 31, but with selected F1:A1
    F1:A10 will become marked, I would have expected F1:A14, because Row 14 is
    the last one containing data. But not unexpeced after 21ff



b) LibO 3.3.3
b1) Tests 11ff
b1a)  In step 13 jumps to A14: SEEMS Correct "End of range", but why column A?
b1b   In step 14 jumps to A5, means target column = where range started in 
      step 11 
      target Row = the one of cell cursor position

b2) Tests 21ff
b2a) In step 23 marked range A1:E14, expected after b1, Cell cursor A1
b2b) Step 24 marked A1F5, expected after b1, b2a

b3) Tests 31ff
b3a) In step 33 marked range A1:E14, expected after b1, Cell cursor A1
b3b) Step 34 marked A1F10, expected after tests b

c) LibO 3.4.4
c1) Tests 11ff
c1a)  In step 13 jumps to A10: Here Target row is defined in start range
      column, not in end range column, behavior different to OOo, LibO333
c1b   In step 14 jumps to A10,  Here Target row is defined in start range
      column, not in end range column, behavior different to OOo, LibO333
      target Row = the one of cell cursor position

c2) Tests 21ff
c2a) In step 23 marked range A1:E10, expected after c1, Cell cursor A1
c2b) Step 24 marked A1F10, expected after c1,
     behavior different to OOo, LibO333

c3) Tests 31ff
c3a) In step 33 marked range A1:E14, expected after b1, Cell cursor A1
     behavior different to OOo, LibO333
c3b) Step 34 marked A1:F5, expected after tests c
     behavior different to OOo, LibO333

   
My conclusions
--------------

OOo3.1.1
<Control+arrow> always reaches the next cell with contents in arrow direction from the current Cell Cursor. Useful in many cases, but IMHO not really consequent.

LibO 3.3.3
<Control+arrow> always reaches the next cell with contents in arrow direction from the current Cell Cursor (as OOo). 
For Down-Example reached Column differs from OOo, not below cell cursor, but below begin of marked start range.
Useful in many cases, but IMHO not really consequent.

LibO 3.3.4
<Control+arrow> always reaches the next cell with contents in arrow direction from the START OF MARKED CELL RANGE. Differs from OOo and LibO333
For Down-Example reached Column differs from OOo, not below cell cursor, but below begin of marked start range.

IMHO hehavior is not consistent in all cases

I would prefer 
a solution that for our <Control+Arrowdown> Example, the most bottom line with contents will be reached


@Lorieul
In OOo Bugzilla it was not possible only to add oneself to CC, it was necessary to write a comment. Most of us have been used to comment a simple dot if nothing was to say.

@Rmax
Instead of mournful "EXCEL slavery" comments you should write down exact descriptions of your observation. "No longer works" is not a good description. Knowing all that behavior it's easy to find workarounds for your needs, for example 
40. goto B2, <control+c>
41. <Control+Arrowdown> from A1 to A100
42. <arrowright> reaches B1000
43. <shift+control+arrowup> marks B1000:B1
44. <control+click> unselects B1 (not necessary)
45. <control+v> will paste formulas to B2:B1000.
    A little more work than with LibO333, but not terrible

50. or simpliy use the scroll slider? Mark and fill down?Faster and more secure than all other soulutions.

60. or if you do not want to use the mouse:
61.  goto B2, <control+c>
62. <Control+Arrowdown> from A1 to A1000
63. <arrowright> reaches B1000
64. <shift+control+arrowup> marks B1000:B1
64. <shift+arrowdown>  unselects B1 (not necessary)
65. <control+v> wil paste formulas to B2:B1000.

Comparing number of all key press key release actions between LibO 3.3.3 and LibO 3.4.4 for your example (ontil past completed with<cnotrl+v> :
333: 14
344: 16
That seems not completely inacceptable


@David:
Help for this under "Shortcut Keys for Spreadsheets" is not very precise. For 'Ctrl+Down Arrow' I read: "Moves the cursor to the bottom edge of the current data range" . What ever "THE" current data range might be. I believe it means "Moves the cursor to the last row containing data below the current cursor position or marked cell row"
Additionally all those details I found out nowhere are mentioned , I believe that should be improved in Help and Manual.

@Kohei:
I can't see any reason for urgent action, but currently I believe consistence is not optimum. But of course, there might be lots of cases for other use I did not examine until now?!
Comment 8 von_klatka 2011-12-09 01:47:37 UTC
@Rainer:
I'm sorry but Rmax is right, the new behavior in 3.4 is very annoying and anti-intuitive and it's also present in Ubuntu 11.10. It was so easy to Shift-Arrow to select the adjacent column and use Ctrl-Shift-Arrow to select the range. The new 3.4 behavior is just stupid and a big regression for such a common task in spŕeadsheets. I switched back to 3.3 and will stay there until this issue is solved. Or maybe go back to OpenOffice?
Comment 9 willy.bueno 2012-01-14 05:09:12 UTC
After 4 updates of the 3.4 version still no fix to the bug. I observed this same bug since OOo era sometimes when new version is released but fixed immediately in succeeding maintenance versions. However, it's very disappointing here in LibO this bug is never addressed. I retracted to 3.3.4 every time I try a new version of 3.4 when available because the bug is very annoying especially that I'm working with spreadsheets having thousands of rows. I wonder if it persist in 3.5, any testers here?
Comment 10 willy.bueno 2012-01-14 05:15:52 UTC
After 4 updates of the 3.4 version still no fix to the bug. I observed this same bug since OOo era sometimes when new version is released but fixed immediately in succeeding maintenance versions. However, it's very disappointing here in LibO this bug is never addressed. I retracted to 3.3.4 every time I try a new version of 3.4 when available because the bug is very annoying especially that I'm working with spreadsheets having thousands of rows. I wonder if it persist in 3.5, any testers here?
Comment 11 willy.bueno 2012-03-06 00:07:33 UTC
I can't believe this is defined as a feature rather than a bug in this thread:

https://www.libreoffice.org/bugzilla/show_bug.cgi?id=37230

That the old behavior was actually the bug????
Comment 12 Florian Reisinger 2012-05-19 10:42:04 UTC
Please do not use https://www.libreoffice.org/bugzilla/*, use https://bugs.freedesktop.org/* URLs instead..
Thanks

Florian R.
Comment 13 Cor Nouws 2012-05-24 06:52:12 UTC
(In reply to comment #0)
> This is a MAJOR inconvenience. Please restore the previous functionality for
> copying using adjacent columns in LibreOffice 3.4.2

Sorry I lack time to really dive in all technical issues and variations and what Excel should do when...
It is not as handy as before, but the difference is small, IMO:

Then it would be
  Ctrl+C
  Shft+> 
  Ctrl+Shft+^
  Shft+<
  Ctrl+V

Now it is
  Ctrl+C
  > 
  Ctrl+^
  <
  Ctrl+Shft+v
  Ctrl+V

Gradually I got used to it. It's one key stroke extra, and for people useing key's, that's a fraction of a second?
Comment 14 von_klatka 2012-05-24 08:19:11 UTC
All those who ask "what's the difference?" clearly aren't heavy spreadsheet users. There is a difference and it's a big one. Perhaps someone should decide if Libreoffice aims to be a pretty office suite or a useful one.


(In reply to comment #13)
> (In reply to comment #0)
> > This is a MAJOR inconvenience. Please restore the previous functionality for
> > copying using adjacent columns in LibreOffice 3.4.2
> 
> Sorry I lack time to really dive in all technical issues and variations and
> what Excel should do when...
> It is not as handy as before, but the difference is small, IMO:
> 
> Then it would be
>   Ctrl+C
>   Shft+> 
>   Ctrl+Shft+^
>   Shft+<
>   Ctrl+V
> 
> Now it is
>   Ctrl+C
>   > 
>   Ctrl+^
>   <
>   Ctrl+Shft+v
>   Ctrl+V
> 
> Gradually I got used to it. It's one key stroke extra, and for people useing
> key's, that's a fraction of a second?
Comment 15 QA Administrators 2015-01-05 17:51:11 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice (4.3.5 or later): https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)

Thank you for your help!

-- The LibreOffice QA Team
Comment 16 Cor Nouws 2015-01-05 19:43:11 UTC
Hi,

This has been fixed, by adding ... an extra option :)

Tools > Options > Calc > General.. Use legacy cursor movement behaviour when selecting.

See http://cgit.freedesktop.org/libreoffice/core/commit/?id=462b28770e4fa3dfa6fe4af71a6776cceb4c4640

Since I know the commit, I assume it can be set to fixed :) ?