Some extra code to ensure that OUString's copy method gets correct
sub-string lengths.  Unlike UniString, OUString's version is more
strict.

Change-Id: I7daabf2ad587ff44fd6d8c66a02dbecfe519295b

Change-Id: I65f9ce6bc9851c97e25aaf5b131a4b319f00fed0
Reviewed-on: https://gerrit.libreoffice.org/2013Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I61c85b75b026e15541101b25cf254aa64c3e1762
Reviewed-on: https://gerrit.libreoffice.org/1949Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Id7c9ff4c7d7da830f9fdfb5046b627b5235c19be
Reviewed-on: https://gerrit.libreoffice.org/1951Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Id1cd40e3b9e2ae9ba0193708245c62f8ecd9cb96
Reviewed-on: https://gerrit.libreoffice.org/1950Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

I doubt any other app would intentionally do such a restart trick, so
it isn't surprising that the app sandbox designers have not taken such
a possibility into account.

So instead of crashing, display a dialog informing the user that LO
must be restarted manually once after installation (or after being
updated, presumably).

Change-Id: I0e6ea8384fe5a9b3a8b3ddb07743374a4c2300cd

Change-Id: I6250ec56c7b6d8f1da94b98e494f483c4076844c

Change-Id: Ifb38b49fb62d5fc85bcc6dfa7729bb87d3c7f8e0

Change-Id: I174be35302361bfa9985ad77a3c6496d858da472

Change-Id: Id857bfdfd7a2e9024eabdc2b63c02d3d61e7e4f6

Not yet implemented in the code, but my idea is that any functionality
that modifies the system-wide installation will go away in this case.

Automatically set if --disable-externsions, or if building a sandboxed
LO for OS X.

Should probably be set automatically also when just building a signed
(but not necesssarily sandboxed) LO for OS X? Surely installing a
system-wide extension should count as tampering with the
app. Especially if we can make also extension (scripts) be signed (by
locating them in the Resources folder?)

Change-Id: Id654bfaa6331535a66eae1bc6531a756085a3f06

Change-Id: Id29ccc9c009f0db5f1ee7483c412bb18578c24d3

Change-Id: I70b257fb2df8e0ea1ef2d94b3da7da7989e3535e

Change-Id: I0c65076d698865a653cac774a17f9db3d6f4d9ca

These two errors in the code contributed to the reported bug.  Let's
fix them.

Change-Id: If82a1bd4d1e27145b48e722b30388cc9dc4a8a6e

"Required line break" was eaten by the newly added code in text() to
ignore \'0a.  (regression from f593a2e4)

Change-Id: Id32687c40a17ddb99196635cedfc850182705799

Change-Id: Ia19087cdd27c54f8aa57253fbfeb19a13a7490b0

Change-Id: I16eb442fd65b3a2f3a44108f670fd364dc7a64c0
Reviewed-on: https://gerrit.libreoffice.org/1988Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Peter Foley <pefoley2@verizon.net>
Tested-by: Peter Foley <pefoley2@verizon.net>

And disable user interaction during type detection, since that would
cause the test to fail.

With this change, 'make check' works once again.

Change-Id: I2f45a2e962e45ee64f7984e794cff814fbfe6dab

Change-Id: Ifdc1716ed033f01bc298243c1e2dafd5736fac68

Change-Id: I417d76f7f7ab1b14a449ec0ee86bfd69effa68df

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

Change-Id: I2660d79b14455ffed62c755b8d83e70c2d7a99f2

Change-Id: Ia655743710778ea7d48a9b2221f22f55a4ccce32

Change-Id: I9cc1fdfa7acad6c233b68eb23dea39c58d4cecaa

Change-Id: Icb083795c9c00a9ca33c2a901b4183b81c98918c

Change-Id: I48bd329e1a29ce9cbf9840bf5e3cb48a92cb8073

Change-Id: I79db3d1b611315aab8a6c3a28d259a589dfa41d7

Change-Id: I09ba3b2c7502b56241aa957b05c443270c1cd56e

We still need to leave the MS Excel 4.0 filter name there as it's
used for Excel 1.0/2.0/3.0 file formats.  In the future we might move
these to ScExcelBiffDetect as well...

Change-Id: I8422e7470fbb0a14c219b7f67e3dfd4a34131eba

Change-Id: Ic0f5c585386f602bd51e006770b30cbb190a531e

Project: help  a35db526f704f87c082cba926ccb3559bb2d561d

Change-Id: I3838de932dea44accd3ec5a8eca3706f65058661

Change-Id: If93d8cb9d9d5ee4f9bc253a3c9ea6a063629dcb4

- changed osl_trace with sal_info

Change-Id: I6504abf50f6193db52d101ec856bcaf1ee2a982c

Change-Id: I103ca7d72e6bae6c20605719451579dd156504ce

Change-Id: Ib7951202399816a8bdb5806751857c6c0cafceff

Change-Id: Ie3901ac8dc2cb46f6d06cbc2c80760570a474bf9

Also switch BOOLEAN constructor from sal_Bool to bool.

old/new signed/unsigned storage situation:

-------------------------------------------------------
 SQL type | signed    | unsigned old     | unsigned new
-------------------------------------------------------
 TINYINT  | sal_Int8  | sal_Int16        | sal_uInt8
 SMALLINT | sal_Int16 | sal_Int32        | sal_uInt16
 INTEGER  | sal_Int32 | sal_Int64        | sal_uInt32
 BIGINT   | sal_Int64 | pValue (String*) | sal_uInt64
-------------------------------------------------------

When sticking an UNSIGNED TINYINT into an Any,
silently promote it to UNSIGNED SMALLINT (that is sal_uInt16),
else Any would take it as a sal_Bool and normalise to
sal_True (1) or sal_False (0).

When constructing an ORowSetValue from a sal_Bool,
silently keep it as an unsigned 8 bit integer
(that is understand it as a sal_uInt8).
This will work in most cases,
since when asked back for a bool or sal_Bool,
we'll give back the right value.
Only code looking at the type tag could possibly
make a "wrong" decision.
The main (hopefully only?) path
through which this would happen is
through an implementation of
  XParameters::setBoolean
  XRowUpdate::updateBoolean
that would use its sal_Bool argument
to construct an ORowSetValue.
So make sure each implementation
constructs a proper BOOLEAN so as not to get confused.

For authorship/copyright purposes, this patch is a cooperation between
 Lionel Elie Mamane <lionel@mamane.lu>
and
 David Ostrovsky <david@ostrovsky.org>

Change-Id: I3f1f08716127147f077bff4edb6ec558b1b09e09

Change-Id: I0a10cbb7eab77d215c15592a2121b65f1c9f3732