Bug 39212

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.

I observed the problem using LibreOffice 3.4.1 on Windows. I'll check on Ubuntu over the weekend.

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).

(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 ?

.

@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 ?

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?!

@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?

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?

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?

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????

Please do not use https://www.libreoffice.org/bugzilla/*, use https://bugs.freedesktop.org/* URLs instead..
Thanks

Florian R.

(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?

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?

** 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

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 :) ?