Age | Commit message (Collapse) | Author |
|
Effective C++, item 17
Change-Id: I5c6f20c9631f1ca86b481a56ef08d578a7addbad
|
|
...similar to what has been done for svx/sdtmfitm.hxx in
6a2ea81ca1622d2c2ad55bea8ddc28167fcc2794 "Remove unused ctors" and
68969cc61adecac481ae9656978ef952f435b310 "Consistency around SdrMetricItem."
Change-Id: I3734cb14b6ed8f556af85b234968682a55ac8a4c
|
|
Change-Id: Ic554fa7c1e549a0f39296836868b22ccf4c859d3
|
|
valgrind + bff
Change-Id: Ib818d508e10877a845b733c4aa223d1e2cbbc05e
|
|
Change-Id: I69dbbabc5774cbce7943e77f41bb42ed7a118bcf
|
|
Change-Id: I65e4a6ad59aee21b62454b4fcdd6d6ca056cb249
|
|
Change-Id: Ib0db01179ed56f39d5e3986e7302b2bf914b06e9
|
|
Change-Id: Ib9e8a9a80498ad87df6ab13ded1127d068913347
|
|
apparently I removed the wrong one with 15344d0415f153ba579ad132266c47990a8c9515
with pch I don't see those problems :(
Change-Id: If4cb8b178bdd8f8d68b4921c1993642656fc75ea
|
|
Change-Id: I4f6dfe478ba6dd009153d77af26507e0e1795262
|
|
Change-Id: I07c457a49646703af5d13f83ba033340309ee655
|
|
Change-Id: Ide31f67c346f9a82bf6aa8282caa7cfcee65d9fd
|
|
Change-Id: I96861e0d31c75587892d13818f536acb1a05d24e
|
|
Change-Id: Ie6d05762baae87794e9320a6b123ef326289e4c1
|
|
Change-Id: I9db0befd075089f346b504f91657a67dc01c9808
|
|
Change-Id: I084d99fdd1a34842178b59c17ab108750f7bd11d
|
|
Change-Id: Id39add923b94bcf43e64ffbf4940625efe4d35a0
|
|
Change-Id: I6ce6aa7cc4420bf8f82a578b7985e795c99e0898
|
|
Change-Id: I42f97a12052f4a173b05173fdd2c3079c517f78e
|
|
Change-Id: I64d2b73744401baafd7dd037187ba3d7c604a535
|
|
Change-Id: I6e1b54a66d0b669ecbba4eb305c1dd8925747edd
|
|
Change-Id: I36fc0ed4f67c0af467a8dc593950a9c53a5ec53b
|
|
Change-Id: Ic3b7de3d26e91b260d775e629602758f63a40b85
|
|
Change-Id: Ie3934ebc3209b8ba0358cca5fad9883e3b8cd262
|
|
Change-Id: Ie72cb6796e3996d7050b771f7ab92e4ab5a6d72b
|
|
Change-Id: Idef182a43e7aa631aeea92870e3c51a7c2b8b7c5
|
|
Change-Id: Iccaf0cd1adbe5a2b1ff81c466ca3c81c00390c10
|
|
Change-Id: I88a34ad1d54066c30523c6493cbe5f0502adb3fb
|
|
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/10837
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If996284aeea4b430cceaaf264035aa9e4ec0f2f0
Reviewed-on: https://gerrit.libreoffice.org/10835
Reviewed-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/10834
Reviewed-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 961315f0838197e71e9bd49169afe673466e5eb8.
Change-Id: I06648ab075b198ee7914e7ae60bef87e7ff94f0a
Reviewed-on: https://gerrit.libreoffice.org/10833
Reviewed-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/10953
Reviewed-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
|