...had to adapt one test that had picked this service apparently arbitrarily.

Change-Id: Iaa17b7c622b9ac3601beb3ba931f7b1d99f649f1

Change-Id: I23f5f002826e2ecc25ff19d18372cb637feb1310

Change-Id: I075467d17f6c59bd66a7a2d8e1e82f2a3ba42cad

Change-Id: Iab19ae876162e72104267ad5f760f55e7d854934

This saves us several string comparisons for every cell during import
which should speed-up our cached value import quite a bit. I haven't
profiled it yet. Additionally it lets us move away from a heuristic
based approach.

Change-Id: Id9ca92a1251b62e99ca54209fdd52031694784b1

Change-Id: I364afb6d638f47a41ea31bf3df00540db417d505

Change-Id: Ia5dbea0a496f578f619276def349ff21674fb644

For cached value import we need the information which cells are error
cells. For ODF 1.2 extended we therefore export now calcext:office-value
with the additional value "error".

Change-Id: I9bc988ea4924bea767ba5e504b77f6a16e51a82e

Change-Id: Ie70d580cd2a4ad88751672fd257c825b9813c86e

This is actually a regression caused by
1165aac9, where a confusing code was removed,
that should have stayed there.

Re-introduced in a readable way.

Change-Id: Ib99c19c04cf3b098097cef8da5da63b8cc7dd130

let si-phonetic-dynamic survive libreoffice losing focus and regain it cycle
and still use surrounding text. It should be safe to report that we can provide
surrounding text but there isn't any during the time window when there is no
focus window, because the focus in event was received but it hasn't arrived yet
because that happens on a postuserevent.

Change-Id: I0481c42208953f2a0618aaed7b0d9e9f3e7bda07

http://lists.freedesktop.org/archives/libreoffice/2013-April/051026.html

Change-Id: I81031d8290efcc4f343af7bdffb4762411f4f107

i.e. false for "we can't provide context", and true for
"we can provide context, even if there isn't any"

Still looks to me that there's a bug in the si-phonetic-dynamic
im (or something in the stack) that assumes that returning
false once means it will always return false and give up
for ever

fix indent while I'm at it

Change-Id: I6df7f2689101250c33318db1fac5ec1b3e340566

Change-Id: I84c73b07d8a4a6950cde98898754168720952934

Change-Id: I1dcfee9fa0fdc4457754396ffb52cc8462f3906a

The service already existed, it just needed an IDL file

Change-Id: I30cfa80fee436ed859d5bc00d1cb23e465c7e149

The service already existed, just needed an IDL file

Change-Id: I5e6449522ce77c36df1857213bd028336c3354bf

The services already existed, they just needed IDL files

Change-Id: I4e3389abb2cb0e41c9bab112cda2a7e896eb271d

The services already existed, just needed IDL files

Change-Id: Ifc1980160b8472bc9bf96a36ca4bff2c4153a8b1

Change-Id: If7cc52ffeb35efe0969876a9822106b1fd958b10

Change-Id: I457288d881ba74db2127e8543b0de70b6498002d

Change-Id: I34c532dc7d1c71724a5c0e29c113f2d6510cc2d7

Added the check only in the Axis Labels import.
Maybe this check can be moved to convertNumberFormat()

...and remove the unused feature of initializing it with an obsolete
XSimpleRegistry.

Change-Id: I333dae51f67c16da3e6822ba81e4b8ca125188a5

It is not good to mess with the stream operators, more so when the size of the
data changes ;-)

Change-Id: Id02b83224496a28575f4e12196892de198793983

Thanks to Fridrich for finding the real cause for why I thought this was
necessary..

Change-Id: I77934b17c2b994a03cae5440253b165704de2fa4

Since 360d6bf4 the precompiled header for vcl
includes <rsc/rsc-vcl-shared-types.hxx> , so the KEY_SHIFT from there
interfered with the KEY_SHIFT here.

These magic values apparently are the "known" return values from
MapVirtualKey() called to translate (fixed) virtual key codes to scan codes,
suitably shifted and ORed with some flag bit(s). Whether such scan code values
really are constant in all Windows installations I have no idea, it does sound
a bit scary to me to assume they are. (If they are, why does <windows.h> then
not provide symbolic names for them?)

Change-Id: Ic18a8e1a8b7a95bb6b018382662944f6912e4734

Project: help  0f337351043a65843b4b7687d33ca5afdc8289b8

Change-Id: I4c4511787247bdcabd88af1c3b0894361336b71f

Change-Id: I76cca4646bd0258cdf64a079edb017e6243839af

Project: help  01a9fff87678572226b099c7102f5f1b03bec4b4

Change-Id: I59ff70e3280d4e746b0d20f7f9532a341d88cb57

Just use SAL_WARN, building up the message using chained << operators instead
of constructing it into a OStringBuffer (or OUStringBuffer) and then passing
that to OSL_FAIL.

Or should we have a real assert() here?

Change-Id: I2c3f64ff2b29a3d81ba444d98c2a38ef49e6d7af

Project: help  9b03a7110683c9e05b5a6a193d71dcfad58b8122

Change-Id: I0e4f45d9e74fd2ae04defa75fce225d61295cdbc

Change-Id: I9a47317bf7251dfef5f5d7f2cd6b817792114289

Change-Id: I17fa205f16929b913084c8eee320a73416b1eda0

Change-Id: I67e73438312f2a672e71762ee6707ec5d425bb47

Whether it works, no idea. But on the other hand, from the dicsussion
in fdo#61503 it doesn't seem as if that commit was deeply insightful
either. (And how it compiled on the commit author's machine, no idea.)

Change-Id: If6355b33c406e8da5bdb2bf77aaf8b2ac0c39343