Change-Id: If5e0a2bbfbd56a2d647dac608643411eefa1ed73

Change-Id: I62f8d5c3cac71f83f5cdde114f66e8554a780538

Change-Id: Ibcf1fa35617ee8d7fab6b66e3e8c8881ad55c3e5

Change-Id: I54382b0dd0f6b6f21f635d75cb3ee3cefc1eb203

Change-Id: I73a69fdfee0b0f3af5bf6b4e52629dba7ed69630

The problem was that SwXTextEmbeddedObject::getEmbeddedObject() returned
an empty reference for those embedded objects, so the HTML filter
couldn't extract their content when it wanted to do so.

It turns out the reason for this was that the DOCX importer only handled
the replacement image + raw native data for the object. Fix this by
creating the embedded object with the correct CLSID and import the
raw data into the empty embedded document model.

This is similar to what is done for XLSX-in-PPTX in
oox::drawingml::ShapeExport::WriteOLE2Shape(), just for the import part.

Change-Id: Ieb1dcb1774d2d4da00117e3a35160053066c78aa

Change-Id: I59153a29e6271abb4d184bd3c67cd8fb2c092669

On non-Windows, when double-clicking an embedded OLE object, our glorious
content type detection logic detects it as "Text". As a side-effect, we start
to calculate text statistics on it. Which surely could produce interesting
numbers (you know what they say about statistics), but sadly causes a crash
involving the ICU RuleBasedBreakIterator, SwScanner,
sw::DocumentStatisticsManager and whatnot.

Avoid this by checking for a detected filter of type "Text" explicitly, and
avoiding the fun code paths in that case.

This leads to double-clicks being just ignored. Maybe it would be more useful
to produce a "General OLE Error" message box?

Change-Id: Iae0726b5e9c511a92bdff7229d2978cbf76cb07b

Change-Id: I63a513406dbd90746bcad9da88945f49d2b51cc5

Change-Id: I1874b5b4a059ef5fc8818b3b49ff10f2917b20ca
Reviewed-on: https://gerrit.libreoffice.org/11135Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: I37ec7e6104dc9526b1792f163fe58ec8673274c2

Change-Id: I8c21bfd70e5afb6d4f9a0a57f9946074c1b16a52

Change-Id: Ia2777d61678f511c1e604c55b4e349d2ab938b24

Change-Id: I1d1fff8b596d75a4cb033679d06b300402dbf212

commit 4b56d82c converted the cli_uno
library from "Managed C++" to "C++/CLI", but forgot one detail:

The destructors on "ref" classes were mapped to Finalize() methods in
the old syntax, but the new one maps them to Dispose() methods, which
are only invoked on stack-allocated objects.  Presumably this omission
results in leaking of native C++ UNO objects.

Reading the C++/CLI documentation i get the impression that:
1) the destructor should explicitly call the finalizer
2) the CLR will not call the finalizer itself iff the destructor is
   invoked

http://msdn.microsoft.com/en-us/library/ms235315.aspx
http://msdn.microsoft.com/en-us/library/ke3a209d%28v=vs.110%29.aspx

Change-Id: I509d9b69a399c3d7d6597060ab9b7c78c5916e11
Reviewed-on: https://gerrit.libreoffice.org/11132Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>

Change-Id: I90b8e30ffd095cc3fa20938cd15adf4d217bb6e1

Change-Id: I053c99c1b544fd64951c42ebe1c232cd1768e79f

Change-Id: Idc13f652d359baf2c91758ee1efd5b908b4b9483

Change-Id: I1a86ff55805e88cc559795139c7f8f84d3fb5109

Change-Id: I9654fb02a1481b679d98359424e272cc4a706464

Change-Id: I61dd4fac1e93e3b6255f31585b19f0182cb45b97

Change-Id: I2407166368b55b973c70a2edc377785b82d8481b

Change-Id: I18edebf6fe3c323fec2f6190b00bdc6b5d76c4bc

Change-Id: Ibb8b57577696e582c05ac0ea372385373e3444de

Change-Id: I417583701fdc24f846c684924fef4dfa4becb259

Change-Id: If95ae86708660007e6a0f4df27b3c364a9653dae

Change-Id: Ice1d71e730519697c891d66909550876c9d23ebb

Change-Id: Idaed255e4f004ad555ccbd6ba9dc29bf522d3c5f

Change-Id: I21f394c1a2f91a18af8eb46ed9be3c2f786fe1ef

Change-Id: Ia4089023ff1b9a18ed44f599dc7382fc3dcbbd36

Change-Id: I676039b07519fbed3b92c6ada0fa8217ee2cbe27

aName == aLinkTabName.copy(nIndex, nLinkTabNameLength)
is not a replacement for
String(aName).Equals(String(aLinkTabName), nIndex, nLinkTabNameLength)
instead use
aName.match( aLinkTabName, nIndex)
because here nLinkTabNameLength actually is aLinkTabName.getLength()

Change-Id: I884f56541f819db5672e9d096a26a3673e82d83b

Apparently this seems to have been forgotten at one occasion.

Change-Id: I1436e412c1308f451d9d953f432a9887cfc99b59

Apart from that they weren't currencies and only in the way when adding
a new currency.

Change-Id: If8ca3ab3b37f3617c3f73a01428c0c30dd3481d7

Change-Id: Iadf4ae9a569388528f1083c22d6ff197d6479ba9

Change-Id: Ic8395cc31845e510b6ef5fb2a1d5f66534295012

Change-Id: I1722c1d3816e6e995e71317a9c9b1529afe9df13

Change-Id: I202f716bcc65165e80928ccb81cec57f01bc0824

Change-Id: I37c4db8ad7283486dd8bb62b22342f6b127f0b08

Change-Id: I1e2ae37a75826d321268395d4a3c23c7ed8d7b17