Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I1d792082e79d6bb68004a84c172cc3bb5c194826
Signed-off-by: Kohei Yoshida <kohei.yoshida@gmail.com>
|
|
Change-Id: If9859b5021c532daacccfaf386e0489c134e4afb
Signed-off-by: Kohei Yoshida <kohei.yoshida@gmail.com>
|
|
Currently, having a note e.g. at D5, and deleting cell D4 and shifting
the cells below upward will remove the note at D5. But the correct behavior
is to shift that note up to D4. This change fixes it.
Change-Id: Ia37f1ce67a003deab424f2b805a2ce333fc10ed4
(cherry picked from commit d3344dd85ee31b195a3709d16e734245e1d0a4b6)
Signed-off-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Steps to reproduce:
1) Insert a comment at D5.
2) Move cursor to C4.
3) Right-click and select Insert.
4) Choose shift cells down.
5) The comment gets shifted down but it shouldn't.
The same thing happens when deleting a cell and shifting content.
Change-Id: I5a71845cca6abde6b7c940e152e155da26343cef
Signed-off-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I036f0531dc2290c5eb480258bc70ec13b810e6bc
Signed-off-by: Kohei Yoshida <kohei.yoshida@gmail.com>
Signed-off-by: Eike Rathke <erack@redhat.com>
Signed-off-by: Noel Power <nopower@novell.com>
|
|
Change-Id: I52987e957918853bcd1abd1460c6166b52454d62
Signed-off-by: Kohei Yoshida <kohei.yoshida@gmail.com>
|
|
Change-Id: Id1cf7d99a13c04541e87ad00c5418dd4f766d268
Signed-off-by: Kohei Yoshida <kohei.yoshida@gmail.com>
|
|
Change-Id: I7c4cb1a5f31ba9e37a280af2243a13c57914cb2f
(cherry picked from commit 669784c6653732fd2ad43024332957d5df5652bb)
Signed-off-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I52d645a8a7662016ced8c1eb6b320c4a14807353
Signed-off-by: Jan Holesovsky <kendy@suse.cz>
|
|
Change-Id: Ib9cd4e09e55ff2413db8e1daf45624d695e3113d
Signed-off-by: Jan Holesovsky <kendy@suse.cz>
|
|
Change-Id: I3c235f6dd0b69d3fc560910fcc890d2c80c995c0
Signed-off-by: Jan Holesovsky <kendy@suse.cz>
|
|
Change-Id: Id49eb1da20b75a9ab83d20c29ad8e976d46b9423
Signed-off-by: Jan Holesovsky <kendy@suse.cz>
|
|
TODO:
- UNO needs some love to accept this change
- we need a new uno interface for conditional formats in 4.0
- copy/paste
- undo/redo
Change-Id: I2c8a233888a95c7298dfb151d1c12b6a6a58520d
|
|
This is just a first step. In a second step we need another layer to
allow color scales and databars applied to the same range and finally
merge them with normal conditional formatting.
Change-Id: I0452ed12dd9b2d5395cf005d75a902fbb7a984ad
|
|
Change-Id: I I I0f3ce313928ffa85f563e4162398816bf3ab2fdc
|
|
This fixes problems with unique value/ duplicate value entries. The old
falt copy process did not respect that the copy needs to point to its
own range and therefore the copy was totally useless.
This is also necessary for several future new conditional formats like:
top n%, top n elements, above average, ...
Change-Id: I51b868968812a4e00dca9af2aa51d50b5ef8b855
|
|
Change-Id: I60cb1f1ed4a0068bc39ada14ac629bf20af709f9
|
|
Change-Id: I I98b7d83aee9f74574a4884f6066e769930e1803a
|
|
|
|
|
|
|
|
It is alarming that the Notes unit test did not fail for any of these
errors
|
|
|
|
I can't express how dumb I feel after searching for hours for a bug in
the note handling and then it is just such a small copy/paste error
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
there are still some issues that will be addressed in later commits
|
|
|
|
|
|
Regression from 3.4.5.
|
|
multiple variants of toUpper (etc)
some that take a non-const OUString or String and modify it
some that take a const OUString or String and return a new one
some that take part of a const OUString or String and return a new one
|
|
|
|
|
|
* make it officially non-copyable. It was never copied anyway.
* retire std::auto_ptr which is deprecated. Let's use boost::scoped_ptr.
* some unused typedef's.
|
|
|
|
|
|
|
|
Because I'll be modifying this struct in the next few days...
|
|
|
|
|
|
|
|
Dependencies of defined names must not depend on the order in which they
are inserted during file load. In a second step compile defined names
that had unresolved names during load, and only those.
|
|
|
|
only update range names in formulas if the documents are different or
the sheets are different
|
|
we need to update range names/database ranges when we copy/paste formula
cells otherwise the ScNameToken may point to a different entry
|