Change-Id: Ia0e5930b9bbf0c81a5d2974d45730b5af75019f0

Change-Id: Ic12f04bf80639d89ecc531bceb8378c7d97e9325

Change-Id: If033f0ccca636a3ab3080a01a11467ce1ce9b24e

Change-Id: If1bf07016864a856ad15d84db0fffc34dc52ecbe

Change-Id: Ieb1c90f2f17b2ce12acf2999743ce4d608076223

Change-Id: I68fed7d2f0eea7fde60707e48349230d8a8d5c73

Change-Id: I343948a9a5e093f210cae1049caa92eeb614a2d7

There's no need for such a bloat method to replace just two vars.

Change-Id: I235d092b89160c2599a41e1046a15475b8ba433c

Change-Id: Ica4bc2a52e7351899a5741086c6db299caa5ed16

Change-Id: I2636555d9351b59572eebcf4d3f420da33674e3a

When searching for the current field in the field list to find the
previous or next one, we check the field start and compare it with
the cursor position.
But with the new input fields, the cursor can actually be anywhere
in the field, so we actually have to search for the start position
of the input field at the cursor position.

Change-Id: I26526524eccfdbea41c6bf69a460fa64248f50ca
Reviewed-on: https://gerrit.libreoffice.org/10837Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: If996284aeea4b430cceaaf264035aa9e4ec0f2f0
Reviewed-on: https://gerrit.libreoffice.org/10835Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

The new inline-editable input fields contain real content in the
node, therefore a single SwPaM::Move isn't sufficient to select
the field or move after the field.
For the input fields we can directly go to the end of the field.

Change-Id: Ic1bce415ce45e49456121b6db003ded0733e195c
Reviewed-on: https://gerrit.libreoffice.org/10834Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

if the document isn't read-only. So backspace should always work in
input fields.

Regression from 961315f0.

Change-Id: I06648ab075b198ee7914e7ae60bef87e7ff94f0a
Reviewed-on: https://gerrit.libreoffice.org/10833Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

As described in the bug report, removed Autoformat as it was creating
confusion.

Change-Id: Ia22ba529bd3cfa08fe86de4ba7947baef94f4061
Reviewed-on: https://gerrit.libreoffice.org/10953Reviewed-by: Cor Nouws <oolst@nouenoff.nl>
Reviewed-by: Joren De Cuyper <jorendc@libreoffice.org>
Tested-by: Joren De Cuyper <jorendc@libreoffice.org>

We map Word's even/odd page breaks to Writer's left/right page styles. And we cannot
just set any page style to be left/right, because that could set e.g. the default
page style as such, which would make all normal pages that way. So instead we need
to make a copy of the relevant page style, as the original page style as its follow,
copy all the properties and headers/footers, and use this copy to get the page break.

Change-Id: Id0d2568de91ac2de4afb0ba3a6eedd9cec46f878

Old behavior:

1) Add a property of type "Date". DateField inside Value column uses
   the full width.
2) Increase the width of the dialog. Now the size of DateField in
   the Value column only uses the half width.

Solution:

Set a flag if the current type is of Date. So we can correct the size
after a dialog resize action.

Change-Id: I915a553b2f69aac1aea0ac5b24536db5709abfae

No need to store the position of DateField and TimeField, because this
will not change if we choose another type. The only thing what changes
is the size of the DateField, because both "DateTime" and "Date" use
this field. And for this size we just rely on the size of m_aTimeField,
because it's the same as m_aDateField (for type DateTime).

Change-Id: Ic590c62d82d8f90576479e10be9d422326032d28

Before this patch types "DateTime" and "Yes or No"
were one pixel too big in height.

Fix this by using the original aSize and aPos values, don't
depend on m_aYesNoButton size and position.

However there are some glitches with DateTime: If you scroll
some times up and down the list of "Type" the Date and Time
fields will get positioned somewhere left.
This has to be a problem of DateField and TimeField, because

m_aDateField.SetPosSizePixel( aPos, aSize );

and m_aTimeField get the same values as all other fields...

But this positioning error existed before this patch, too.

Change-Id: I793aebf39f5b6cb6e4b290f21a5dbcc7ce6ce964

bff + valgrind

Change-Id: Ie08ddfe06dc0850cf44955cc9f9079b3856b19e3

Change-Id: I3134c574a124a2359c40b139eb5b41198b0e4611

MSWord, unlike Writer, can anchor even to a page break (i.e. after the last
paragraph). When this document was read, what happended was:
- the last paragraph was read and the current position PaM was set to point
  after it
- frame was read and anchored to the PaM
- page break was read, making everything following be moved to the next page;
  including whatever ended up at the PaM position
Handle this by checking for this case and inserting an extra empty paragraph
before the break. This shouldn't affect layout of the page itself anyway,
since the break should leave room for it (and MSWord shows a page break
there if control characters are enabled, so there is room).

Change-Id: Ia2a13bf5cf1c959b5aa228254365019a00a22679

Change-Id: Iab2c78af7dcf967ccdf5016266324c805856af0b

Change-Id: Ib8b1af5a783a2bae285c24e5153cce4713a2e2dd

Change-Id: I40d8fc61b1e488955faa61c868877c7b6487c529

Change-Id: Ia7e47b5d42e9a488b3952f12d607b3f17661c44d

Change-Id: I4be3600af6ee97ba9f962edf9723c04d89b161e4

Change-Id: I5c35d3085ec0dfa0e1d27caa9cdac5792d98812b

Change-Id: Ib405aabc4b9da1e06a009159a0ec3a15af1c7570

Change-Id: I928e8dbeeac168a02c82f2fafe881dae38ae4e3c

Change-Id: If828f82e36d12ceca7e6392de5757a131c99462c

and

coverity#1231675 Uncaught exception

Change-Id: If0907f2048fc5e492d5b8b49388c3bfad542e5f7

Change-Id: Idfc005c1c34c609b7dcaae266cdaf6a15a403e5a

Change-Id: I70c6255f062c6624bc367a8fb81288c99b6635b3

Change-Id: I0ee69279e3bb1d9871feba17b908b8307f0ec5b4

Change-Id: I33b6c2ab1068b7138ce99239f56552529d5206f5

Change-Id: Ie570a84bfca530c6763c6aa7b0ca12ae1a16f0f3

Change-Id: Ic15362b9a7687c7cba2e3b1554f2eac593afab3b

Change-Id: Icfb104b0f77d5303751a30f9188319bca7a14e6b

Change-Id: I47bb934102dd18695b3e4647c0f6216ee98f059c