diff options
| author | Justin Luth <justin_luth@sil.org> | 2016-11-08 11:33:02 +0300 |
|---|---|---|
| committer | Michael Stahl <mstahl@redhat.com> | 2016-11-10 14:24:35 +0000 |
| commit | 70f41634d085aecc8e90dfba034bb367341d142e (patch) | |
| tree | 72846423e423feea35a342259268c257157e9c46 /sw | |
| parent | bec9e673ad37e86cbc86d0ed844340ab080a7c5f (diff) | |
tdf#67379 - sw: treat clicking h/f-fly the same as any other
Why should clicking on a frame/image in a header act any differently from
a one insde the text body?
(The only time frames (or any kind of fly) required a double click occured
when switching from inside a header to a body-fly or from inside the body
to a h/f-fly. This patch removes that oddball corner-case.)
Now all frames are handled with a single click and there will not be
an impact on double-clicking anymore.
regression caused by 7e2f98d0a0c4a0f36a94353a256e7cc5caa3113b and its
prior commit which say:
> Header/Footer: fixed click on frames over the header/footer area.
> The main problem here was due to the click to show the separator when
> there is no header or footer under the frame. That code was just exiting
> MouseButtonDown too early, which isn't good.
> Now, double-click actually selects a frame anchored in header/footer.
confirmed that single-clicking on frames over the header/footer section
still shows the header blue-line.
Change-Id: I4770cfe7898202929742743931e22de8bf233b03
Reviewed-on: https://gerrit.libreoffice.org/30693
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Diffstat (limited to 'sw')
| -rw-r--r-- | sw/source/uibase/docvw/edtwin.cxx | 17 |
1 files changed, 2 insertions, 15 deletions
diff --git a/sw/source/uibase/docvw/edtwin.cxx b/sw/source/uibase/docvw/edtwin.cxx index 5b450303a053..68b2c69df57e 100644 --- a/sw/source/uibase/docvw/edtwin.cxx +++ b/sw/source/uibase/docvw/edtwin.cxx @@ -2855,7 +2855,6 @@ void SwEditWin::MouseButtonDown(const MouseEvent& _rMEvt) const Point aDocPos( PixelToLogic( rMEvt.GetPosPixel() ) ); - // How many clicks do we need to select a fly frame? FrameControlType eControl; bool bOverFly = false; bool bPageAnchored = false; @@ -2866,16 +2865,6 @@ void SwEditWin::MouseButtonDown(const MouseEvent& _rMEvt) // We have a field here, that should have priority over header/footer fly. bOverHeaderFooterFly = false; - int nNbFlyClicks = 1; - // !bOverHeaderFooterFly doesn't mean we have a frame to select - if ( !bPageAnchored && ( ( rSh.IsHeaderFooterEdit( ) && !bOverHeaderFooterFly && bOverFly ) || - ( !rSh.IsHeaderFooterEdit( ) && bOverHeaderFooterFly ) ) ) - { - nNbFlyClicks = 2; - if ( _rMEvt.GetClicks( ) < nNbFlyClicks ) - return; - } - // Are we clicking on a blank header/footer area? if ( IsInHeaderFooter( aDocPos, eControl ) || bOverHeaderFooterFly ) { @@ -3211,10 +3200,8 @@ void SwEditWin::MouseButtonDown(const MouseEvent& _rMEvt) } } - bool bHandledFlyClick = false; - if (!bExecDrawTextLink && nNumberOfClicks == nNbFlyClicks) + if (1 == nNumberOfClicks && !bExecDrawTextLink) { - bHandledFlyClick = true; // only try to select frame, if pointer already was // switched accordingly if ( m_aActHitType != SdrHitKind::NONE && !rSh.IsSelFrameMode() && @@ -3339,7 +3326,7 @@ void SwEditWin::MouseButtonDown(const MouseEvent& _rMEvt) case 2: { g_bFrameDrag = false; - if ( !bHandledFlyClick && !bIsDocReadOnly && rSh.IsInsideSelectedObj(aDocPos) && + if ( !bIsDocReadOnly && rSh.IsInsideSelectedObj(aDocPos) && FlyProtectFlags::NONE == rSh.IsSelObjProtected( FlyProtectFlags::Content|FlyProtectFlags::Parent ) ) { /* This is no good: on the one hand GetSelectionType is used as flag field |