Aha, now we know that the reason for the defensive programming
in lcl_AssureFieldMarksSet() was that there are actually 2
different use-cases for it: usually a new mark is inserted,
so there are no dummy characters and they must be inserted.
However when copying text, the dummy characters are copied too,
so they must not be inserted, or we get duplicate fieldmarks.
This also reverts commit d4036d3a89
which fixed the problem only for CHECKBOX_FIELDMARK in a
different way.
(regression from bb069fe7b8)
Change-Id: I3c99b8c6d720951655198e682018794337859373
The code in DelFullPara() returns early if it can't move the rPam
out of the to-be-deleted paragraph, but it only checks that the point
of the rPam is outside; it then rather pointlessly assigns the 0
index in the node where the mark is, which leaves the mark on the
to-be-deleted paragraph.
In this modern day and age, after much technological progress,
DeleteMark() actually does unregister its SwIndex, so just do that.
Change-Id: Ia1643cf0b976857809ee4130efdec37ce831fdef
Range annotations are represented by a SwPostItField at the end of the
annotated range, and a AnnotationMark that covers the range (including
the field).
During a normal delete, SwUndoDelete calls
SwUndoSaveContent::DelContentIndex(), which has a special case to remove
the AnnotationMark if the field is deleted.
The problem is that when change tracking is enabled, the AnnotationMark
survives, but the field is moved out of the paragraph when the redlines
are hidden (as happens during ODF export), hence
lcl_FillAnnotationStartArray() doesn't find its field.
There doesn't appear to be a good solution to this, because in ODF it's
also not possible to represent this, because the deleted content is
outside the text:p element.
It doesn't work to delete the annotation mark in DelBookmarks(), when
hiding the redline, because then no Undo is created to restore
the mark, and DelBookmarks() is also called from Undo code from
SwUndoDelete, which breaks with this change.
So delete the annotation mark when creating the redline in
DocumentContentOperationsManager::DeleteAndJoinWithRedlineImpl().
Fixes the assert and the subsequent crash, which is a regression
from 31c54fa7bb.
Change-Id: I361ffee8e6ab86de499c25f34a96ceeaf83d9e0b
When showing the redlines in rhbz908615-13.odt, the following assertion
happens:
Assertion `IDocumentMarkAccess::IsLegalPaMForCrossRefHeadingBookmark(rPaM) && "<CrossRefBookmark::CrossRefBookmark(..)>" "- creation of cross-reference bookmark with an illegal PaM that does not expand over exactly one whole paragraph."' failed.
This is because in DocumentContentOperationsManager::MoveRange() the
flag bNullContent is set after the node has been split; in this case the
nContent is of course always 0.
Later the function then restores aSavePam to the index 0 of the next
node, when it actually shouldn't do anything because the JoinNext()
already positioned it correctly at the merge-index of the re-joined node.
(regression from 850795942b)
Change-Id: I64d50e70b19e2fd81537a9771fa8706898b17642
The code assumes that if it can move the cursor backward in line 2038,
that move can be "inverted" by moving the cursor forward after the
content has been moved - but if the cursor moved back a node, and the
moved content does not start with a SwTextNode, the cursor will move
forward skipping over the non-text nodes, so offsets in the aSaveBkmks
(and aSaveRedl, presumably) are going to be wrong.
Just don't use Move() if it leaves the current node.
Change-Id: I95278a10c14aeba9f76558486bb2712f6726dbcb
...with the aid of an extended compilerplugins/clang/store/sfxitemsetrewrite.cxx
(which in turn needed a small addition to compilerplugins/clang/check.hxx).
Enable svl::detail::validGap check for the static case, but keep it disabled for
now for the dynamic case.
Change-Id: I4846ba8e99aff94a86518e2cb5044e575093386e
This is a follow-up to 45a7f5b62d "Keep WID ranges
sorted, and join adjacent ones". While SfxItemSet::MergeRange relies on the
m_pWhichRanges being sorted (and, under DBG_UTIL, asserts if they are not), the
various SfxItemSet constructors curiously only check (via assert or DBG_ASSERT)
that each individual range has an upper bound not smaller than its lower bound.
Arguably, all SfxItemSet instances should fulfill the stronger guarantees
required and checked by MergeRange.
And in many cases the ranges are statically known, so that the checking can
happen at compile time. Therefore, replace the two SfxItemSet ctors taking
explicit ranges with two other ctors that actually do proper checking. The
(templated) overload taking an svl::Items struct should be used in all cases
where the range values are statically known at compile time, while the overload
taking a std::initializer_list<Pair> is for the remaining cases (that can only
do runtime checking via assert). Most of those latter cases are simple cases
with a single range covering a single item, but a few are more complex.
(At least some of the uses of the existing SfxItemSet overload taking a
const sal_uInt16* pWhichPairTable
can probably also be strengthened, but that is left for another day.)
This commit is the first in a series of two. Apart from the manual changes to
compilerplugins/clang/store/sfxitemsetrewrite.cxx, include/svl/itemset.hxx, and
svl/source/items/itemset.cxx, it only consists of automatic rewriting of the
relevant SfxItemSet ctor calls (plus a few required manual fixes, see next).
But it does not yet check that the individual ranges are properly sorted (see
the TODO in svl::detail::validGap). That check will be enabled, and the ensuing
manual fixes will be made in a follow-up commit, to reduce the likelyhood of
accidents.
There were three cases of necessary manual intervention:
* sw/source/core/unocore/unostyle.cxx uses eAtr of enum type RES_FRMATR in
braced-init-list syntax now, so needs explicit narrowing conversion to
sal_uInt16.
* In sw/source/uibase/uiview/formatclipboard.cxx, the trailiing comma in the
definition of macro FORMAT_PAINTBRUSH_FRAME_IDS needed to be removed manually.
* In svx/source/svdraw/svdoashp.cxx, svx/source/svdraw/svdotext.cxx,
sw/source/uibase/app/docstyle.cxx, sw/source/uibase/shells/frmsh.cxx,
sw/source/uibase/shells/grfsh.cxx, and sw/source/uibase/shells/textsh1.cxx,
some comments had to be put back (see "TODO: the replaced range can contain
relevant comments" in compilerplugins/clang/store/sfxitemsetrewrite.cxx).
A few uses of the variadic form erroneously used nullptr instead of 0 for
termination. But this should have been harmless even if promoted std::nullptr_t
is larger than promoted sal_uInt16, assuming that the part of the nullptr value
that was interpreted as sal_uInt16/promoted int was all-zero bits. Similarly,
some uses made the harmless error of using 0L instead of 0.
Change-Id: I2afea97282803cb311b9321a99bb627520ef5e35
Reviewed-on: https://gerrit.libreoffice.org/38861
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
...from 9ca8a63fff "Use consistent integer types
in the SwRedlineTable interface". This all started as an attempt to reduce the
number of places a to-be-committed improved loplugin:loopvartoosmall complains
about. Lets see where it ends...
SwRedlineTable::size_type is now the size_type of the underlying std::vector, no
longer sal_uInt16 from ancient times. I tried hard to find all places that are
affected by this change, changing types of affected variables and non-static
data members as needed. Some notes:
* The original code used USHRT_MAX as a "not found" value. I replaced that with
a new SwRedlineTable::npos, of type SwRedlineTable::size_type but still for
now of value USHRT_MAX. This should eventually be changed to something more
sensible, like std::numeric_limits<SwRedlineTable::size_type>::max() (which is
best done after we have constexpr support in all toolchains, so that npos can
be constexpr). It is important that the value of npos is towards positive
infinity, as many places in the code use
for (i = f(); // may return npos
i < table.size(); ++i)
table[i] ...
* There are some borders where values of SwRedlineTable::size_type are converted
into different types, for various reasons. But all of those other types
should be large enough for practical purposes (at least 32 bits wide):
MakrEntry::m_nIdx: long int
SvxRedlinTable::InsertEntry: sal_uIntPtr nPos
SwRangeRedline: size_t
SwRedlineItr: sal_Int32
SwVbaRevision::GetPosition: sal_Int32
SwXRedlines: sal_Int32
* .uno:TrackedChangeIndex= transports textual representations of such values.
libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx treats them purely as
strings, while SwTiledRenderingTest converts them to int.
* TODO: The one place I'm unsure about is SfxUInt16Items with IDs
FN_REDLINE_ACCEPT_DIRECT, FN_REDLINE_REJECT_DIRECT, and FN_REDLINE_NEXT_CHANGE
in sw/source/uibase/uiview/view2.cxx. For now, I kept those as
SfxUInt16Items and take care to "map" USHRT_MAX to npos when reading from
those items. But I have no idea where instances of those items would actually
be created, and what it would mean to change those items' types?
Change-Id: Ib7a14dc67e2b970766966e43f4732abd9f045ff8
Reviewed-on: https://gerrit.libreoffice.org/34775
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
including fixing a bug in SwXMLExport::exportDoc where it was ORing with
a constant from a different type: nsRedlineType_t::REDLINE_INSERT
Change-Id: I2bb154c9a35d106e64fd1a8b6e928d0384c9fafe
This patch was created using a script
Variable name textual alignment is preserved to the same level
Change-Id: I6b4858f8059b8cf71fc253e87d6df634362d62e9
Reviewed-on: https://gerrit.libreoffice.org/26306
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Replaces the defensive programming band-aid of
5c1a1d1c66 with a real fix.
The problem is that lcl_NonCopyCount() has some special case code
to ignore the first node in the target document, which erroneously is
executed for every bookmark, which results in the 2 bookmarks in the
bugdoc being created with nDelCount 1 and 2 so they land on the same
node, which is not allowed for cross-reference marks.
Extract the adjustment into a separate function that is called once.
(regression from 689962feae)
Change-Id: Ie14c650f7fdb259c13cb9048226da30971d2ab3c
SplitNode() inserts new node before the existing one, so pEndTextNd and
aRg.aEnd point one node too far.
Change-Id: I6cea44fafd9d2b47e77e76892a260c5a8c6849fc
In copy/paste ignore the page break attribute from the first paragraph
of the document (see also tdf#39400)
Change-Id: I838c21c14647d4692673bd30df320e6704de1455
Reviewed-on: https://gerrit.libreoffice.org/22270
Reviewed-by: Oliver Specht <oliver.specht@cib.de>
Tested-by: Oliver Specht <oliver.specht@cib.de>
