Change-Id: I26d49db0207b3f4f64aa9698da4cf3567d195834
Reviewed-on: https://gerrit.libreoffice.org/33800Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>

Change-Id: I8a3b138c051d3cddf25855a635262311669bdddc
Reviewed-on: https://gerrit.libreoffice.org/33798Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>

In a build with -fsanitize=address, this fails with:

Change-Id: If8581363a395af78bbbe00dd656290aea53af330
make: symbol lookup error: instdir/program/libfreebl3.so: undefined symbol: __asan_option_detect_stack_use_after_return

Change-Id: I4a34f03fdab4626bdbf9b254986b0953ecfdffa7

Starting from MSVC 14.0, the directory table layout of VC++ Runtime merge
module changed. As consequence, all MSI produced with newer compilers,
including MSVC 15.0 (aka VS 2017) are broken in term that the VC++
Runtime DLLs are installed in the wrong directory, e.g.: C:\System64.

According to the specification for merging merge module (msm), see:
"Authoring Merge Module Directory Tables": [1], custom action 51 (set
property) must be emitted for every directory name in the merge module
directory table if the directory name is starting with the standard
directory name.

Quoting it here:

"
When a predefined directory is included in a merge module, the merge
tool automatically adds a Custom Action Type 51 to the target database.
The merge module author must ensure that a CustomAction table is also
included. The CustomAction table may be empty, but this table is required
to exist in the target database and ensures that the modified predefined
directories are written to the correct locations. For example, when a
system directory is included in a merge module, the merge module author
must ensure that a Custom Action table exists.

Note that the matching algorithm for the generation of these type 51
custom actions only checks that the directory name begins with one of
the predefined SystemFolder properties. It does not verify that the
directory name exactly equals the directory property. Any directory
beginning with one of these standard folder names gets a type 51 custom
action, even if the rest of the name is not a GUID. Authors need to take
care that this does not generate false positive matches, and unintended
custom action generation, on derivative primary keys that begin with one
of the SystemFolder properties."

Rectify the problem by analyzing the directory table from the merge
module, checking whether the directory name starts with the standard
prefix name and if it is the case, emitting custom action 51 to set this
variable to the standard directory name.

Implementation details:

We use the existing facility for emitting the custom action table events
including referencing them in the corresponding sequence tables. Given
that the specification above doesn't mention what sequence table should
be referencing this emitted custom action, we reversed engineer this
information from WiX toolkit. Merging the VC++ CRT module with WiX
toolkit and investigating the resulting MSI with Orca MSI reader, reveals
that these sequence tables were referencing from these sequence tables:

* AdminExecuteSequence
* AdminUISequence
* AdvtExecuteSequence
* InstallExecuteSequence
* InstallUISequence

Replicate this behaviour here as well. Note, though, that custom actions
are generally not referenced in AdminUISequence and AdvtExecuteSequence
tables in LibreOffice MSI building tool chain.

Rendering of the custom action is achieved by programmatic emulation of
custom action in SCP module. Consider this similar SCP module based
action:

  Name = "MigrateInstallPath";
  Typ = "321";
  Source = "shlxtmsi.dll";
  Target = "MigrateInstallPath";
  Inbinarytable = 1;
  Assignment1 = ("InstallExecuteSequence", "", "CostInitialize");
  Assignment2 = ("InstallUISequence", "", "CostInitialize");

We instantiate the following data structure to emit custom action
System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1:

  Name = "System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1"
  Typ = "51"
  Source = "System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1"
  Target = "[System64Folder]"
  Styles = "NO_FILES"
  Assignment1 = ("AdminExecuteSequence", "", "CostInitialize")
  Assignment2 = ("InstallExecuteSequence", "", "CostInitialize")
  Assignment3 = ("InstallUISequence", "", "CostInitialize")

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa367787%28v=vs.85%29.aspx

Change-Id: I2fbd37ff63298d99b2ba1b6afe6e875f56d8e378
Reviewed-on: https://gerrit.libreoffice.org/33366Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>

This is a temporary fix, to allow testing of the new
windows IDE, without disturbing the existing one.

Change-Id: I4c59427541878acb6dd382af42deb7c0c952bcf9

Change-Id: I3b57086349d039087dc9395f7af63f8e8fbf1bab

PresenterSlideShowView::PaintInnerWindow has a mbIsForcedPaintPending flag
which is used to throw away the console canvas, but for other backends the
paint occurs at a much different time after a clear has a chance to get
triggered, while for gtk3 it happens as its being setup.

hack around this presenter console weirdness by skipping the initial
paint for this salsysobj case

Change-Id: If1b23600ef07241e52d92bd5eb38b9e90d9ed192

Sometimes gbuildtojson does not get rebuild, and thus
delivers unexpected json files (old keys)

Change-Id: Ib4bab170ed5a2ab5c112d19af144f2551e608278

Change-Id: Ie13a5e04207475794fef75c568786f37eb2c406f
Reviewed-on: https://gerrit.libreoffice.org/33230Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Heiko Tietze <tietze.heiko@googlemail.com>
Reviewed-by: Akshay Deep <akshaydeepiitr@gmail.com>

Change-Id: I89c809a220efc006d3b5b0675c050ff07cb2dbfe
Reviewed-on: https://gerrit.libreoffice.org/33380Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Change-Id: I287f166291a905c9f4d166bf07c09de93184bf87

Change-Id: I9dc03760831f3f1ff433c67abde95060d533ea14

Change-Id: Iffab8e3d8ecaad835d5f0cce68ede4eaea1547a4

This reverts commit a4d5d69e.

Once is enough.

Change-Id: Ie16af2d0943cec6374307e9afb09cd47ed6d7043

Change-Id: I8b7611d6fdc55fc8cd9551e129a2e03e58682229

Change-Id: I53699ef386dad99b38559defe985057492a5df76

Project: help  732cd669a0f593eeaacaa4f67bce5947a431c0c1

Adapt hids after popupmenu xml conversion

Change-Id: Icf119499f75a838ec6159ae19c33e16be9967da5

Change-Id: If59ecb4ea92d9daf423aef870e79248f5bc93e6d

Change-Id: Ifcce63b975fb7c4ac7e7545e3eadcc6f7f12e466

Change-Id: I6e68a6728eed108c7670ebef6073394de3f53e6b

Change-Id: Ie261d5412c510c045b4d93a6bf1a3d4cf4371897

Change-Id: I39d443e582a6e82947f9c833b157f137a082a358

Change-Id: I8bd752814994fedac17fe0d002b415902c276b20

Change-Id: Ib64d5b5fa1bf13a484adb296b969d1b96387f0c6

Only on macOS, the SDK used to expect javac etc. in a Commands sub-dir (which
Apple's JDK 1.6.0 has but Oracle's JDK 1.8.x don't).  However, at least both
Apple's latest JDK 1.6.0 (as available via <https://support.apple.com/kb/DL1572>
"Download Java for OS X 2015-001") and any recent Oracle JDK 1.8.x (like
jdk1.8.0_121.jdk) have a Home sub-dir that contains a "standard" sub-tree with
bin sub-dir etc., like on other platforms.  So consistently make the SDK use
that instead.

This removes the JAVABIN Make variable from settings.mk.  It is assumed to not
be used by client code.

Change-Id: Ie0ad647f489528444dfd399c2f00500b772d3288

The problem in callnk.cxx was that when selecting 1 char to the right
using keyboard, and exiting field boundary, nCmp pointed to previous
position (inside field), and then compared to position to the left
(which also may be inside field), thus missing call change link (and
read-only state change). Seems that this was a mistake in commit
740efbb1.

In pam.cxx, if cursor was to the left of field, and then selected
1 char to the right to cross field's boundary, then both PaM's point
and mark had same fieldmark, but point was outside, and mark inside,
and as code didn't check this condition, so read-only state wasn't
properly set.

Unit test is augmented to check the second problem.

Change-Id: I7323e53eeb261b4ccdc0f9e36cc0956b373f104d
Reviewed-on: https://gerrit.libreoffice.org/33790Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

Change-Id: I391554dff6f92d7639d0a391f4b00437c7648a6b

The #include was introduced in
96c1ae1d with an #if on
HAVE_FEATURE_OPENGL, but that #if was later removed.

Change-Id: I70f839d5224e0a77a1640a5e23cbe64656c9cb1b

This reverts commit 4739b31d.

Apparently, passing a param of type css::uno::Exception to Any
will record precisely a css::uno::Exception in that Any, losing
any subtype information, which this commit changed.

Change-Id: Idc5fbdcd6d1a11b7607995c1d492ffc829879566
Reviewed-on: https://gerrit.libreoffice.org/33718Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>

Add missing recommended formatting options in Compatibility.xcs
Correct ConfigItem rootnode path for SvtCompatibilityOptions_Impl

Change-Id: I1e56b276bf4a0801ab724baaecda53168783b27f
Reviewed-on: https://gerrit.libreoffice.org/33786Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

so that e.g. the xor cursor in csv dialog can be seen when moving
the mouse across the ruler

Change-Id: Ia2f367d5f610d486a8e10b6bc278cbc8029cf2a1

since the latter is rather slow

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

Change-Id: I0d913699c3aac84f2bdfe50f9dec6e6921242744
Reviewed-on: https://gerrit.libreoffice.org/33776Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>

all the call sites are passing an uno::Exception subtype

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

So add to them instead of just assigning. In the bugdoc the initial
values were zero, but maybe in some other cases they aren't.

Change-Id: I3d399fe4aab9260817f171d4e69388a19eb85d21

just the simple and obvious case for now, of a local var being allocated
and deleted inside a single local block, and the delete happening at the
end of the block

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

Change-Id: I22af89b920d43f3fc5f0fff02070f288bfa59fb4
Reviewed-on: https://gerrit.libreoffice.org/33702Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Siegmund Gorr <siegmund.gorr@cib.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>