Can't assume that the necessary entries are in the Registry. Need to
fix it to start soffice explcitly before running the VBScript.

Change-Id: I809be88a2fe2afbda1f087501785ec7a9e2a358b

This patch fix regression caused by e87cc12e and allow
table borders rendered in the left or right page margin.

Also add another test case (testTableExtrusion2) to assure
inner table can't have wider border than outer table.

Change-Id: I7a86b379dee08fb2f23385183a42d0ebde007370
Reviewed-on: https://gerrit.libreoffice.org/54862Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Hung <marklh9@gmail.com>

First step: Find all constructors/derivations, mark
all of them.

Removed two-value-constructors, adapted code as needed

Reduced constructors for SdrModel/FmFormModel
to a single one.

Removed PathName for List creation, this is not
needed and anyways all calls used the default
SvtPathOptions().GetPalettePath(). This is also
true for usage of IsFuzzing() that is also part
of the default creation process (without path).
All usages that need an extra-List were setting
it after construction explicitely.

Removed UseExtColorTable. This prevents a single
List to be not created by default, the ColorTable
which is replaced later by all callers that used
this. This is not needed since the default
ColorTable gets constructed just by default, no
expensive stuff is triggered (e.g. loading the
ColorTable). Thus now a default ColorTable is
created and kept for a short moment, destructed
again when a ColorTable is explicitely set.
Doing so is also more safe - it avoids not
creating a default-ColorTable and then not setting
one (what would be urgently required).

f23c24a8548d5246b77b1cc359ba89564538e81a
f124468c3898c5842d37123bdeb87d79a2b19c62

Change-Id: I865de4bb23f673c6684d83c2c6390439506dc5b6
Reviewed-on: https://gerrit.libreoffice.org/55028Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>

Change-Id: I1ff31d692100695a706bf128c18c4e3ae8b55ce3

Change-Id: Ic197a9573968fb252cb52cc5089f9140d5375d3a

Written in VBScript, yay.

Change-Id: Ibbdba804939c2646aef8f8a2bb3781eaf1a6d208

Change-Id: I4b0b119af356f38f359f2ba5afa6081533790443

Don't need the mbFromOLE boolean flag and the special "FromOLE"
parameter passed to the InvocationService::
createInstanceWithArguments().

Change-Id: I05e10a78955d87cb7c37e198c60c3ddcfdbc4275

Change-Id: I2723146f2c549c630dfa0e5da330af228cb305a0

Corresponds to the Author attribute of
css::document::XDocumentProperties. I.e. the initial creator of the
document.

Change-Id: I07d3ce9dfb87900948d2bb7af14109b17546fb4c

Change-Id: Ie62c47a0b60df5b7a7237cce981e850cbbe5aee9

For instance when opening a Calc Document through ooo::vba::excel::
XWorkbooks::Open(). Instead just let the function return null. It does
seem that callers are prepared for that.

Change-Id: I7136133155f95a696b5ed3e661a9adb98396c9c5

Change-Id: I565ce46c01edfe16d5639cc62cb5a4ca996db349
Reviewed-on: https://gerrit.libreoffice.org/55098Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: Ic76fc43fc521a6fd6642e22b71c311370788d4aa

Enables finding out anywhere whether the thread is processing a call
from an Automation client. Not sure how I have managed without this
until now.

Presumably the Invocation_Impl::mbFromOLE variable in stoc can be
replaced by a call of comphelper::Automation::AutomationInvokedZone::
isActive().

Change-Id: Ib79ec5f6dff17af25c8539d2907c7cd5d7b9a62c

Also, it is UnknownPropertyException that we need to catch, not
RuntimeException. Did I not actually exercise my change to getValue()
back in February?

Change-Id: If13eaa9bbecd15f5330a4102ae932f2ec0c7ecd4

Especially, this happens when an Automation client wants to open a
Calc document. Equivalent to the code for the same situation in
getCurrentWordDoc().

Change-Id: I209a72dcae49f18cd265e0c6c2790618e1ebb4a1

Parameters come in in reverse order in pdispparams. There might be
less parameters than expected. In that case, assume the missing ones
are "optional" (but can't be marked as such in UNO IDL), and fill in
the rest with empty Anys. There might also be more parameters than
expected. In that case, assume the oovbaapi UNO IDL hasn't kept up
with added optional parameters in MSO, and just ignore the extra ones,
as long as they are empty.

An example: incoming parameters: <12, 13, "foo/bar.tem">

Expected paramters: (string filename, int something, int
somethingElse, Any whatever, Any whateverElse)

Here the existing incoming parameters are placed in reverse order in
the first three outgoing parameters, and the rest of the outgoing
paramters are passed as empty Anys.

Another example: incoming parameters: <EMPTY, TRUE>

Expected parameters: (bool flag)

Here the TRUE is passed as the sole outgoing parameter, and the
incoming EMPTY is ignored.

Still an example: incoming parameters: <"foo.doc", TRUE>

Expected parameters: (bool flag)

This throws an error as the incoming non-empty extra parameter
presumably indicates something important, but there is no
corresponding outgoing parameter to pass it in.

Change-Id: Ib04f9701099ecb899e792d99ff86588022b3bbf6

If we have too few parameters, fill with empty ones, as before. If we
have more paramters than the called method expects, but the extra ones
are empty anyway, ignore them. Do all of this in
convertDispparamsArgs(). This improves interoperability with typical
Automation clients.

Change-Id: I47376993dc10b401e4c349e19b2bbe4be9f8f444

Make it easier to search for a specific class and function in the
output by outputting the 'this' pointer first, not between the class
and function name.

Change-Id: Ia6e087e3a4be9e701c418aedb9b6af5fd4f6e828

Largely parallel to what we do for Writer.

Yes, there is a fair amount of duplicated code now for the outgoing
("sink") stuff in sw and sc, that should be factored out (to
vbahelper, probably).

Change-Id: I8df4a81c3b9043e8d6b0b206e3c04660205987c7

Change-Id: I4d43bdd6789bdf01cd9b7b38377b19294a544477

Change-Id: I50ba5482742296609187e8b41bd3a2910c44ca4e

so that we flush out various code using Bitmap, in favour of using
BitmapEx.
This is part of the process of making Bitmap largely an internal detail
of vcl

Change-Id: Iaf2ead5e3d9960838723fb55b812b97108093d74
Reviewed-on: https://gerrit.libreoffice.org/55062Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: Icee6f97abf9182621e43a0039b52c2f2e141fa01

Change-Id: I4360c588ee4866f4e680095c0cd0e8f7aceaa6d7

Change-Id: Ia5f8c0fcc8d1eb9f6ec3db82b947a16ed3762d01

Like the other similar attributes and methods added lately, they just
forward to the corresponding attributes of the "active
window". Whether setting and retrieving such then actually does
something useful or not I don't know. My main concern is that
Automation and COM clients at least won't complain and abort because
of unimplemented APIs.

Change-Id: Ia8d22e3137d314268ac6771bb355e9f0686f52dc

Change-Id: Ib230e730f68a30b82915ed6d7898bf1c02690b70

Seems to be commonly called by 3rd-party Automation (and VB6) client
code.

Change-Id: I29ee5e7d95f3da2ffae0fac44151148be6e272ee

It seems to be something 3rd-party VB6 clients expect to be able to
get and put.

Change-Id: If5079da8ba99fde74b12b9590737d575f6636210

Change-Id: I785c115ab7bcb7cfddc8e79bd5d31278f0c544dc

Change-Id: I13601337a78d22eca1df185fb4d51b34a90925f3

Change-Id: I1c706a2139cb2596969c6c1d166d3f9fe9f91d39

Change-Id: Ia2a0ade0af45f1ba99b0cfa860bd1986edcf272e

They are supposed to be emitten when a new document is created, an
existing document opened, or a document is made the active
document. (Hopefully our SfxEventHintId::ActivateDoc matches the last
one semantically.)

Change-Id: Ic53285fc3d1b9a61ababf77f06477081cef20f27

Change-Id: Ib7fcdbe934b66971995574226f982a6865faab1b

Change-Id: I428c2bbaa273d893fa5a3cc42bb7f3d060f375ad

Just call Open() with the same parameters. (Most of which are
cheerfully ignored.)

Change-Id: Ia9b980bf870bac04fab7e23843d29f66d5859037

Change-Id: I9c7a17aa9bdbbba29cd12a0e3d09c9047e9b5678