Change-Id: I958f6e80813a4e056b09225b16cea9ea2a3450ac

Change-Id: Ib9b06e843f3e44c3a1ec3c1a64335d2a6ebed810

Change-Id: I64995db8f9e913db5f4ab4e81359dd163bc29d15

Change-Id: I417a6d46dc72ee251b43e00836363b6ae07c2b4c

Change-Id: Ia840ae93a0582e96df8faa2507835dc4fbb7141d

Change-Id: I732bd280295097fe098d3175127eb4d8a026dc32

Change-Id: I579dd5fc6c71ac9dad2de622e9125b399f3e160e

Change-Id: I8ba88cf9b19612800beac5e200bbaeff6da32f97

Change-Id: I21aa786a9f214ba5137d35497318c4f088456845

Change-Id: I31c91bec6807b699333f646d758078ce5e69570d

Change-Id: I90ef759639c8b1410ec314fed4ff0fd877d8e224

Change-Id: Idd1f670dba9d88233a22b9f6ff084bf2ef41fb54

Change-Id: I99314136cac7f47a5adf8e0e29093ec9fbf4fd90

Change-Id: I8702c70eb2579781e2f524b2364191e1636370c5

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

More type-safe way, instead of void* everywhere
void* instead of sal_Int8 for raw memory / multi-use buffers
Fixed more issues than I care to count, but at least:
 - updates to a DECIMAL were truncated to integer because DecimalDigits set to 0
   maybe/probably also NUMERIC
 - setObjectWithInfo(... DataType::LONGVARCHAR ...) was passed as AT_EXEC, but the buffer was already free()d by then -> crash or wrong data

Change-Id: I0e6791a05b96fb345bfe3f911386263e6cfedde9

Change-Id: Ifa9b93b2daf0bb448711eb1bd3ebab69febf4f9c

Change-Id: I6de4e86f09be74518c9980d1b2347217cdcc4e02

Change-Id: I70f92224e22e9a9a1283564b5b1be7bf1e0240d0

Change-Id: Id2e8ad5b6bed1c184de6dccf7fa43254099fb958

Change-Id: I50c64d5fcf1d642052be5edbe64dde2c03c1eba9

Change-Id: Icf6a71900d79377cde84c2307ce85a9b3c96a54f

This reverts commit dd6c4f4d "fdo#46102: Load
Java scripts with class loaders that actually find them."  That commit broke
support for macros embedded in documents (as
new java.net.URL("vnd.sun.star.tdoc:...") throws a MalformedURLExcetpion), and
it looks like that commit was not necessary after all -- or rather that what it
tried to work around must have been some other problem that has been fixed
meanwhile.  "It is unclear to me how the Java script provider shall ever have
found the script jars in the past" indicates that something must have been
fishy, and what I failed to notice back then is that createURL creates
java.net.URL instances with a UCBStreamHandler that does allow to obtain content
from weird-looking URLs.

Anyway, with that reverted, all three following scenarios work on both current
master (towards LO 3.7) and libreoffice-3-6 (towards LO 3.6.4); I haven't yet
come around to test on libreoffice-3-5:

1  Stock macros, "Tools - Macros - Run Macro... - LibreOffice Macros -
HelloWorld", running all of the four "helloworld.bsh", "helloworld.js",
"HelloWorldPyhton", and
"org.libreoffice.example.java_scripts.HelloWorld.printHW".

2  Per-document macros, loading test.odt attached to fdo#49517, then "Tools -
Macros - Run Macro... - test.odt - HelloWorld", running
"org.libreoffice.example.java_scripts.HelloWorld.printHW".

3  Extension macros, installing ScriptDispatch.oxt attached to fdo#46012 as
shared extension, then loading StartScriptDispatch.odt attached to fdo#46012 and
pressing the "Start Java via ScriptProvider" button.

Change-Id: I31cd16b3720ffeb1058722d4d1fdffb773f8a067

Change-Id: I6b26f2805d08d2eb1b28ade459d38a1c6895addf

Change-Id: I347672a2175cf7a0304cf5d6c0f8f3f6afa92cd4

Change-Id: I0ddc4d343882248d208c9f96366625bcbe6ac4f7

Change-Id: I702c044fdf510c67364f2fc32889ca394583edf6

Remove tabs too

Change-Id: I8f7b2148f95e5694ad17d1a1b98001f1c803ce7e

Change-Id: I1c571327f977a95fc4193567142e3897cbfc3e14

Change-Id: I6ac3940fb0b07d280998a56d5eaede0909f14bce

With ucbhelper::Content now requiring an XComponentContext during construction,
calling "unopkg add" with an .oxt that requires license acceptance would lead to
an assertion about a null XComponentContext, as doChecksForAddExtension calls
the XPackage's checkPrerequisites -> checkLicnese -> getTextFromURL, which
creates an ucbhelper::Content with getMyBackend()->getComponentContext(), but
early release of the "tmp" manager would already have caused disposing of that
backend, which clears m_xComponentContext.

I assume this problem had always been lurking silently in the code.

Change-Id: I9f59c612fe3831b2f6dd832ef2f0505b6590b8e0

Change-Id: I119f008734e4978d6bcf5f786ae3604db5c0f8a9

The "faux bold" make the bold font in Asian ugly & unacceptable,
Adjust & improve the "faux bold" to make the bold font better.

Change-Id: I2e02156ffc30629476b80134ffb0b50e793f7ead

Hmm, this did not work as expected. The submodules seems to be a bit
error-prone to get git into inconsistent state :-(

This reverts commit af8d133e.

Change-Id: I382b2a01ec5c7bbe5a3faf7333c161e8a76fdd27

Change-Id: I13d08b9ecf86bf78389effb2bb6f167f74f37827

Change-Id: I16c555e87f8df19a74c8d34f21bce4570c1d756f

regression from f6a34255

Change-Id: Iabfaf92629cd4d53ab7af5f3e3013eb81bb8104d

Change-Id: Ie54528ccf641b380eda1d1bb12b39d0536c4d17b

Change-Id: I39ce208c1e5dd307631c628217ff596632753f23