[Libreoffice-bugs] [Bug 122232] UI: Pressing Enter in a protected sheet doesn't jump to next row in every case

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=122232

--- Comment #4 from Gerhard Weydt <gerhard.weydt at t-online.de> ---
Created attachment 147790
  --> https://bugs.documentfoundation.org/attachment.cgi?id=147790&action=edit
Test Doc where the protected cells are to the left

After confirming that I also think that the described behaviour is a bug (and
it's still present in 6.2.0.1), I want to describe what I think is the intended
behaviour in simpler situations, which I indeed think is helpful when filling 
many rows of similar data, which might be deemed the most frequent case.
if you start from a cell, only entering data and then going to the next cell
using Tab, then using Enter will position the cell cursor in the next row and
in the column of the cell this sequence started with. I cannot tell exactly
which actions break this sequence, but clicking in a cell and changing data
does, for example.
Now the problem in the present case obviously lies in the fact that some cells
are protected. It is now more difficult to identify the cell to jump to. It
seems that up to 6.0 Calc first selected the column to jump to and then
selected the fist cell below the starting point which is not protected. (for
the moment I call this choice 1)
Starting somewhere with 6.1. the behavious changes, as described in the bug.
One could assume that it now first looks for the next unprotected cell in the
current column (where Enter was pressed) and the goes to the start column (taht
would be called choice 2). If it were so, this would have corrected a wrong
behaviour in 6.0 (and probably in former releases too) which you can test in
the attachment "reverseExample.odt" (protected cells are also yellow): if
C7:D10 are protected and you enter data in the sequence C6 -> D6 -> G6 and then
use Enter, then the cursor is in the protected cell D7.
Unfortunately, this is not the case. The same still happens in 6.2.0.1. So it
is not the case that one error was corrected by creating another, but the
situation now is worse than before: both test cases now are wrongly handled,
whereas only one was beforehand.
Although the present situation is doubtlessly worse than the one before and
should therefore be changed, it does not seem clear to me how a complete
solution could look like. Even choice 1 and choice 2 seem to be contradictory
solutions, each one fitted for one type of constellations, and combinations of
protected/unprotected cells more difficult are conceivable. If, for example
choice 1 is used and jumps to a cell which is protected, a human being would
look for the next unprotected cell to the right _which will be needed_. But
this cannot be detected by the program: it selected the first cell of the new
row simply because it was the first in the previous row, I assume, and I also
assume that the intermittent columns used in the previous row are not available
to the program. So I cannot propose a consistent way for the determination of
the jump target in the general case of protected cells.
By the way: is there another jump direction in Calc for languages that write
from right to left or top-down? That would make the problem even more
complicate (although not necessarily more difficult, as a solution could
probably be transposed).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20181223/20af1a2a/attachment-0001.html>