...which has the same underlying type as sal_Bool. The
/org.openoffice.Office.Writer/Numbering/DefaultBulletList properties FontWeight
and FontItalic are of type xs:short, i.e., sal_Int16.
Change-Id: Id8ea7300b5fda65f7fe7df98d4f8b32c22da9886
DataNode has a default initializer who sets all members to 0
Change-Id: If5086fa54701394f9ba3eadd1c130ddede945fb2
Reviewed-on: https://gerrit.libreoffice.org/24331
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
The problem as seen by the user: if you have a table of 2 rows and 1 column,
and the separator line is dragged upwards by the mouse, then undo doesn't
restore the original situation.
Two items are created on the undo stack: sd::UndoGeoObject and
sdr::table::TableRowUndo. Let's say the table height is 8000 mm100 and the two
cell heights are 4000 and 4000. If the user resizes the first cell, so that its
height is 2000, then the new table height will be 6000. The problem is that
when undo is executed, first sd::UndoGeoObject resizes the table, distributing
the newly available 2000 between the existing rows, and then
sdr::table::TableRowUndo sets the row height of the first row: the height of
the second cell will be larger than expected. Fix the problem by not doing a
relayout during sd::UndoGeoObject, but doing a relayout after
sdr::table::TableRowUndo in this case.
This is done by:
1) Adding a new SdrDragStat::mbEndDragChangesLayout, so that
SdrTableObj::applySpecialDrag() can inform SdrDragObjOwn::EndSdrDrag() that
TableRowUndo will do the layout instead of UndoGeoObject. (This is done only in
case a row edge is dragged, as otherwise it's not guaranteed that a
TableRowUndo will follow the UndoGeoObject on the undo stack.)
2) Adding a new SdrUndoGeoObj::mbSkipChangeLayout, so that
SdrTableObj::applySpecialDrag() can let SdrUndoGeoObj::Undo() not do the
layout.
3) Adding a sdr::table::SdrTableObjImpl::mbSkipChangeLayout, so that
SdrUndoGeoObj::Undo() can let SdrTableObj::NbcSetLogicRect() not do the layout.
4) Marking the table model as modified in TableRowUndo::setData(), so it does
the layout at the end of the undo group.
Change-Id: I8adde3cdad5741e6fcb420e333ce336e18c77cf1
Reviewed-on: https://gerrit.libreoffice.org/24363
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
This allows the headers in that folder to stand on their own and
not depend on any transitively included headers. All changes to
other files are needed to fix compiler errors related to missing
includes that occurred afterwards.
Change-Id: I2083b30763f0b2c1aacdff00226e5f567ae52db4
Reviewed-on: https://gerrit.libreoffice.org/24355
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
* Step by 0.1 not 1
* Allow to enter negative values without selecting condensed/expanded
Change-Id: Ibe2898cf77f56e52a276166d2ee882fbd23452af
Reviewed-on: https://gerrit.libreoffice.org/24304
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Type -- into a writer document, on a machine without Courier installed
set that text to Courier. Export to pdf, select inside e.g. evince and
paste to a terminal. You don't get --
0x2D is mapped from unicode 0x2D and unicode 0xAD in the adobe
encoding. So the latter trumps the earlier one and <ADAD> is pasted
instead of <2D2D>.
Reverse the order that the encoding is mapped from unicode so lower
more "ascii" options are preferred over the higher more "unlikely"
unicode options
Change-Id: I8f251253fca468d269493801e668617a935ee15d
replace the old declare and don't implement pattern
with C++11 delete keyword
Change-Id: I10b14cece4ecaddc5f96ee098b5fa36a8782a0fc
Reviewed-on: https://gerrit.libreoffice.org/24340
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
left change in place as it improves readability
original commit was 59433cfbff
move scope of variable
Change-Id: I86f7a7c741556d75079bd4cb3cfecafcdd229d24
Reviewed-on: https://gerrit.libreoffice.org/24325
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Project: help aefc01b1da7c55698de8bbcb483c0e8f07738984
This advice is outdated since 2011 and LO 3.5
Change-Id: Ib6a9c59b05b74b47801bf620eacb46b125e4e64a
I’ve never liked the chosen wording of this string; it has been merely
a decorative item, of limited usefulness. So I’ve decided to replace it
with something that describes a somewhat hidden functionality (drag’n’drop)
while avoiding the misuse of the word “sidebar” to refer to the bar
containing the application launcher buttons.
Change-Id: I299e9e1e97a4e7aa176bc7bbc24cf0e9bea5abb5
... not just adjacent to the one at the end. So we actually can handle
INDIRECT("A2:C2") INDIRECT("B1:B3")
Change-Id: Ie8030ebc13bb1ae2246611f5722da97970b8c544
... should be FormulaToken(svSep,ocClose) instead. Though it didn't hurt
at the end of a formula where this was generated for auto-correction.
Change-Id: I71bd8270ccc268e645eb60298e84acffe39d3a0d
The array overflow detecting places that unconditionally deleted the
token in case of overflow should do so only if no reference is held,
i.e. the token was allocated with new and passed immediately without
being assigned to a FormulaTokenRef. Just to be on the safe side.
Change-Id: If2ccabec3725ac73fe82c23f51a291246847cfdb
