Bug 54552 - EDITING: Cell used in a formula is considered non-empty
Summary: EDITING: Cell used in a formula is considered non-empty
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.0.0.beta1
Hardware: All All
: medium major
Assignee: Markus Mohrhard
URL:
Whiteboard: BSA target:3.7.0 target:3.6.3
Keywords: regression
Depends on:
Blocks: mab3.6
  Show dependency treegraph
 
Reported: 2012-09-05 12:27 UTC by pierre-yves samyn
Modified: 2013-04-26 01:12 UTC (History)
3 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 pierre-yves samyn 2012-09-05 12:27:58 UTC
Hello

Steps to reproduce:
1. File> New> Spreadsheet
2. In A1, type =C3<Enter>

Expected & Actual result : A1 displays 0 (C3 is empty)

3. <Ctrl><End>

Expected result : A1 selected (last cell used)
Actual result : C3 selected

Regression

Platform: Version 3.6.1.2 (Build ID: e29a214) & Windows XP

Reproduced (fr-discuss) with same build & Win7 64b 

Regards
Pierre-Yves
Comment 1 Jean-Baptiste Faure 2012-09-06 04:19:50 UTC
I reproduce the described behavior, but I am not sure that it is not intended because it allows to know all cells which are involved in the current sheet.

@Kohei: please, can you confirm if this behavior is intended or not?

Best regards. JBF
Comment 2 Kohei Yoshida 2012-09-06 05:19:41 UTC
This is very much intended behavior.
Comment 3 Kohei Yoshida 2012-09-06 05:24:27 UTC
Actually wait, I misunderstood the description.  I would have expected the end of the data to be A1 in this case.  This is odd.
Comment 4 Kohei Yoshida 2012-09-06 05:25:39 UTC
And this is a regression since which version?
Comment 5 pierre-yves samyn 2012-09-06 06:35:32 UTC
(In reply to comment #3)
> I would have expected the end of the data to be A1 in this case. 

+1

If it was a new feature that would undermine all applications using the method gotoEndOfUsedArea

Please also look at the bug 54553 appears to be a direct consequence of this one.

(In reply to comment #4)
> And this is a regression since which version?

I do not know for sure but with version 3.5.0rc1 (nothing currently available for testing) the result is the expected one (A1 end of data).

Regards
Pierre-Yves
Comment 6 Jean-Baptiste Faure 2012-09-22 10:37:22 UTC
(In reply to comment #4)
> And this is a regression since which version?

LO 3.5.7.1 gives the expected result: A1 selected instead of C3.

Problem seems not to be connected to bug 54553. In LO 3.6.3.0+ (Build ID: 9d3af8d) bug 54553 is fixed and this one not.

Status set to new.

Best regards. JBF
Comment 7 Jean-Baptiste Faure 2012-10-06 12:08:05 UTC
Added regression keyword, accordingly to comment #4

Best regards. JBF
Comment 8 pierre-yves samyn 2012-10-06 12:36:21 UTC
Hello

This bug could seem minor in the interface (user's keystroke <Ctrl><End>
and the cursor can go "further" than the last input cell) but IMHO it is
very inconvenient for applications : many (most) of them use
the gotoEndOfUsedArea method whose result is not the same !

Regards
Pierre-Yves
Comment 9 pierre-yves samyn 2012-10-07 06:16:11 UTC
May be related to Bug 55712
Comment 10 Not Assigned 2012-10-17 13:56:13 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=40377a6e26aa61a1c0788cad1c97a10911d38da8

only use non blank cells in the visible data methods, fdo#54552



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 11 Not Assigned 2012-10-19 08:50:26 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=23e6bac62ef6482c287bb0f55c662ac2047ebb33&g=libreoffice-3-6

only use non blank cells in the visible data methods, fdo#54552


It will be available in LibreOffice 3.6.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 12 Not Assigned 2012-10-22 13:56:03 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-3-6-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c38b67a171615ddc444e0fe849e10d7cada74b6a&g=libreoffice-3-6-3

only use non blank cells in the visible data methods, fdo#54552


It will be available already in LibreOffice 3.6.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 13 pierre-yves samyn 2012-10-27 04:50:04 UTC
Hello

Verified as fixed with Version 3.6.4.0+ (Build ID: b1f308d) and Windows 7 64bits

Thank you very much :)

Regards
Pierre-Yves
Comment 14 Jean-Baptiste Faure 2012-10-28 20:53:53 UTC
Verified in LO 3.6.3.2

Thank you.
Comment 15 Joel Madero 2013-04-26 01:12:50 UTC
As part of our regular FDO management we are going back and checking regression versions to see earliest version we can confirm problem. I have been able to confirm this regression on:

Version 3.6.0.0.beta1

Changing version to reflect this