This is an alternative fix to the bug. The idea is, that we shouldn't
call MoveFwd in SwTabFrame::MakeAll in case of floating tables.
In commit 45574624ff (tdf#120262 sw
floattable: no split when none of first row fits the vert space,
2023-07-19) a code was added, that made sure that for floating tables
MoveFwd was called with bMoveAlways = true. Obviously, for that bug,
this code path was used at that time. However, the unit test for that
but doesn't pass the code path these days.
What happens inside MoveFwd for a floating table is:
1. MoveFwd calls GetLeaf, which in turn calls GetNextFlyLeaf;
2. GetNextFlyLeaf splits the anchor (the new frame isn't yet moved),
and creates a follow fly, which is still on the same page;
3. MoveFwd moves the whole table to the new fly, making the old fly
empty;
4. The old fly calls its DelEmpty, breaking precede/follow chain and
making the new fly standalone.
In the end, the situation after the call is fundamentally the same
as before, with exception of new garbage (empty fly) to clean later,
and the split anchor that needs a join.
This change avoids calling MoveFwd for floating tables in this case.
It keeps all unit tests working, so hopefully this cleanup could be
an improvement by simplifying code, and by avoiding a call to
SwLayouter::InsertMovedFwdFrame, which itself is manual override of
the normal layout process (IMO, the less it's used, the better).
If it turns out problematic, it may be simply reverted (that's the
idea of merging it only after the more conservative fix).
Change-Id: I606976de629bb5514edafd1430704901241876cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198135
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
... after commit c880d2bec8
(Fix some non self contained headers in module sw, 2026-01-25).
The change in sw/inc/ndtxt.hxx created circular dependency:
- sw/source/core/access/parachangetrackinginfo.cxx
- #include <wrong.hxx> (executes #pragma once, will not be included again)
- #include <ndtxt.hxx> (at the beginning of wrong.hxx, only on Windows;
before its classes are read)
- #include "../source/core/inc/wrong.hxx" (ignored because of #pragma once)
- #include "../source/core/inc/SwGrammarMarkUp.hxx" (needs access to
definitions in wrong.hxx, yet unavailable)
Resulting in
C:\lo\core\sw\inc\../source/core/inc/SwGrammarMarkUp.hxx(36): error C2504: 'SwWrongList': base class undefined
C:\lo\core\sw\inc\../source/core/inc/SwGrammarMarkUp.hxx(46): error C3668: 'SwGrammarMarkUp::~SwGrammarMarkUp': method with override specifier 'override' did not override any base class methods
C:\lo\core\sw\inc\../source/core/inc/SwGrammarMarkUp.hxx(47): error C3668: 'SwGrammarMarkUp::Clone': method with override specifier 'override' did not override any base class methods
C:\lo\core\sw\inc\../source/core/inc/SwGrammarMarkUp.hxx(48): error C3668: 'SwGrammarMarkUp::CopyFrom': method with override specifier 'override' did not override any base class methods
C:\lo\core\sw\inc\../source/core/inc/SwGrammarMarkUp.hxx(42): error C2065: 'WRONGLIST_GRAMMAR': undeclared identifier
C:\lo\core\sw\inc\../source/core/inc/SwGrammarMarkUp.hxx(42): error C2614: 'SwGrammarMarkUp': illegal member initialization: 'SwWrongList' is not a base or member
Change-Id: I868902d6d0552832c4db3aefdba8ee76fa19bce1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198124
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
...contrary to what 96cb87ca01 "tdf#146619 Use
more forward declarations in include/vcl/[a-o]" apparently assumed, as seen at
least with recent Clang 23 trunk against recent libstdc++ 16 trunk,
> In file included from vcl/source/window/builder.cxx:14:
> In file included from ~/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/16.0.1/../../../../include/c++/16.0.1/memory:80:
> ~/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/16.0.1/../../../../include/c++/16.0.1/bits/unique_ptr.h:90:16: error: invalid application of 'sizeof' to an incomplete type 'NotebookBarAddonsItem'
> 90 | static_assert(sizeof(_Tp)>0,
> | ^~~~~~~~~~~
> ~/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/16.0.1/../../../../include/c++/16.0.1/bits/unique_ptr.h:398:4: note: in instantiation of member function 'std::default_delete<NotebookBarAddonsItem>::operator()' requested here
> 398 | get_deleter()(std::move(__ptr));
> | ^
> include/vcl/builder.hxx:59:80: note: in instantiation of member function 'std::unique_ptr<NotebookBarAddonsItem>::~unique_ptr' requested here
> 59 | std::unique_ptr<NotebookBarAddonsItem> pNotebookBarAddonsItem = nullptr);
> | ^
> include/vcl/builder.hxx:44:8: note: forward declaration of 'NotebookBarAddonsItem'
> 44 | struct NotebookBarAddonsItem;
> | ^
Change-Id: I81537c4c7f774bb1f9e7e3bdbf85af9786c9e016
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198131
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
The bugdoc has commented text range inside a deletion. The import result
doesn't mark the comment as deleted.
Comments with a single anchor point work fine, since commit
419b70b5d4 (tdf#105485 DOCX: import
deleted comments as deleted, 2019-08-26).
Fix the problem by invoking CheckRedline() in
DomainMapper_Impl::PopAnnotation() in the range case as well, that
correctly creates the delete redline for the comment anchor.
This is shared code for any redlines, so fixes inserts, too.
Change-Id: I620e1419cee79ab729ea7be248f1ad079a9fc536
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198125
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Added handling for the viewAdded and
viewChanged events, which cause navigation bar
icons to change if they don't fit the current
presentation area size.
This handler is only applied when automatic
scaling of the navigation bar is enabled, so it
shouldn't impact performance when the bar isn't
used or a fixed size is selected.
Icon sizes:
XLarge for UHD and above
Large for FHD and up
Small for anything smaller than FHD
Change-Id: I9f6599291d57aca9991c8d2dd2969d1edb36080e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196157
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@collabora.com>
In the specific bug document, some constellation of factors created
the case where the last inner floating table tries to move forward,
in the process creates a split fly on the same page (subject to move
forward later, when outer table formats), moves to it (leaving the
old fly empty), which recreates the same layout as before; and that
oscillated infinitely.
The fix implemented here is to detect when MoveFwd call created the
described situation, and then use SwLayouter::InsertMovedFwdFrame
to break the oscillation.
I was not able to reproduce this problem anew; test document was
simplified from the original, with the aim to minimize instability
(but still, the resulting layout in Writer differs from Word's,
which makes the test likely to stop testing the intended code path
in the future - sigh).
Change-Id: Iaa796a169cb9f97d5a6b3dd7ebf1cf5b726ca568
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198116
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Any variable in too broad scope may cause headaches; but for methods
like SwTabFrame::MakeAll (more than a thousand lines), it easily hits
with "the variable hides earlier one" errors.
Change-Id: I6b8e2137b777698a4f82d1032ceac6daed6a7eba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198117
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
this was skipped in previous runs, since it contains some code behind #if
After inspecting these, it seems like the removals should not cause trouble.
Change-Id: If1e3e3c7c0fc14ed6e8b51174a0e7f1220fdbc8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197496
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
The evaluation of the fooIFS functions attempts to reduce the range to be
examined so that empty cells at the end of a range are not examined. To
do this, it uses the range at the bottom of the parameter stack. That
works well, for example, with SUMIFS and AVERAGEIFS, because this range
does not have an associated criterion, but instead contains the data to
be summed up.
In the case of COUNTIFS, however, all ranges have an associated criterion
and such might query for empty cells. At the point in the process when
the reduction takes place, the criteria are not yet known. Therefore,
when the criteria are later resolved, the reduction is reversed in case
the criterion queries for empty cells.
The evaluation of ranges and criteria starts at the top of the parameter
stack and goes then backwards. That means that the reduction was based
on the range at the bottom of the stack, but the reversal of the
reduction was based on the criterion at the top of the stack.
The solution is to use the range of the parameter at the top of the
stack to calculate the range reduction in the case of the COUNTIFS
function.
Change-Id: Ia451312b83ab73f52020edd204fb2e37997714e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198058
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
This patch replaces the previous one.
It is more generic
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf165359_SdtWithDrawing
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf165359_SdtWithInline
Change-Id: Ic1533a71fbaaaa4e28e7e00976f5c8f747cf2d6b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198049
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Builds on pre-Tahoe macOS versions still render the pre-Tahoe style
so further adjustments are needed when running on macOS Tahoe.
Change-Id: Idef3555680020c1862b8d8c8c8b03a80497050a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197411
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Tested-by: Jenkins
Its only difference from its base is getResult, which also tries
to use IFileOpenDialog::GetSelectedItems/GetResults, which is OK
for folder picker.
Change-Id: I6acbcb64a2de4025dcac8022b26355d6444f5082
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198044
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
C:/lo/core/editeng/qa/unit/core-ttest.cxx(2447): error C2672: 'CppUnit::assertEquals':
no matching overloaded function found
Change-Id: I9ff0a59fc3ee6de00ba3a54442f66feb66a9d25e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198042
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Pressing Cancel in the dialog caused an assert in debug builds:
include/vcl/vclptr.hxx:123: VclPtr<reference_type>::~VclPtr()
[with reference_type = AbstractSwInsertDBColAutoPilot]: Assertion
`(!m_rInnerRef.get() || m_rInnerRef->isDisposed() || m_rInnerRef->getRefCount()
> 1) && "someone forgot to call dispose()"' failed.
After:
commit 137df7cd67
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Wed Jan 31 13:10:52 2024 +0200
make insert-db-col-auto-pilot dialog async
To reach the dialog:
1. Open Writer
2. View - Data Sources (Ctrl+Shift+F4)
3. Expand Bibliography until you see biblio
4. Click on a row indicator to the left of the data
5. Now the "Data to Text" button is enabled, click it
Change-Id: If2c4a1024afec666589b4b4c1932d5a661b964f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198036
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Use less IUnknown::QueryInterface, and more COMReference::QueryInterface.
No need to use COMReference default ctor in member initializers.
Change-Id: I28cd07d16dc294d598580f353a4ec7efe82bc480
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198040
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
1. Avoid explicitly specifying COM_QUERY in calls to QueryInterface
(it is implied from the name).
2. Drop redundant ctor and set() that duplicate QueryInterface.
3. Allow ThrowIfFailed without a message.
Change-Id: I75b545e534efb7e57da131dfd40a2a49d204efac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198033
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
this was skipped in previous runs, since it contains some code behind #if
After inspecting these, it seems like the removals should not cause trouble.
Change-Id: I8b856cbf7ded7c62634286a53f1ef41e99adb286
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197495
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Tor Lillqvist