Change-Id: If1b4125fa0757fdcdff5466bf9b99791c930ffa6

Project: help  cff95cb4ac050718c0ac7c9e37c5946ce4467c95

this one nearly killed me

Change-Id: I51f14017940a275cca33dacf6f42438da43f46bc

Change-Id: I8c071dd76e9ea84ee9aaf9cdd06b2103df4fd789

Change-Id: Id30805f09bc359c6f66d87f050427c0e586ec93d

not only one.

Change-Id: I1f611dda6a98fb6244409c0cd1fc87fc9dfaa8c3

Change-Id: I709305d4ec3c37d3fc1c2c911551174f8cfbb883

as opposed to table columns or other expressions.
So it makes no sense to slap a table name on them.
Notwithstanding HSQLDB 1.8 (our embedded database) bugs.

Change-Id: Ib5d0b1479e29b9efeafca9ebc2eb7ed8e0f42b79

Change-Id: I8660ae764c7dd51b8d780929effe895243e4fc4c

the layout changes for the basic IDE ( for the object browser and object
catalog ) seem flacky, I have seen since those changes have been introduced
some strange ( but random ) behaviour ( like the odd unrepeatable core ( maybe
related to this ) and also sometimes Modules appearing in the tree under the
wrong nodes etc. I'm no expert in the basic IDE code but this patch seems to
fix the problem.
However there is one drawback, in the core inducing scenario the tree view
( object catalog ) dissappears, this is because the patch suppresses the
problematic layout in this case ( as the layout seem not to be currently able
to deal with 'no-existent' (recently) deleted current window )
Probably in this scenario a fallback currentwin (instead of nil) could be set
this would behave better but ideally. Ultimately the layout class should
probably be modified ( possibly redesigned )

Change-Id: I9d1e23bd6fc4aae32aa78da8278c318f7051136a

...post 68e2a4e4 "Revert 'Visibility doesn't
seem to work as we want in Apple's Clang.'"

Quoting <https://developer.apple.com/library/mac/documentation/developertools/
Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html> section "Symbol
Visibility and Objective-C:"  "When building for x86_64 OS X or for iOS, symbol
visibility /does/ affect objective-C classes.  [...]  This means that if a given
class is intended to be usable outside the library or executable it's defined
in, you need to ensure proper symbol visibility."

The chosen syntax works at least with both --en/disable-64-bit "experimental"
(Clang-based) builds on OS X 10.8.  Hopefully, it also works for baseline
builds.  (Also, it could be that a more fine grained use of
SAL_DLLPUBLIC_EXPORT/SAL_DLLPRIVATE would be useful, but with the current setup
at least linking of Library_vcl against Library_AppleRemote works.)

Change-Id: Iff4fe9e50d1400c83879f62fe29b35bd19d58eb8

Change-Id: Icd832483228812cf3c8ddff3c0d56090f3b17856

When exporting a Frame that contains an eDrawing, check whether it's
a diagram and export it properly if so.

Exporting the diagram means adding the relations for the four
mandatory files (data, layout, quickStyle and colors), and the
optional one (drawing), and also writing those from the imported
XDocuments to the respective files.

If the drawing file exists, the data XDocument must be updated before
writing it to disk, as it contains a reference to the drawing file
that must be updated with the new relation id.

With this change, the files saved to docx that contain SmartArt will
be properly opened by MS Word without data loss.
LibreOffice won't be able to properly open saved files though, as
it requires the theme file to be present, and it's not being
exported yet. This is planned to be fixed in an upcoming patch.

Change-Id: If69ca9815dd076597a37937fe2af8ed4d1c7acc5
Reviewed-on: https://gerrit.libreoffice.org/5896Reviewed-by: Thorsten Behrens <thb@documentfoundation.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: I8484be77353b288b6dfaa0d86fa4b325fd1187a5

Change-Id: Ie3e2f6c9d1b8ff75b8450e8c377073821d0f1b37

Change-Id: Ib9a706a7ecb20bbee283e566f94fd22d412027e7

Change-Id: I516a4e9da4e670f0fdbbfa0f793ccfb308189534

Change-Id: Ib71adb544c02b764fe85b2fd32fda2097efc41d0

Change-Id: I879a47720f337b57038ac3207cb466aa42d0beeb

Because mtvelements.hxx is very slow to parse by the compiler, and
cellvalue.hxx is included everywhere. Hopefully this will speed up the
compilation time of sc...

Change-Id: Ic9a9b8483c8325e4a91021f071f2391db8b57806

Change-Id: I6c7cfd8c1e0d88ad99f5e2ca15758eab033ec50c

Should help to avoid potential memory leaks.

Change-Id: Ic9518af17d818eb439358cb86afa03e80ab9799e

Replace an events loop at the communication service with single-shot
connection workers. This should help to avoid deadlock behaviour in situations
when user quits the connection to one server and tries to connect to another
one. The events loop required synchronization blocks which cause ANR in
the situation described above.

Change the server connection interface to contain a connecting stage
in a separate method. This is more just-in-case measure for situations
when the connection constructor shouldn't be blocking.

Change-Id: I941a4b67d965f6b1f76bc9975818e82aea12bf00

Currently, when the sidebar is showing, and we hold the handle to make
it wider/narrower, if we move the mouse much to the left (so that it
can't become any wider), and now move mouse pointer to the right (while
still holding the handle), it immediately begins to shrink.

Ideally how it should behave when we move the mouse much to the left is
that- the sidebar should begin shrinking once we have the mouse pointer
over the handle again and not immediately.

Change-Id: Id17dc19e6e1ad02fb7879ace9a2e092ac0128693

Triggered by aa9af08b which explicitly sets
rSet.Put( SdrTextAutoGrowHeightItem(FALSE) ); so there is something set on the
style which is being overwritten.

The code here resets the style to the default of "true" before going on to set
it to the explicit "false" again. In that window of time the master shapes
listen to the property change, on being set to autoheight they resize and on
being unset, they remain stuck on their autoheight calculated size.

Change-Id: I567a791b2bbbcb3a1a111633fabf509142984645
Reviewed-on: https://gerrit.libreoffice.org/5887Reviewed-by: mhofmann <borim7@web.de>
Reviewed-by: Thorsten Behrens <thb@documentfoundation.org>
Tested-by: Thorsten Behrens <thb@documentfoundation.org>

Change-Id: I7495f86cb35b6f712cfb7d603f022f6f6c407266

Change-Id: I2eaa32e0ec09b239e03d3efa776f5b47c2fb5c6d

Would have caused eternal recursion, probably was intended to use
throwGenericSQLException or similar, but throwing the correct
exception is probably cleaner anyway.

Change-Id: Ic4afa623bfcd57eb68ef6cfbf737862fd40eaaa2

Currently this causes some (all?) gcc to break.

Change-Id: If6d802f5a763904d06107fa99731dd4512f18052

Change-Id: I3fd7508a3b9c362661ad1bfa66901be9f938b8e6

... where everything is inside some artificial "LibreOffice 4"
directory that is set as WINDOWSBASISROOTNAME in openoffice.lst.in

Change-Id: Ib04f84a8064739e0ea9d11b3b79cc1fa167a06e5

Change-Id: I81909e4542bd5e8d1f8ae182c3c17f9bbea9745d
Reviewed-on: https://gerrit.libreoffice.org/5881Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>

Change-Id: Ib1074e3025680306c0a8bf7dcff651cefdcb90ba

Change-Id: I02881a2a7ab3178521388b76e2413b7e1cd6c443

Change-Id: Ia4fa44c2382f6d1f5a6b3fed533f401bcb03be53

Change-Id: Ia156b27d944bf419a2e0bd45fa65efd4b7f89404

(This is to comply with the updated API specification.)

Change-Id: I4542fecc78a6e64011276dafc72c31d5533af1ab
Reviewed-on: https://gerrit.libreoffice.org/5923Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>

Change-Id: I7a9354ecd35a70a005c6c50e38d27de9b33332bd
Reviewed-on: https://gerrit.libreoffice.org/5922Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>

This is to reflect the JDBC specification where invalid column names
result in an SQLException.

(The drivers within LibreOffice are being updated to reflect this new
specification.)

Change-Id: I76cdf9d5d15d55b534b28219b541ff9190365f9d
Reviewed-on: https://gerrit.libreoffice.org/5921Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>

Change-Id: Ia6ea53f1a9e1c575606901e173bc952449135522