Problem is that the TextBox SwFrmFmt of a draw object gets a FLY_AS_CHAR
anchor set, which is then not updated later before nodes are deleted.

(regression from c7307c77)

(cherry picked from commit 9dbb88fc)

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

Change-Id: Ibdc0596181711e748e4b1f59ffc27629c5423e66

Regression from commit 0761f816 (123792:
complete annotations on text ranges feature, 2013-12-19), the problem
was that the added additional IDocumentMarkAccess::GetType() check in
lcl_FindDdeBookmark(), which means that the function no longer finds
bookmarks with the matching name, only real DDE marks. This is a
problem, as SwTrnsfrDdeLink::WriteData() depends on the fact that
sw::mark::Bookmark inherits from sw::mark::DdeBookmark. As a result, the
fast IDocumentMarkAccess::GetType() (that intentionally doesn't handle
inheritance for performance reasons) can't be used here.

(cherry picked from commit e06e2cb1)

Conflicts:
	sw/qa/extras/uiwriter/uiwriter.cxx

Change-Id: I2b7a07c18b641ac991f3227812a609dedc960e08
Reviewed-on: https://gerrit.libreoffice.org/17447Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>

The marker used in Word to identify table cell division was being
included in the track-changes deletion from the following cell if
the deletion was the first node in the cell.  This would cause the
two table cells to merge into one when changes were accepted by
Word.  (Problem not seen in LibreOffice itself.)

Change-Id: Ia98017cbba7d3a43b67764ae0fa6447b7e90ca86
Reviewed-on: https://gerrit.libreoffice.org/15340Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-on: https://gerrit.libreoffice.org/17142Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>

Else, on any action done directly (not through the
FormControllerHelper) on the controller and raising an SQL error, this
would silently swallow the error message, and the operation would fail
without any message to the user.

E.g. when validating an insertion or modification in a grid control by
moving the cursor to a different line (as opposed to clicking the
"Save Record" button).

Change-Id: Ie569d9c826609f803f7b312c0469907155558ef2
Reviewed-on: https://gerrit.libreoffice.org/17268Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>

This avoids arbitrarily switching to the first form in the document,
which would do a (premature!) save to the database of the
modifications pending in the active form. This may lead to a database
error, when the data is not in a shape to be written to the database,
e.g. when on an insertion row and not all mandatory fields have been
filled in. This then pops up an error message to the user.

Change-Id: I30bb533598ca707b892bb7155e54ce05d4ddf275
Reviewed-on: https://gerrit.libreoffice.org/17269Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>

This disable will be done, in a better way, by the call to
BrowseBox::MouseButtonDown below, *after* the destination of the mouse
click has grabbed the focus, by a call to DeactivateCell().

If this is done here, while the "source" controller still has the
focus, then the window's Disable() method will try to pass the focus
the the "next control". However, the "next" control may belong to
another form, and this will do a (premature!) save to the database of
the modifications. This may lead to a database error, when the data is
not in a shape to be written to the database, e.g. when on an
insertion row and not all mandatory fields have been filled in.
This then pops up an error message to the user.

Change-Id: I38b1850319691b34232e51f131f8d099dc4a9114
Reviewed-on: https://gerrit.libreoffice.org/17270Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>

by jrb, oops

Change-Id: Id722533edae72d4849129e339bd6cca265d3c35c
Reviewed-on: https://gerrit.libreoffice.org/17578Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>

Change-Id: I90d1a5696e0c964d7e5df8be14781a4e292d9c12
(cherry picked from commit 467c482d)

Project: translations  ee62796699c03b6d31184697010db569f6dae8de

update translations for 5.0.1 rc1

and force-fix errors using pocheck

Change-Id: I53ea5774b8c02e329e916f8a533051d6720a5028

Instead of painting on the vcl::Window directly, take a
PaintBufferGuard, and use the vcl::RenderContext of it, that may be
either the vcl::Window or the toplevel frame's buffer.

Trigger the paint of the buffer by informing the guard what area was
painted. In case of direct painting, both the ctor and the dtor of the
guard is a NOP.

This means that finally we can also assert Invert() calls on the output
device, so that direct paint can't happen when double-buffering.

Also:

- make PaintBufferGuard visible outside paint.cxx
- move buffer paint logic to PaintBufferGuard

(cherry picked from commits c85b2511,
a6c7a0bf and
c64a7ce1)

Change-Id: I0322563369dc63b3c49061cbe7c4a911cb13a2e2
Reviewed-on: https://gerrit.libreoffice.org/17576Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins <ci@libreoffice.org>

Change-Id: Ia8c7da1e321f363efee2d60b29078b35fcbe1dcd
Reviewed-on: https://gerrit.libreoffice.org/17571Reviewed-by: Eike Rathke <erack@redhat.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>

Unicode collation ignores control characters and other specific
characters, see
http://www.unicode.org/charts/collation/chart_Ignored.html
and thus is not suitable to be used for Equal/NotEqual operators.

Change-Id: Ib84713e1da59d92e07bc974d93b6def8217bb067
(cherry picked from commit 1e5e7b93)
Reviewed-on: https://gerrit.libreoffice.org/17240Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Hence we need a separate string as header in the dialog. Unfortunately I
did not see this when applying 0cf38e7d

Change-Id: Ib60cef29e663e71a25849df1d5a926f0e871bb8b
(cherry picked from commit ffebdead)
Reviewed-on: https://gerrit.libreoffice.org/17239Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

I missed a similar bug lower down

Change-Id: I673c69dd1d36cc1b502a7de7821a05d859313aac
(cherry picked from commit 0c08cb23)
Reviewed-on: https://gerrit.libreoffice.org/17537Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

Bug introduced by commit fb14be5f
"create new 'enum class' SotClipboardFormatId to unify types"

Change-Id: I3febb927f658ac27d2b864869775db3b71940a5c
(cherry picked from commit f7d65b04)
Reviewed-on: https://gerrit.libreoffice.org/17536Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

tdf#91278 related

Change-Id: Iab4728b07649bcbb1beb372e68369f3762b13a5c
(cherry picked from commit 01eea7fe)
Reviewed-on: https://gerrit.libreoffice.org/17264Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: I6b226f8e992b3a2b6bcebc44b36ca1f2f06a128e
Reviewed-on: https://gerrit.libreoffice.org/16894Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
(cherry picked from commit ebdc15f9)

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

Change-Id: I476f0ffaef383f3227c0c12b50fcdebf393190f6
Reviewed-on: https://gerrit.libreoffice.org/17487Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
(cherry picked from commit dea885f8)
Reviewed-on: https://gerrit.libreoffice.org/17561Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: I1dc34eee645b77537517e147b86599cfe74f09a9
(cherry picked from commit d97cc94a)
Reviewed-on: https://gerrit.libreoffice.org/17560Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: Iba3fd58374a550f3411b02f029f12f4509fb6048
(cherry picked from commit f73e1f50)
Reviewed-on: https://gerrit.libreoffice.org/17559Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: Id0258fe0db89aa06b91233ae2052f018d606cc74
(cherry picked from commit 6d9ddfb9)
Reviewed-on: https://gerrit.libreoffice.org/17558Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: I67d0dcb48d1843587abbc1dc0f7da1f8057b281e
(cherry picked from commit 1c28c59f)
Reviewed-on: https://gerrit.libreoffice.org/17557Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: Ia0423dac5309aabc5e81357cf4f67b5ee14bab31
(cherry picked from commit 3bc00eca)
Reviewed-on: https://gerrit.libreoffice.org/17556Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: I6b1a39918e6c8c67712be2c8e9907266dcfefedb
(cherry picked from commit 80a92134)
Reviewed-on: https://gerrit.libreoffice.org/17555Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: I85c7cc01113bc4ac810c450a6460059463cc8e03
(cherry picked from commit 450727fd)
Reviewed-on: https://gerrit.libreoffice.org/17554Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: I088633e4cff278e1add8eeea8828f9ba9c9fb140
(cherry picked from commit c7d66949)
Reviewed-on: https://gerrit.libreoffice.org/17545Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Ic45f65d10835eb39b6709e7adeed1392905ea631
(cherry picked from commit f4a2c604)
Reviewed-on: https://gerrit.libreoffice.org/17564Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I66b92146757352408a331f9e23289839f443ff79
(cherry picked from commit 2a19bb85)
Reviewed-on: https://gerrit.libreoffice.org/17553Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: Id9dee9cfe065b30c2ae9bade1098d16e2c659c23
(cherry picked from commit d657a976)

Add a dependency from main.xcd to config_host.mk to rebuild it when the
version number changes.

Change-Id: I6878d58def57942f117b0b6e49a6c03abbeca5af
Reviewed-on: https://gerrit.libreoffice.org/17539Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
(cherry picked from commit da011e05)
Reviewed-on: https://gerrit.libreoffice.org/17541

I did not notice this before, as my user profile had a custom window
size; but with an empty user profile the buffer had a 0,0 size, so the
buffered result was empty, as no ImplHandleResize() was invoked.

Change-Id: Ie299ad1323944941afc407dc90f2459d72885d42
(cherry picked from commit 968bc55a)
Reviewed-on: https://gerrit.libreoffice.org/17532Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

This was only done in the new gtk3 backend, all other backends seem to
ignore the GDK_KEY_RELEASE event (especially the gtk2 one). So make the
gtk3 backend code consistent with the other backends.

Change-Id: I3bdecb7ce05190ee2496bc552ca79375fb6fd713
Reviewed-on: https://gerrit.libreoffice.org/17431Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit a2eaa1bb)
Reviewed-on: https://gerrit.libreoffice.org/17529

Change-Id: I9888f8ab7bccdd2902d619487279999f2ff9ab13
(cherry picked from commit c1617b8d)
Reviewed-on: https://gerrit.libreoffice.org/17513Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Project: help  68c46e7dbaf5cf34a5b5ccb80122801dad778bbe

missing space Open Statement[Runtime] → Open Statement [Runtime]

Change-Id: If90b4d89c0dc7172b417b30dd242278386813244
(cherry picked from commit bbece63b0f7b182f8bbf36accef29bb7a42e7800)

cherry-pick from master

caused by commit 5333782d
"convert SETTINGS_ #defines to 'enum class'"

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

Wrong copy-paste

Change-Id: I7460c095c7bbb340be2cab32c4724688076c5952
Reviewed-on: https://gerrit.libreoffice.org/17477Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
(cherry picked from commit 4a847bb4)
Reviewed-on: https://gerrit.libreoffice.org/17488Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

In case we had a toplevel window W1, the paint was triggered for window
W2 and we had a sub-widget W3, then previously the buffer was created
for W2, so the pixel offsets had to be set relative to W2 when rendering
W3. As a consequence, if a single window was painted, then it was
always painted in the top left corner.

Now that the buffer is persistent and is always created for W1, make
sure that we paint to the correct offset, and W3 is always painted at
the same offset, regardless if it was painted directly, or just because
it's a child of W2.

With this, the buffer conents is closer to what is on the screen, even
if it's not perfect yet.

Also:

- PaintHelper: restore set buffer properties
- let PaintBufferGuard also manage pixel offset
- no need to tweak map mode in PaintBuffer()

Conflicts:
	vcl/source/window/paint.cxx

(cherry picked from commits 94a6daa0,
c36a00b8,
28e465d2 and
ec1a0354)

Change-Id: Ibf0e89ad18e5763bd2a01e69d91da163c24a309d
Reviewed-on: https://gerrit.libreoffice.org/17518Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

The hard-coded "/" separator causes getFileURLFromSystemPath to fail,
and it's not obvious why the URL is being converted to a system path
in the first place.

Change-Id: I06ebe6d92954c4f3c884ae6f0b327ea8a36c10a4
(cherry picked from commit 8bf374b9)
Reviewed-on: https://gerrit.libreoffice.org/17512Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>