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/27087Tested-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/27177Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>

Change-Id: I0a321e8ffbe379588a288084ec2e74e1a8c296b2
Reviewed-on: https://gerrit.libreoffice.org/27171Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: I5c276c11885913129ab2c947f28c52439ef0d188
Reviewed-on: https://gerrit.libreoffice.org/27048Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: I7c16212b5f1832aa5d79c8e883fc5cd103f0657b
Reviewed-on: https://gerrit.libreoffice.org/26925Tested-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 367105e0

Change-Id: I15fff464e2f71a6ade29c141bb17216770f54ced
Reviewed-on: https://gerrit.libreoffice.org/27127Tested-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/27159Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>

Change-Id: If3596f7b2b546f360774e995867d18c9ba543737
Reviewed-on: https://gerrit.libreoffice.org/26785Tested-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/27137Tested-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/26914Tested-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/27134Reviewed-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/27166Tested-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/27157Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: I0fb35541863c1390c5a95e60539404547398cba3
Reviewed-on: https://gerrit.libreoffice.org/27156Tested-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 a5a71cea

Change-Id: Ia1d2ac626dbdeea689a1f36494963be18316127f
Reviewed-on: https://gerrit.libreoffice.org/27161Reviewed-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 bdc1824e
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 0759f311 we check that, so test
for error here.

Change-Id: I395360d96ece31d8fb6a969c75d06b5e441c3051

Change-Id: I906ef285ec6164284924ca4771a6da758bd23fd6
Reviewed-on: https://gerrit.libreoffice.org/27140Tested-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 d6f1ca24.

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 d6f1ca24
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/27034Tested-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/27006Tested-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/27002Reviewed-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/26996Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>