Change-Id: I05d9fdd234374924c7876d2c123656495016b0ea

Change-Id: Id9362d05ddae2066f2fa289640f447393d7cda84

Instead of #if OSL_DEBUG_LEVEL>0.

Change-Id: I2329de4deff4687fb1249c47f2e24eaf6ea6a248

Change-Id: I61ef0e13a38ebb82becf56ec8ae9e083571d2e53

Change-Id: I06667cbb1fe24356bb24b7781258ef2c194f0e4d

Change-Id: Icda3d24a67c8bbe5aafcf5c917d0f930e534c6be

Change-Id: I7c3df5e82e05dc494e05a15a5f64b9f25b034f74

Part of fix for bnc#805901. (No locking of documents edited through WebDAV.)
Seems to work, can it really be this simple...

I am a bit unsure if any explicit UNLOCK operation happens, but WebDAV locks
typically time out relatively quickly, don't they? And WebDAV implementations
(often/always?) have the possibility for a user to force open a lock.

Change-Id: Ia32d8b1517361f702b4f469d9f1aa17de6d7ba54

Change-Id: I379f8bd780f40169ed7c70c7c5a28277091b978e

Change-Id: Ib5327fe5a88036f718f90cc0e05f287dc1573d03

Change-Id: I40a2e6ea708aa037172bc6e9f9882c88f1d486c3

Part of fix for the WebDAV https server authentication problem noticed when
fixing bnc#805901.

Change-Id: Ic54c59bdadaf34cdba32949400d5da69712017f3

Change-Id: I4acb7ab1aeba31bfeedd4dfbcd76d6bf517b8944

...which started to fail reproducibly at least for me with recent commits, with

[...]
> checking: [sc.ScCellRangeObj::com::sun::star::beans::XTolerantMultiPropertySet] is iface: [com.sun.star.beans.XTolerantMultiPropertySet] testcode: [ifc.beans._XTolerantMultiPropertySet]
> LOG> Execute: setPropertyValuesTolerant()
> LOG> starting required method: getPropertyValuesTolerant()
> LOG> Execute: getPropertyValuesTolerant()
> LOG> starting required method: getDirectPropertyValuesTolerant()
> LOG> Execute: getDirectPropertyValuesTolerant()
> Method getDirectPropertyValuesTolerant() finished with state OK
> LOG> getDirectPropertyValuesTolerant(): PASSED.OK
> Method getPropertyValuesTolerant() finished with state OK
> LOG> getPropertyValuesTolerant(): PASSED.OK
> ValueChanger don't know type class com.sun.star.table.TableBorder2
> warn:legacy.osl:19841:96:sc/source/ui/unoobj/fmtuno.cxx:197: lclResolveGrammar - unspecified grammar, using GRAM_PODF_A1
> warn:legacy.osl:19841:96:sc/source/ui/unoobj/fmtuno.cxx:197: lclResolveGrammar - unspecified grammar, using GRAM_PODF_A1

causing a SIGSEGV at

> #24 <signal handler called>
> #25 0x00002aaacd9b310b in ScBaseCell::SetScriptType (this=0x0, nNew=8 '\b') at lo/core/sc/inc/cell.hxx:104
> #26 0x00002aaacdc86a9f in ScTable::InvalidateTextWidth (this=0x2aaad80d9e00, pAdrFrom=0x2aaacd16ac00, pAdrTo=0x2aaacd16abf0, bNumFormatChanged=true, bBroadcast=false) at lo/core/sc/source/core/data/table5.cxx:1200
> #27 0x00002aaacdabb18a in ScDocument::InvalidateTextWidth (this=0x2aaad88a19f8, pAdrFrom=0x2aaacd16ac00, pAdrTo=0x2aaacd16abf0, bNumFormatChanged=true) at lo/core/sc/source/core/data/documen8.cxx:440
> #28 0x00002aaacd982d94 in ScAttrArray::ApplyCacheArea (this=0x2aaad81d5380, nStartRow=0, nEndRow=4, pCache=0x2aaacd16ac70, pDataArray=0x0) at lo/core/sc/source/core/data/attarray.cxx:825
> #29 0x00002aaacd9cdaa2 in ScColumn::ApplyPatternArea (this=0x2aaad80d9e00, nStartRow=0, nEndRow=4, rPatAttr=..., pDataArray=0x0) at lo/core/sc/source/core/data/column.cxx:450
> #30 0x00002aaacdc638cf in ScTable::ApplyPatternArea (this=0x2aaad80d9e00, nStartCol=0, nStartRow=0, nEndCol=3, nEndRow=4, rAttr=..., pDataArray=0x0) at lo/core/sc/source/core/data/table2.cxx:2174
> #31 0x00002aaacdad93ce in ScDocument::ApplyPatternArea (this=0x2aaad88a19f8, nStartCol=0, nStartRow=0, nEndCol=3, nEndRow=4, rMark=..., rAttr=..., pDataArray=0x0) at lo/core/sc/source/core/data/document.cxx:4204
> #32 0x00002aaacdaddeef in ScDocument::ApplySelectionPattern (this=0x2aaad88a19f8, rAttr=..., rMark=..., pDataArray=0x0) at lo/core/sc/source/core/data/document.cxx:5232
> #33 0x00002aaace0c46ab in ScDocFunc::ApplyAttributes (this=0x2aaad8910f70, rMark=..., rPattern=..., bRecord=1 '\001', bApi=1 '\001') at lo/core/sc/source/ui/docshell/docfunc.cxx:1267
> #34 0x00002aaace268e02 in ScCellRangesBase::setPropertyValuesTolerant (this=0x2aaafa235fb0, aPropertyNames=uno::Sequence of length 97 = {...}, aValues=uno::Sequence of length 97 = {...}) at lo/core/sc/source/ui/unoobj/cellsuno.cxx:2933
> #35 0x00002aaabc674df6 in gcc3::callVirtualMethod (pThis=0x2aaafa236018, nVtableIndex=3, pRegisterReturn=0x2aaad8b94820, pReturnTypeRef=0x2aab601513a0, bSimpleReturn=false, pStack=0x2aaacd16b240, nStack=0, pGPR=0x2aaacd16b2c0, nGPR=4, pFPR=0x2aaacd16b2f0, nFPR=0) at lo/core/bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:119

Change-Id: I4cf6386f903e2681033bd63005141f71feb13ad7
Reviewed-on: https://gerrit.libreoffice.org/2740Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

for gdk_screen_get_primary_monitor but osl_getAsciiFunctionSymbol does the
right thing

Change-Id: Ibf1a17724a9393d95c4fbe0d26aa82148eea33a9

we go to some effort to determine the right value of ret
and then throw it away and return 0

regression since 4a7e3482

Change-Id: I652cfbe44fdab6560c1c8dc8fe25d6211b5357cb

Change-Id: I4bf2d72ba14f5293c2f9aa8eb3a34fedefa03939

Change-Id: I3a3a8dbf5e15d3d3e882b1f7b9a17c6f985afd9c

Change-Id: I786227d89cc441990d6bdce0acf872a73be51a7c

Change-Id: I3ec724037fae49e7e29115e5e4814c48a98e7c0d

Change-Id: Icf489a49c547a93458aeef1c70ba699181a47c38

Fixes a problem that was noticed when working on bnc#805901, which is about
documents opened from WebDAV (using https) not being locked (in the WebDAV
sense).

For some reason, at least in the 3.6 branch, I noticed that LibreOffice did
not manage to open any connection to the WebDAV server. The error message
"Server error message: Server certificate verification failed: issuer is not
trusted" was displayed.

Turning on Neon logging I saw the OpenSSL error code 19
(X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN) passing by.

Some googling turned up
http://stackoverflow.com/questions/4103472/ssl-handshake-fails-with-a-verisign-chain-certificate-that-contains-two-ca-s
. If I understand correctly, root certificates (which are the final ones in a
certificate chain) are by definition self-signed.

One can try this on Linux (or even on Windows, using the openssl command built
as part of the LibreOffice built):

openssl s_client -connect vibe.novell.com:443 -showcerts

and see that it also displays a message about this "error": "verify
error:num=19:self signed certificate in certificate chain"

One can get around that by passing the -CApath option:

openssl s_client -connect vibe.novell.com:443 -showcerts -CApath /etc/ssl/certs

on Linux. There is no corresponding directory with trusted certificates as
files on Windows.

This tells OpenSSL where to find a list of trusted root certificates.
Apparently when OpenSSL is used by LibreOffice it does not use the list of
trusted root certificates that Windows knows automatically. This patch makes
it do that when ne_ssl_trust_default_ca() is called.

Change-Id: Iddbd3d61413aa52adbed3f9a0239a364e70668d8
Reviewed-on: https://gerrit.libreoffice.org/2741Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>

- as this is being quoted, this causes breakage

Change-Id: I6834a3235ae2334a0d6f7df0f97dcde7cdc6a5d0

Change-Id: I446fa717dfd11fc5d6045cb1e8dc3eaf8861262e
Reviewed-on: https://gerrit.libreoffice.org/2738Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>

Change-Id: I56c9c8307d6e5c3d119b9c894ef5122f448ef3f7

the second argument is a count

Change-Id: I1b6d7db8ba3ac83ef0be091c25e28ad93375d432

Change-Id: I0f23e9f7f076f3a82d1d5df92d9d4d3919fc816d

Change-Id: Ib25a9eab4ff2b2ba078f18d21e5f697c4fd62460

Replaced String with OUString in module dbaccess/ui/app , and also removed RTL_CONSTASCII_USTRINGPARAM deprecated macro.

Conflicts:
	dbaccess/source/ui/app/AppControllerDnD.cxx
	dbaccess/source/ui/app/AppControllerGen.cxx
	dbaccess/source/ui/app/AppDetailPageHelper.cxx
	dbaccess/source/ui/browser/unodatbr.cxx

Change-Id: Ie385d44c328fb3f919d53a604d51640a334a1013
Reviewed-on: https://gerrit.libreoffice.org/2386Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>

Applied fdo#38838 in dbaccess/source/ui/browser, +
RTL_CONSTASCII_USTRINGPARAM removals

Change-Id: I8a565cdae7fd9da1de05525c602ce011542ab4d5
Reviewed-on: https://gerrit.libreoffice.org/2538Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>

Change-Id: I90a001b354810daefd6cd05ca96de4207eee15aa

Change-Id: Iec5a960b0a6492b1e4690c31b9c2098248c23cfa

Change-Id: I0a83769f19a38fd5c0421ba6117603517cded17b

This needs some tweaks but it looks like we are already able to choose
the chart and import it. There are some more tweaks needed to handle
internal vs. external data provider, errors, other components, ...

Change-Id: Ib3e7f8bbf7b7f49b071d85120930624e2add91a7

the base class destructor is already virtual

Change-Id: Iab38666fab3a8ef33e2fd1ee1c53754ef50f5481

Change-Id: If554782930a8cf35fa4366d8f92020f1c7b5cbd3

Change-Id: I240ab25258cb66786cd8882c8c4e1da5e30f8863

Change-Id: Ia2f7ccc2a9ccc888dfef5d5bf0cb366b1b3ba981

Change-Id: Iac59e450521b427c5ddb77cb944dd12ef4bb0cea

We can now export a chart to odc when we are in chart edit mode from
Calc. I need to add support for it to Writer and Impress as well.

We can already open these files but copy&paste from the opened file
fails. The next step is then to add a new menu entry
Insert->Object->Chart from file

Change-Id: I14d1702e79517e7319a1929de2be5501d375885d