Change-Id: Iba320b00bdef3704bdfe1abe2a60b8c767a571ec

This reverts commit 4c2e9fc6.

Change-Id: Iea84991ee689240fe6e6ddbc47f44b444f582dde

Adds IMTAN, IMSEC, IMCSC, IMCOT, IMSINH, IMCOSH, IMSECH, IMCSCH spreadsheet
functions.

Change-Id: I04ce0b1fdf787c3d8b2301cd92400e54049494bf

Change-Id: Iea1e44f40a1e2d51947cdeff4f8948f3612dc25c

Change-Id: Id3189a9abff5ee97b93bccefba8193ba36cb043a

Change-Id: Iad6bc5af052a0795608ec11ee11c8dea3d091868

Change-Id: Ia63eea0c19bfa750b80f4c99f278f8d144c714a8

Change-Id: I4fac64952abf208864281fda722d8b7242689395

I had to make the destructor of SvxRTFItemStackType public.
The combination of friend class, boost, and a private destructor
does not make OSX's gcc happy.

Change-Id: I2d9a3bff3c5edaf5435fb543389a9a2822c6b2ad

Change-Id: I6b0fee0f5d736006938d3d6ab69745219bffa227

Change-Id: I90d357107f69ea5939952e9640b5e1f4cbdcec3d

Change-Id: I1d53e6815c4da5ef5f525dbc11bca73723bb3bd2

Change-Id: I90628a60e3eb33097728e1036b22a5c000be02bc

For reasons I don't understand, the compiler would get uncopy
if I tried to declare the destructor in the header file.

Change-Id: I67fa7941da2f0ee08ae10bf350fb1f3bf1397410

Make SbCompare_UString_PropertyValue_Impl a strict weak ordering.

Change-Id: I70d639ad44ceb69311c2d5bc1b95c972ad658451

Change-Id: I3e072c165d83e9ade06caf2508031b473ef7691d

Change-Id: I4e288a90f3b1662462ba06053343c8bab5fe46cf

I had to keep the pointer typedef because MacOS gcc gets
confused otherwise.

Change-Id: I0681585f7273dcac25b2cb835601b29353e2183a

Change-Id: I9197dc4fd7ed32f030de8121913265ec78c83585

Change-Id: I6cd5793b1ba2a29cbedce7fe5a040651e1664a11

I could not use boost::ptr_vector because some of the code copies
the pointers into other data-structures temporarily, which
ptr_vector does not like.

Change-Id: Ie9c8aeb4e741bfd138694929ccda451a1c0984bb

I could have used boost::ptr_vector, but the code seems to believe
that the array can contain nulls, which ptr_vector does not like.

Change-Id: I5f56a3e96ef9baca2c192e7cfa33b8f4283709a6

Change-Id: Ie7aa19b7ef5c25b2547a9fd29810fb56427edac0

Change-Id: Ic3b06e179d182d68288c7c6832149309160cd637

Change-Id: I29e61ac8c932d0920f326f268aa62acc4aaec5c5

Change-Id: Iea01a7d7c01bb9da80ccae001157c60d6090348b

Change-Id: Ic4cb48c1ea3df05cecaedb41941d9b592d591a55

Change-Id: I2fee4cf49ff48e4cffef0bcba704b69aad8242d8

Change-Id: I2375831167dff55b7906cc7ae8c8a1b53fc88125

Change-Id: Ic541506a426e056909f6c5cb67af166d4081ea89

BITAND, BITOR, BITXOR, BITRSHIFT, BITLSHIFT are written as _xlfnodf.* in Excel
export because Excel doesn't have them. So far we weren't able to properly
read that in again and the #MACRO? error was generated as function result.

* removed XOR entry again from sc/source/filter/oox/formulabase.cxx
  saFuncTableBiff5
* changed XOR entry in sc/source/filter/excel/xlformula.cxx saFuncTable_Odf
  from ocNoName to ocXor to have it written as _xlfnodf.XOR
* changed description of function in Function Wizard

Change-Id: I994119c0520658775d07f776237d31a03f53ab52

Change-Id: I0d345b2cf60f49e0e6b72724251c1f6d30529dce

Change-Id: Id68521b92f572366a68f35c09387a7ed45a835ff

Change-Id: I1b12a923e8c045c7ebca8c0b77b8135d3e072ac9

Change-Id: Idd938980b91ec8b822a92dfd7013a20fe5b6f498