Bug 131186 - Faulty behavior on Inserting rows/colums in a table by dragging
Summary: Faulty behavior on Inserting rows/colums in a table by dragging
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 131220 (view as bug list)
Depends on:
Blocks: Cell-Formula Cell-Management Drag-and-Drop
  Show dependency treegraph
 
Reported: 2020-03-06 14:13 UTC by Karl
Modified: 2022-09-23 09:12 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
small table with steps to see faulty behavior (9.39 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-03-06 14:14 UTC, Karl
Details
screen shot " inherited from OOo " (72.64 KB, image/png)
2022-09-23 09:06 UTC, Karl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Karl 2020-03-06 14:13:15 UTC
Description:
Dear folks ! 

For example in a small table there are TWO ways of inserting rows:

First : 
One can select a row (on left side the row numbers) and then one can INSERT a (or more) Row by "right clicking the mouse" selecting "Insert Row above".

Second :
With (by) the mouse a part of the table can be market and selectet and then
this selection can be moved (for example) one row down with the same effect to have a row inserted in the partition of the whole sheet

I have figured out, that both modificaton do NOT have the same Results
especially if some cells have a formula inside.

A simple example is attached with descripion in the file to produce.

kind regard




Steps to Reproduce:
1. create coloumn 1,2,3,4,5, sum of this 5 numbers below
2. create coloumn 6,7,8,9,10, sum of this 5 numbers below
3. select 2 to "sum" by mouse, move selection 1 row down
4. repeat 3 to "sum" 


Actual Results:
formula is wrong

Expected Results:
formula is correct


Reproducible: Always


User Profile Reset: No



Additional Info:
dont know
Comment 1 Karl 2020-03-06 14:14:08 UTC
Created attachment 158453 [details]
small table with steps to see faulty behavior
Comment 2 m_a_riosv 2020-03-06 21:57:54 UTC
Repro
Version: 6.4.2.1 (x64)
Build ID: c92dba0b4728c0ec26c4b83e2c0fbf3284425375
CPU threads: 4; OS: Windows 10.0 Build 19569; UI render: GL; VCL: win; 
Locale: es-ES (es_ES); UI-Language: en-US Calc: CL
Second drag of cells shows the misbehavior.

Repro with Aoo 4.1.1
Comment 3 Oliver Brinzing 2020-03-07 09:56:59 UTC
confirming, root cause seems to be:

forumla in C9 =SUM(C3:C8) is not adjusted after drag operation, e.g. after first drag to: =SUM(C3:C9), after secand drag to: =SUMME(C3:C10),...

btw: it works with excel 2016
Comment 4 Karl 2020-03-07 16:38:20 UTC
Hi,

behavior as well on

Version: 6.4.1.2 (x64)
Build-ID: 4d224e95b98b138af42a64d84056446d09082932
CPU-Threads: 4; BS: Windows 10.0 Build 18363; UI-Render: GL; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: CL

regards jürgen
Comment 5 Karl 2020-03-08 10:22:27 UTC
HI,

please read my comment number 2 on BUG 131220

There are some more effects to be seen.

Happening both on ROWS ant COLUMNS too.

regards jürgen
Comment 6 m_a_riosv 2020-03-08 16:35:30 UTC
*** Bug 131220 has been marked as a duplicate of this bug. ***
Comment 7 Karl 2020-03-08 16:55:01 UTC
Hi m.a.riosV

I dont know much about this "bugzilla" !?

The information on the other "dupilcate bug" to which i refer 
here in comment No. 5
-which referrs to bug 131220 comment No 2

should NOT go lost anyway.

May be one of my descriptions of the two bugs shall be copied to another ?

Especially the "re (respective) back - dragging" after inserting rows / columns,
because it "simply" is the other dragging direction 
and incorporates some faults ?!

You or anyone familiar with THIS bugzilla should do what is needed,

i am not.

best regards
jürgen
Comment 8 Karl 2020-03-30 11:50:45 UTC
Hi, as well in

Version: 6.4.2.2 (x64)
Build-ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3
CPU-Threads: 4; BS: Windows 10.0 Build 18363; UI-Render: GL; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: CL

regards jürgen
Comment 9 QA Administrators 2022-09-23 04:31:10 UTC Comment hidden (obsolete)
Comment 10 Karl 2022-09-23 08:40:01 UTC
Hi folks

the described behavior IS STILL PRESENT 

in LO
Version: 7.4.1.2 (x64) / LibreOffice Community
Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL


BEST REGARDS

karl
Comment 11 Karl 2022-09-23 09:06:27 UTC
Created attachment 182642 [details]
screen shot " inherited from OOo "

Hi,

i did a " cross testing " on LO 3.3.0 ( but is x86 version against the x64 version ) i regular use since years.

The behaivior is shown in the screenshotwithj LO Version info.
Comment 12 Karl 2022-09-23 09:07:44 UTC
Hi,

hope, i did understand the mail correctly.

best regards 

karl
Comment 13 Karl 2022-09-23 09:12:16 UTC
HI,

BUT BUT BUT ::

I had to remove LO 7.4 befor installing LO 3.3 !

During installation IT WAS MENTIONED to HAVE A Java Runtime to be installed.

I DID NOT do this ( installing a OLD Java ) !
_____________________________________________

I cannot determine whether this has / had any influence .... ???!!!


REGARDS again

karl