Age | Commit message (Collapse) | Author |
|
This reverts commit 2b5953a19e36a02040f2ff08bc87efe4785f80bd. Whatever that
"gcc4.4 (and 4.3 and possibly older) have a problem with dynamic_cast directly
to the target class" issue actually was: For one, our GCC 7 baseline presumably
would no longer have such an issue. And for another, the added asserts that the
results of the dynamic_casts must be non-null were presumably all bogus (and
have in part been reverted again in the meantime), as all the sources are UNO
interface types that can presumably point at implementation objects of other
than the expected C++ class types. (Those dynamic_casts from UNO interface
types will be addressed in a follow-up commit. See the upcoming commit
introducing loplugin:unocast on why such dynamic_casts are dangerous.)
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
sw/qa/extras/rtfexport/rtfexport.cxx
sw/source/filter/ww8/docxattributeoutput.cxx
sw/source/filter/ww8/rtfattributeoutput.cxx
writerfilter/Library_writerfilter.mk
writerfilter/source/ooxml/OOXMLFastContextHandler.cxx
writerfilter/source/rtftok/rtfdocumentimpl.cxx
Change-Id: I0c330a3541e64ce08bfe30ff15d51a2fd8a243b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144336
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: Ic151fd657cb780291009ee4c9db51a35dfa7f357
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144335
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: Ib681b4eaa44c65b9da5988c74c03f1829e3a1507
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144334
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: I13f71f717a8661e0889ab7acf6fe7c7ebbe3dbe6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144332
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I46c122e800c63038cf7fd650ebb6f0115c6e8c78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144330
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(cherry picked from commit 1257c288a0ba03fc69e7bc29fcf05642eb91d150)
Change-Id: I2cbc0fc18f716bf214db61f0729d666a1d2d172c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144344
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ia6b8599c7ff185d5beecf6572c0df353320d8ebb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144338
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I7b417c64ce08cddc2c413dae3bcab3b9fe083bc6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144337
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Working hypothesis is this happens after a failed spreadsheet
load, or from a race during load.
<crash>
ScModelObj::getPartInfo(int) sc/source/ui/unoobj/docuno.cxx:602
doc_getPartInfo desktop/source/lib/init.cxx:3531
...
KitSocketPoll::kitPoll(int) coolforkit
SvpSalInstance::DoYield(bool, bool) vcl/headless/svpinst.cxx:492
Change-Id: I06870336d4e64ebfc69bce64e280821c25e1b1e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144308
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
* Update helpcontent2 from branch 'master'
to 55f43cd2900eb670bce537a939ea0f435439d926
- tdf#134377 Help page not found when clicking 'Help' button
targeting File/Open help page - on 'Help' button click - for the time being although this is far
from a perfect solution, and while @@widget@@ bookmark does not operate properly.
Change-Id: Id35bb8a6b707cb8376bac7c036aa47ba31aa8f58
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/144356
Tested-by: Jenkins
Reviewed-by: Alain Romedenne <alain.romedenne@libreoffice.org>
|
|
HACK: Adding a subview to an NSView that is not attached
to an NSWindow leads to infinite recursion in the native
NSViewGetVisibleRect() function. This seems to be a new
behavior starting with macOS 12.6.2.
In the case of tdf#146765, we end up here because
-[AquaA11yWrapper childrenAttribute] is called by a
wrapper that is already attached to an NSWindow. That is
normal. What isn't normal is that the child wrapper's
unignored accessible parent is a differnt wrapper than
the caller and that different wrapper is not yet
attached to an NSWindow.
TODO: switch the AquaA11yWrapper class to inherit the
lightweight NSAccessibilityElement class instead of the
NSView class to possibly avoid the need for this hack.
Change-Id: Ic6c2a60e90a154786dd7f5935582ef7d3f57584c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144329
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Boost.Locale since 1.81.0 switch to enum classes for facet type [1].
Switch our resource manager accordingly.
1: https://github.com/boostorg/locale/commit/e5ed439ea39a4de915e9fb939cca95cae7d9d8d1
Change-Id: Ief215363ceb79b2019606b20a7cde55c8df6a042
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143343
Reviewed-by: Heiko Becker <heirecka@exherbo.org>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3b9781cf00df7b740c8b29c6834e54035b255269
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144327
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
See https://crashreport.libreoffice.org/stats/signature/ScViewData::GetDispatcher()
Change-Id: I3271738b3c7f456adad1309c52195d98646f1acc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144291
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
* Update helpcontent2 from branch 'master'
to 63011fa12038ecc796a66fb4fae4851f5b2647c3
- Document the new SF_Datasheet service
This patch creates the help page for the new ScriptForge service named Datasheet. It also updates associated methods that were added to the Base and Database services.
Change-Id: I6611653b77e1ee41f6afacccb2094f19d7178434
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/144183
Tested-by: Jenkins
Tested-by: Jean-Pierre Ledure <jp@ledure.be>
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
|
|
SfxObjectShell: :Current can return null, it's based on the equally vile
SfxViewFrame: :Current
Change-Id: I1d937b92188deb06eef36af5d0835e173d588d2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144322
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
these ones look potentially worth backporting
Change-Id: Ie7325cd5548c0c10c6b6df9c1a771d24b029b635
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144274
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ib746c28804b0181fe306d53f3f16f70cc36520b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144318
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I76fbf51841f2d5bae38c264af38377f109a8a849
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144317
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...introduced with 73e062be1ff10e2dd889d9ec9c2d07b692077f62 "blind fix for some
7.4.3.2 crashes in UpdateCheckJob" (and wreaking havoc during
--enable-online-update `make check`)
Change-Id: Idde4e4fa8ab94dafa141eb740aba1d874de4717d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144320
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
* Update helpcontent2 from branch 'master'
to e90036912468f58be544b2f12dec0adc7ae8036e
- tdf#134377 Refactoring more help pages for 'built-in' file dialogs …
Change-Id: Ic128cc9d5d59bd80caa369257000b956bad9f437
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/144182
Tested-by: Jenkins
Reviewed-by: Alain Romedenne <alain.romedenne@libreoffice.org>
|
|
Change-Id: Ia7841447df4a7db1b5dd9fad93cab66fbca48981
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144316
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I1a439df62a33c7edccbbe62e373690b17b2f6161
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144315
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Id7202e35bd381e36aa8d36a4ae2c9b987f8e9e79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144293
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The bugdoc has a single paragraph, where the numbering portion is bold
in Writer but not in Word.
The reason for this appears to be that Writer considers text node hints
for the formatting of the numbering portion where the hint covers the
entire paragraph, but Word doesn't do this. This behavior was added in
commits cb0e1b52d68aa6d5b505f91cb4ce577f7f3b2a8f (sw, numbering portion
format: consider full-para char formats as well, 2022-10-20) and DOCX
export was also adjusted in commit
f546f7573158e52359bbeae6194a83a1ff8ac52c (DOCX export, numbering portion
format: consider full-para char formats as well, 2022-10-28).
Fix the problem by partially reverting the above two commits and instead
only consider hints that both start and end at the paragraph end. The
revert of the first commit fixes the new bugdoc (its numbering portion
is no longer bold) and the old bugdoc keeps working if the sw UNO API's
text portion enumeration is extended to expose such empty autoformats at
paragraph end.
Related testcases:
- CppunitTest_sw_ooxmlexport13's testTdf123460 explicitly tested that we
don't expose the paragraph marker's formatting on the UNO API.
- CppunitTest_sw_core_text's testNumberPortionFormat now uses the new
ODT markup for these explicit paragraph marker char props (empty text
span at para end).
- CppunitTest_sw_uiwriter2's testTdfChangeNumberingListAutoFormat failed
when only the above first commit (layout) was reverted, so revert the
matching DOCX export commit as well, which is also good for consistency.
- CppunitTest_sw_ooxmlexport18's testNumberPortionFormatFromODT also
used the old ODT markup, updated.
Change-Id: Iee8acf72dabcd10b3f4d3d68b83ed248bf50c324
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144292
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Before this commit, the 'column' argument was manadatory.
Now the argument becomes optional and designates
the current column, i.e. the column containing the cursor.
Additionally, when a datasheet is closed by code,
any filter is better removed to avoid eventual
user misunderstandings when the datasheet is reopened
manually during the same session.
Change-Id: I904cfa56a9407539a89b7d2451dcf6b45292f660
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144242
Tested-by: Jean-Pierre Ledure <jp@ledure.be>
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
Tested-by: Jenkins
|
|
SfxViewFrame::Current() is a festering wound, these ones look like they
were safe anyway, so no need to backport. But with enough checked static
analysis will kick in to flag new unchecked ones.
Change-Id: Ife81c0e5fc508d8eb30808884c61b8e8c6723890
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144279
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
these ones look potentially worth backporting
Change-Id: Ie01c0b598c3408f4766318267de8438e997dd1a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144278
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
SfxViewFrame::Current() is a festering wound, these ones look like they
were safe anyway, so no need to backport. But with enough checked static
analysis will kick in to flag new unchecked ones.
Change-Id: I2925c4fa4e2d48c1e676ffe7951e65120192517e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144277
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
these ones look potentially worth backporting
Change-Id: I9391f266b08e3842f9686db6113b61fa814f3fbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144276
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
SfxViewFrame::Current() is a festering wound, these ones look like they
were safe anyway, so no need to backport. But with enough checked static
analysis will kick in to flag new unchecked ones.
Change-Id: I28a803be0429b97592d83d88d6c1db077fe31355
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144275
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
crash report id: ec5a64d7-b354-457e-92a3-1bd51208e7c7
Change-Id: Ie64993190baa5e3ea9228214bea1ee4d82044c51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144282
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
SfxViewFrame::Current() is a festering wound, these ones look like they
were safe anyway, so no need to backport. But with enough checked static
analysis will kick in to flag new unchecked ones.
Change-Id: I846a67ca7392182fee6afead8d066fc061ce00be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144253
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
noticed by Julien at https://gerrit.libreoffice.org/c/core/+/143999
Change-Id: Ic17834d503f174f91200614cd48e6771835cc08d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144252
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
these ones look potentially worth backporting
Change-Id: I6153b0f9ead7caef9f228a5724f51823bcf87c07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144280
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
* Update helpcontent2 from branch 'master'
to 53871c4cf5a7703275a2e425b08a4199e9989c46
- fix missing ) in the if statement.
Change-Id: I6b2a45aeda8969778e902ae71e3fa5e46b82875a
|
|
Change-Id: I45e3cc3f4ef9c4e25ffe07e23b39c1e1fe6fdce0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144273
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ibb4eadc15f539ee2d4f030c6366c9abd92bc3823
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144249
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Msgbox (FormFields("text1").Range.Text)
Change-Id: Iac195e09bd3f9619890b336a0cb537a1acd00049
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144136
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Follow-up to 100c914d44ae8f362924fe567d7d41d0033ae8ad
which added the initial id preservation for DOCX.
adding DOCX block SDT grabbaging, ODF import/export
[content controls can't exist in DOC format]
The ID field is CRITICAL to preserve for VBA purposes.
This patch adjusts BlockSDT to also round-trip the id
instead of just creating a random one.
m_nRunSdtPrToken <never equals> FSNS(XML_w, XML_id) since 2021
with 5f3af56b2c0ef6c628a7cfe5ce6e86f8e1765f5f,
so I removed that part of the clause.
I had thought about changing the ID to use a string instead of an int,
but then the integer version was adopted to fix a regression
in the commit mentioned earlier.
I think it is AWFUL to have a number as the identifier
when it will be used in StarBASIC. The VBA guys have to deal
with it, but it would be nice to do something reasonable
for LO native access to content controls.
However, the concern would be if we allow VBA macro content created in LO
to be exported to DOCX format - that would cause problems converting
from a string ID to a number ID. VBA editing already is happening to
some extent, and mmeeks seems interested in enabling it.
So over-all it seems best to just stick with an integer ID.
I used the commits for <w:alias> and <w:tag> to compose this patch.
XML_ID already existed in include/xmloff/xmltoken.hxx
and "id" already exists in xmloff/source/token/tokens.txt
The ID can be used in VBA to select a specific control.
The id (which is a positive or negative integer in DOCX)
specifies a unique control - either by passing the number as a string
(of the UNSIGNED value) or by passing as a float (specified with #).
For example:
msgbox ActiveDocument.ContentControls(2587720202#).ID
msgbox ActiveDocument.ContentControls("2587720202").ID
but not as an integer since that is used for index access.
dim index as integer
index = 1
msgbox ActiveDocument.ContentControls(index).ID
make CppunitTest_writerfilter_dmapper CPPUNIT_TEST_NAME=testSdtRunRichText
make CppunitTest_sw_ooxmlexport17 CPPUNIT_TEST_NAME=testDateContentControlExport
make CppunitTest_sw_ooxmlexport18 CPPUNIT_TEST_NAME=testTdf151912
make CppunitTest_sw_core_unocore CPPUNIT_TEST_NAME=testContentControlDate
make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlExport
make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlImport
Change-Id: I5c4022dc932d941fad9da6d75ce899ee1ff66ff5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142818
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
I am guessing that state in this object is being touched from
multiple threads (since it is an UNO service object), and one or
more of the threads are consequently seeing inconsistent state.
Change-Id: Ib925740d3b8db2713c4f132d0367b794a412a269
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144248
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Use Edit Engine to get the script types instead of trying to duplicate
(poorly) its behaviour. This has the advantage of handling weak
characters and digits properly and is closer to what would happen in the
document itself.
We probably should go further and render the preview entirely using Edit
Engine (since the current code fails short of proper bidi handling), but
this is a bigger change.
Change-Id: I975cb2d96a4a18dbd8110686ca09649cab0ec2f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144284
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
|
|
Use Edit Engine to get the script types instead of trying to duplicate
(poorly) its behaviour. This has the advantage of handling weak
characters and digits properly and is closer to what would happen in the
document itself.
We probably should go further and render the preview entirely using Edit
Engine (since the current code fails short of proper bidi handling), but
this is a bigger change.
Change-Id: I79b28067d80f66087e1d5e9399ba1a513de96c8a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144283
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
|
|
The primary purpose of CharBackgroundExt is a bool flag to
indicate that the watering-can for text background coloring
is active.
It could also function as a synonym for BackColor in the "execute"
state. A prior (NFC) commit removed internal LO use in this way,
so lets drop the ability to do this altogether.
I'm not sure why anyone would have selected to use CharBackgroundExt
instead of .uno:BackColor in API calls. Perhaps they discovered it via
LO_COLLECT_UIINFO. A google search didn't indicate any significant
use or suggestion to use CharBackgroundExt.
P.S. I'm also trying to deprecate BackColor and replace it with
.uno:CharBackColor - which is what this bug report is actually about.
Change-Id: I8d8a2aedb1af18e4a10ff09ad0dabc58e90514a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138167
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
since otherwise merge-conflicts are likely to occur
Change-Id: I46d507763a4d4287a7450bb81d28aed4279aae1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144247
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
While resolving named expression Pinnacle3
IF(AND(Pinnacle1+Pinnacle2<>11,Pinnacle1+Pinnacle2<>22,Pinnacle1+Pinnacle2>9),SUM(MID(Pinnacle1+Pinnacle2,1,1),MID(Pinnacle1+Pinnacle2,2,1)),Pinnacle1+Pinnacle2)
where resolving and inserting named expressions Pinnacle1
IF(AND(SUM($Sheet1.$D$3:$E$3)<>11;SUM($Sheet1.$D$3:$E$3)<>22;SUM($Sheet1.$D$3:$E$3)>9);SUM(MID(SUM($Sheet1.$D$3:$E$3);1;1);MID(SUM($Sheet1.$D$3:$E$3);2;1));SUM($Sheet1.$D$3:$E$3))
and Pinnacle2
IF(AND(Logic1<>11;Logic1<>22;Logic1>9);SUM(MID(Logic1;1;1);MID(Logic1;2;1));Logic1)
with Logic1
IF($Sheet1.$E$3+NilaiTahun>10;SUM(MID($Sheet1.$E$3+NilaiTahun;1;1);MID($Sheet1.$E$3+NilaiTahun;2;1));$Sheet1.$E$3+NilaiTahun)
with NilaiTahun
IF(SUM(MID($Sheet1.$F$3;1;1);MID($Sheet1.$F$3;2;1);MID($Sheet1.$F$3;3;1);MID($Sheet1.$F$3;4;1))<10;SUM(MID($Sheet1.$F$3;1;1);MID($Sheet1.$F$3;2;1);MID($Sheet1.$F$3;3;1);MID($Sheet1.$F$3;4;1));SUM(MID(SUM(MID($Sheet1.$F$3;1;1);MID($Sheet1.$F$3;2;1);MID($Sheet1.$F$3;3;1);MID($Sheet1.$F$3;4;1));1;1);SUM(MID(SUM(MID($Sheet1.$F$3;1;1);MID($Sheet1.$F$3;2;1);MID($Sheet1.$F$3;3;1);MID($Sheet1.$F$3;4;1));2;1))))
overall exceeds FORMULA_MAXTOKENS (8192) in the generated RPN
code, hence an ocStop is encountered as factor token.
(this cries for generating subroutine call token arrays where each
named expression could have their own RPN code and interim results
could be remembered for each while interpreting within one formula
cell; just dreaming..).
Change-Id: I744c4915a00849b107c7c25d7029aa19d976aa86
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144048
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
See https://crashreport.libreoffice.org/stats/signature/svx::ParaLineSpacingControl::ExecuteLineSpacing(long)
Change-Id: Ide29a7e78bf1114f0ebc104fa8c245e52d590eea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144239
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
no need to plant that into the environment of every recipe. some Jenkins
Windows builders already run into "environment is too large for exec"
issue just by attempting a "xargs --show-limits </dev/null" from a dummy
rule within the make environment
Change-Id: I321fa9075532eef62a7d4e33a08c272276de717e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144217
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
it's usually run bypassing all the dependencies & make parsing using
LD_LIBRARY_PATH=instdir/program make cmd cmd='ALL_LANGS="$(ALL_LANGS)" workdir/LinkTarget/Executable/pocheck'
but it doesn't hurt to also have it as a dedicated target
Change-Id: I742373eb0e4d87ea22c80da0dcaaba7116cd2937
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144250
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
these ones looks potentially worth backporting
Change-Id: I294fa029b53fa9d43cb738f07278301e2a06c210
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144245
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|