Currently the anchored object stays with the empty paragraph if enter
is inserted at the beginning of paragraph. It would be better if the
anchored object moves down in this case.
Change-Id: Iacefd9b2de33522158f155fb7035f1640e8eefe1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112738
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
because it wasn't quite there yet - now checks for casts with and
without const, because const doesn't really matter here.
Change-Id: I319025b2095a803fcaad2a7a696d2730b7fd2f81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112098
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This is a follow-up to 7ab349296d.
The first problem was that tables that contain protected cells refused
to be deleted, which caused an infinite loop in
SwXTextRange::DeleteAndInsert().
This also affected SwXTextTable::dispose(), and DDE tables.
Fix this by forcibly deleting even protected cells from UNO APIs;
protection is an UI feature.
The second problem was that pasting the table SwFEShell::Paste() would
set up aCpyPam so that it selects from the start node of the table to
the last text node in the table, excluding the table cell and table end
nodes, which caused:
DocumentContentOperationsManager.cxx:3548: An insufficient number of nodes were copied!
Fix this by setting up aCpyPam over the entire body section of the
clipboard document.
Change-Id: I8c6caee5e75260dff79f106efc11f9669feddc0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110411
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
This is similar to disabling bullets for a paragraph, but in this case
the text nodes are deleted as well.
It seems to me that both invalidations are only useful in the numberging
(e.g. Arabic) case, and not in the bullet case.
Change-Id: Ie03e2847e5e50d9464399f4ea0840910e43a663a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110240
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
- only very few classes (SwNode, SwFormat) are the "owners"
of SwBorderAttrs in the SwCache
- this bookkeeping should not be in such a fundamental class of writer
- also: encapsulate most of the interaction with the cache in the new
sw::BorderCacheOwner. This is mostly to protect the innocent user:
* As interacting with the SwCache directly is very errorprone, because
its glorious idea of using void* of the "owners" as keys to the
entries.
* In C++, reinterpret_cast<void*>(this) might be different along the
class heirachy. This might easily slip under the radar of a casual
user.
Change-Id: I0da774b47885abf52f63aab8d93ebbf41dcf8040
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110112
Tested-by: Jenkins
Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
emscripten clang fails with:
sc/source/core/data/attarray.cxx:378:44: \
error: call to member function 'erase' is ambiguous
aNewCondFormatData.erase(nIndex);
~~~~~~~~~~~~~~~~~~~^~~~~
include/o3tl/sorted_vector.hxx:86:15: note: candidate function
size_type erase( const Value& x )
^
include/o3tl/sorted_vector.hxx:97:10: note: candidate function
void erase( size_t index )
This looks like a compiler error, but if the vector contained
size_t values, this would also be ambiguous to begin with. So
this just renames erase(size_t) to erase_at.
And instead of a 2nd find in the failing code, after copying
the vector, it mow uses std::distance to remove the item.
Change-Id: I7d03ff32352a1890cc01ca241452c0f00d6a9302
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108212
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The problem is that SwTextNode::CopyCollFormat() both creates the
SwTextFormatColl with undo and applies it with undo.
The first is desirable, the second causes a problem because it
necessarily happens after SplitNode() and currently happens before
copying the non-start/end nodes, so the node-index may not match in
Undo, regardless if it runs before or after SwUndoCpyDoc.
But SwUndoInserts restores the SwTextFormatColl on the node itself,
so it can just be suppressed, which looks easier than refactoring this
to call SplitNode() with Undo enabled.
(regression from b4365b9851)
Change-Id: I4d15fb88cd5ae4cc53d9afb3397dec8fcf7635fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107921
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
- This ancient piece of code managed to stack premature optimization on
premature optimization all the while obfuscating the intend pretty
well.
- It also ultimately resulted in a pessimization, e.g. when a
SwSectionFormat is found first, in which case GetSection() is called,
which starts a new loop from the start.
Change-Id: I8e33b3bc592740d7d144e7d4463eb62b27bc8fe4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106327
Tested-by: Jenkins
Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
This is only for the 64-bit windows platform.
I don't see the point in messing with the 32-bit platforms, they are
(a) become more and more rare
(b) unlikely to even have enough available process memory to load extremely large calc spreadsheets
The primary problem we are addressing here is bringing
Windows-64bit up to same capability as Linux-64bit when it
comes to handling very large spreadsheets,
which is caused by things like tools::Rectangle using "long",
which means that all the work done to make Libreoffice on 64-bit
Linux capable of loading large spreadsheets is useless on Windows,
where long is 32-bit.
The operator<< for tools::Rectangle needs to be inside
the tools namespace because of an interaction with the cppunit
printing template stuff that I don't understand.
SalPoint changed to use sal_Int32, since it needs to be
the same definition as the Windows POINT structure.
Change-Id: Iab6f1af88847b6c8d46995e8ceda3f82b6722ff7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This was always a problem, but now more visible since commit
8b3c861c46 (tdf#89991 DOCX: import Show
changes from older formats, 2019-06-13), as it now affects more
documents: tracked changes can be hidden by the time the initial layout
is created.
With that aside, the immediate problem is an assertion failure in
InsertCnt_(), because it assumes that an end node for a section has to
have a matching pActualSection, created by start node of the same
section. This will fail in case the start node is hidden, but not the
end node.
The deeper problem is that redlines are not supposed to cross section
boundaries: if e.g. multiple cells are selected in a table and the user
deletes while tracking changes, then the UI creates multiple redlines
instead. The problem here is similar: a delete redline ends right
before the section start, so when SwNodes::InsertTextSection() inserts a
section node, the end of that redline is automatically moved to the
start of the section content (its index increases, the actual SwNode
doesn't change).
Fix the problem by explicitly checking for a redline end at ToX start and
moving it back to the end of last content node. This matches the doc
model produced by the WW8 import.
Change-Id: Ic7b279185a20d2a32abd054d3fc6be530ddde12a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105412
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
only remaining uses are:
- in calbck.{c,h}xx
- in uwriter unittests
- as a parameter of SwClientNotify
all other uses have been replaced with sw::BroadcastingModify, which
contains sw::BroadcastingMixin functionality. Existing code should then
be moved to sw::BroadcastingMixin (only) as soon as possible.
Change-Id: Ief7895597633c2fcb97e1cbc182905d75feb1567
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105320
Tested-by: Jenkins
Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
- also: introduce SwFormat::RemoveAllUnos() as a member function,
because that is where this belongs ...
- ... and then also use it elsewhere if possible.
Change-Id: I9cc073a41ef1077429f648309806fa433bdcec99
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105173
Tested-by: Jenkins
Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
The old SwClient/SwModify combo is a questionable implementation of the
observer pattern (among other things). The one thing the observer
pattern is good for is dependency inversion: The creator of the message
does not need to know the type of the receiver. Calling the message
handling on the receiver directly introduces tight coupling and entirely
defeats the purpose, leaving us with the worst of both worlds.
In such case, at least be honest about the tight coupling and call a
somewhat more explicit member function of the target.
Thus introduce SwFootNoteInfo::UpdateFormatOrAttr,
SwContentNode::UpdateAttr, remove some useless SwFormatChg clutter in
Set{Foot,End}NodeInfo, and check for some invariants in
SwContentNode::SwClientNotify to limit some of the "a message are two
void pointers" madness.
Change-Id: I32a8d6973231bb5f65c9e144be72d5bcf98f3f44
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105104
Tested-by: Jenkins
Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
in places where it is obvious we only need a sal_Int32, because
we are dealing with rows and columns, and not even calc needs
more than 32 bits for that.
Change-Id: I114417e639c224d45bfd9fc6838122ab195eefa3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104584
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
... delete frames with utmost prejudice - the code that was checking
for empty frames or cells was going into infinite loop because
first the *outer* section is moved to the undo nodes array, then when
the *inner* (index header) section is moved, its section node's
m_pStartOfSection points to the section node that is already in
undo nodes array and so SwNodes::GoPrevSection() goes very wrong
and CheckNodesRange() is called with positions in 2 different arrays.
(regression from a60dd9ef13)
Change-Id: I5682ebc2081ffc7dc49a9c43e613f72c26e93673
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101755
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Gabor Kelemen