Age | Commit message (Collapse) | Author |
|
remove using namespace ::chart::ContainerHelper;
to match other uses
Change-Id: I343086a6b7d70c84499b209680973431c7317219
Reviewed-on: https://gerrit.libreoffice.org/27184
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
the meFilterType field in WorkbookGlobals lead to a chain reaction
of code removal.
Change-Id: Iaa8b467c1c76cab78f8ce1796709590b666028db
Reviewed-on: https://gerrit.libreoffice.org/26682
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I4ef60e11878676b8276f85811e811908242ab1b2
|
|
Change-Id: I4a11f040bb56de0bc761b185395dc87533c3bf01
|
|
Change-Id: I5bfbc8dbba63531ddb05e40e94f626aa5c86071d
|
|
+ Export of paragraph and character properties
+ Tests
Change-Id: I689deb2c524fdcd462c69a33ad9bc2865890793d
Reviewed-on: https://gerrit.libreoffice.org/27115
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
'regression' seems harsh, its not so wide it didn't fit on a reasonable sized
screen or look particularly horrific.
Change-Id: I20d55b8aac609ee0d683eb9a1c2b173aa0c9d8da
|
|
Change-Id: I25760def2c12e4ca87843c2f3ce1a60b5a9b2e44
Reviewed-on: https://gerrit.libreoffice.org/26680
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: Ib5a6fc98fafb774ca5c7cc1323dbe4eb8a1c4aff
|
|
Change-Id: I9dab4c0beef08b04e65dc0dae337a822041cf218
|
|
Change-Id: I384e9ee1a38aad80bf3a4906a4955c57e4895538
|
|
Change-Id: Ic5d08f08c1fccc74be09cea7887d3acb910e7636
|
|
Change-Id: I620d01f2cfbc5327c2fcaf020d50e9184fc1d1b2
|
|
Change-Id: I1065acf0f2406881532e75459bfddbdb7967ad8b
|
|
See e.g.
http://crashreport.libreoffice.org/stats/crash_details/80884848-16e7-4512-be4a-74c53bfce34b#allthreads
The thread can run while the UI elements have already been disposed. The
StopExecute call is not enough to prevent that from happening.
Change-Id: Iab4209776e1403a6520c106f3521476ee50848a4
Reviewed-on: https://gerrit.libreoffice.org/27087
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I14241c8a4418e8356a590a32b661f283b606f9fa
|
|
Change-Id: I9f9b647ed73e06a5e926eff8f95dda92fec134c0
Reviewed-on: https://gerrit.libreoffice.org/27177
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I0a321e8ffbe379588a288084ec2e74e1a8c296b2
Reviewed-on: https://gerrit.libreoffice.org/27171
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I5c276c11885913129ab2c947f28c52439ef0d188
Reviewed-on: https://gerrit.libreoffice.org/27048
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I7c16212b5f1832aa5d79c8e883fc5cd103f0657b
Reviewed-on: https://gerrit.libreoffice.org/26925
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
and remove comments about a gcc 3.3 workaround.
some comments went obsolete with other commits
like 367105e0248c7b80b60b2554d04f5f248b4259b3
Change-Id: I15fff464e2f71a6ade29c141bb17216770f54ced
Reviewed-on: https://gerrit.libreoffice.org/27127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
How to reproduce the problem: open an Impress presentation in
gtktiledviewer, create two views. Start editing the text of a shape in
one view -> nothing happens in the other view.
There is no invalidation in the other view, as
sdr::contact::ViewContact::AddViewObjectContact() is not called for
either of the views. Editing with a single view only worked as when
clicking into the shape, the ViewObjectContact is created.
On the desktop, those ViewObjectContacts are created on the first paint
of the slide, but in the LOK case the vcl::Window instances had a 0x0
size, so an invalidation didn't result in a paint -> no
ViewObjectContact was created -> no LOK invalidation was sent.
No testcase, as I didn't manage to write code that actually triggers the
failure under cppunit with the fix reverted.
Change-Id: If29fcea4258a45f3d6d9aab284445756609fa13c
Reviewed-on: https://gerrit.libreoffice.org/27159
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: If3596f7b2b546f360774e995867d18c9ba543737
Reviewed-on: https://gerrit.libreoffice.org/26785
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
... so handle it and avoid the assert
Change-Id: Ib244746fabeaf41b5ca927d94fc4c3bda19bef26
|
|
Change-Id: Iea05efbb90a0a95fefd18ae9673095a31422f06c
Reviewed-on: https://gerrit.libreoffice.org/27137
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I2fd32bb210f1b5f0a090c29af707cb6ca6e8dd77
|
|
::GetAppData replaced with SfxApplication::GetModule
that now returns SfxModule*
SfxModule no longer registers self for ownership
instead it is now registered using SfxApplication::SetModule
Change-Id: Ifbbe1b2b4c5122da8e643b7926d47878d116c6c8
Reviewed-on: https://gerrit.libreoffice.org/26914
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
... and let the interpreter decide about validity. Only if at least two
parameters are given, empty/omitted or not.
Change-Id: I2d7070e56f616b1940ff577c43e257eabb81b412
|
|
Add-In functions have to explicitly support a missing argument, not get a
default 0 substitute value passed.
For this, some already existing function test cases had to be adapted. YEARS
and WEEKS last arguments are required, and the FVSCHEDULE and ODDLPRICE cases
now work as in Excel.
Change-Id: Iec362db2a23b431db5917613faad2ea88a09a89c
|
|
Change-Id: I6d1fbba2231faaf3ef64564705cf5b1fbcc8433a
|
|
Change-Id: Ib182f6caae61eda5f85d241ddb1499671df0a28b
Reviewed-on: https://gerrit.libreoffice.org/27134
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Tested-by: Katarina Behrens <Katarina.Behrens@cib.de>
|
|
Change-Id: I8a2426e80411940aa295ed46eefca58c6864943a
|
|
Amazingly we fell-back to the old calculation path for
crashes in older LibreOffices, might as well have this on master.
Change-Id: Ifc1de41c93329207d7a1917c736e361d840c2821
Reviewed-on: https://gerrit.libreoffice.org/27166
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
E.g.
http://crashreport.libreoffice.org/stats/signature/com::sun::star::datatransfer::DataFormatTranslator::create%28com::sun::star::uno::Reference%3Ccom::sun::star::uno::XComponentContext%3E%20const%20&%29
Change-Id: I55d7fc9a83526de0cc5f838f0ee2c7e4649dbe6b
Reviewed-on: https://gerrit.libreoffice.org/27157
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I0fb35541863c1390c5a95e60539404547398cba3
Reviewed-on: https://gerrit.libreoffice.org/27156
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
like the other platforms do
Change-Id: I31340254573d13dc808d1e3038e3a36ae97f6c22
|
|
Project: help d17b91b6c497fa9b97ed6d588fcfb37bbdf1d0ad
(Regular) tooltips can no longer be disabled…
… so this is always true.
Change-Id: I1154f86cd7dde358a669f6a3020119e9685ac83a
|
|
DontTerminateEdit was added in a5a71cea62ac3041006c5e9815ae2317999639ac
Change-Id: Ia1d2ac626dbdeea689a1f36494963be18316127f
Reviewed-on: https://gerrit.libreoffice.org/27161
Reviewed-by: pranavk <pranavk@collabora.com>
Tested-by: pranavk <pranavk@collabora.com>
|
|
to determine code shared between C and C++
Change-Id: I1fadf69bf9d0a2bde527b7c3f2ec4c687d70e4ae
|
|
This effectively reverts for the normal-app
commit bdc1824ea7acfa2fe9d71cdbe57882acce155577
Author: Miklos Vajna <vmiklos@collabora.co.uk>
Date: Tue May 19 17:20:10 2015 +0200
SwPaM::Find: search in shapes anchored to the range
The catches are that...
writer will use SvxSearchCmd::Find and not SvxSearchCmd::Replace when Replacing
text, and replacing it afterwards. So replace doesn't work. It might be possible
to mitigate that by passing down the m_bReplace to SwPam::Find and do a
SvxSearchCmd::Replace on the editeng SearchAndReplace in that case and then change
the return code to not-found/found-in-writer/found-in-drawing to figure out what
to do there.
regexps are disabled in the ui for draw/impress, maybe because they seem not be fully
implemented right wrt matching empty paragraphs, so using regexps in writer and
letting them into editeng via this loophole is new territory for the editengine
I think if I was trying this I'd fix regexp in editengine, then try add
searching/replacing in drawing boxes sort of at the end of searching in the
main document, something like how searching in frames works.
Change-Id: I2875b374a7ede8edd7f479254cbc2da36488abc8
|
|
Since 0759f31172253d6c5be3b938446ff1b8313adebd we check that, so test
for error here.
Change-Id: I395360d96ece31d8fb6a969c75d06b5e441c3051
|
|
Change-Id: I906ef285ec6164284924ca4771a6da758bd23fd6
Reviewed-on: https://gerrit.libreoffice.org/27140
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Revert "lool - search all - unit test failure - solved"
This reverts commit d6f1ca24932ba85607ba3e526c5721132cd39252.
Change-Id: I328ece1029955ff9f4e5043084d649898e3e8809
|
|
in FindAll libreofficekit impress test
on find all we loop through the textboxes searching for the string.
We start by searching into the first textbox with the string in it.
mbStringFound gets set to true and this first selection is reported.
Now the current pos is still in that textbox at the end of the string.
The next loop will find nothing in this textbox, but because mbStringFound
was set in the earlier pass, the same selection gets reported again.
The next loop will move to the next textbox.
To keep this fix as simple as possible just check if the selection was
the previously reported one and skip it if it is.
I believe this is the problem that
commit d6f1ca24932ba85607ba3e526c5721132cd39252
Author: Marco Cecchetti <marco.cecchetti@collabora.com>
Date: Mon Jan 11 16:43:02 2016 +0100
lool - search all - unit test failure - solved
wanted to solve
Change-Id: I30e7b9c581488b48fa27f138209f291063b459a3
|
|
Change-Id: I68faf8cfb8eb390e7970383b8a6596a9dd3f95f7
|
|
...which is only ever called from onexcept XInterface::release overrides:
connectivity::release itself appears to be only called from
connectivity::OSubComponent::relase_ChildImpl [sic], which in turn is only
called from various XInterface::release overrides across connectivity.
Change-Id: I94b682ec531acecd0ef9f8c100f67a71c361941e
|
|
Change-Id: I8935ed85df456bd5f86adf0392a19eb0b6a2f656
Reviewed-on: https://gerrit.libreoffice.org/27034
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I7706a950b904603b6d87306e4a8faa0c4f0cc8d8
Reviewed-on: https://gerrit.libreoffice.org/27006
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
(and Excel).
Change-Id: I1cc40494fb2451a06864f770af7c33d26013dcaa
Reviewed-on: https://gerrit.libreoffice.org/27002
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
With unrealistic depreciation rates (>100%), the caluculated amortisation
value can be < 0. Although mathematically correct, financially this is
nonsense. The patch returns 0.0 when the calculated amortisation values
gets < 0.0. (Excel does the same.)
Change-Id: I928bba647429ff6141abfdbd996d4562e31da746
Reviewed-on: https://gerrit.libreoffice.org/26996
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|