[Libreoffice-commits] core.git: Branch 'distro/collabora/cp-6.4' - sc/source

[Justin Luth (via logerrit)]

 sc/source/ui/view/tabview3.cxx |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

New commits:
commit 30e4f9ef29e7d1adad59b84902bd53c47a0e54ca
Author:     Justin Luth <justin.luth at collabora.com>
AuthorDate: Sat Nov 7 10:52:24 2020 +0300
Commit:     Marco Cecchetti <marco.cecchetti at collabora.com>
CommitDate: Fri Apr 9 12:13:58 2021 +0200

    tdf#47349 sc ui: bPosVisible only for fully visible
    
    So this is a regression-inviting guess at a wrong impl.
    And I am not a calc guy, so I shouldn't be making this
    kind of a change.
    
    The problem was that editingActive couldn't select
    cells from other sheets for some cells near the
    frozen border. The reason was that multiple splits
    are considered active at the same time, and so the
    editActive can be monkeyed with. Everything is all
    so interconnected that I get rather confused.
    
    This fix does not solve a same problem with a
    true window split, only with a window freeze.
    
    The freeze problem is that the left column was
    looking at the column (outside its view) and asked
    whether it fit inside the start X (0)
    + visible cells +1.
    
    So pretending typical freeze of row 0 and col 0,
    which means left starts at 0 and has 1 visible col.
    Left activates if col is 0, or 1, or 2.
    Since the only possible column in left is 0,
    it should only activate in that case.
    So visible cells should be --, not ++.
    
    Right? Of course, something probably depends on
    the editing view being turned on for partially
    visible cells on the right or bottom side,
    or perhaps even for the first invisible col/row,
    and so this will probably cause a regression.
    
    An alternative would be to -- for the left side
    and ++ for the right side (to increase confusion,
    but decrease regression potential).
    
    Change-Id: I946512bc7b3994f1750527a1a8c55954234b0d69
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105429
    Tested-by: Jenkins
    Reviewed-by: Eike Rathke <erack at redhat.com>
    (cherry picked from commit fed6c4c70da6b35d72b670c8f4d8e866cdac21e4)
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113759
    Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice at gmail.com>
    Reviewed-by: Marco Cecchetti <marco.cecchetti at collabora.com>

diff --git a/sc/source/ui/view/tabview3.cxx b/sc/source/ui/view/tabview3.cxx
index 736d47ace777..1498204de148 100644
--- a/sc/source/ui/view/tabview3.cxx
+++ b/sc/source/ui/view/tabview3.cxx
@@ -2087,8 +2087,8 @@ void ScTabView::MakeEditView( ScEditEngineDefaulter* pEngine, SCCOL nCol, SCROW
             SCROW nScrY = aViewData.GetPosY( eVWhich );
 
             bool bPosVisible =
-                 ( nCol >= nScrX && nCol <= nScrX + aViewData.VisibleCellsX(eHWhich) + 1 &&
-                   nRow >= nScrY && nRow <= nScrY + aViewData.VisibleCellsY(eVWhich) + 1 );
+                 ( nCol >= nScrX && nCol <= nScrX + aViewData.VisibleCellsX(eHWhich) - 1 &&
+                   nRow >= nScrY && nRow <= nScrY + aViewData.VisibleCellsY(eVWhich) - 1 );
 
             //  for the active part, create edit view even if outside the visible area,
             //  so input isn't lost (and the edit view may be scrolled into the visible area)