| Age | Commit message (Collapse) | Author |
|---|
|
'sc' module was cleaned.
Change-Id: Ia491d741a4c1c5314f35ebb4baa82dd516948ae7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165699
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
|
|
ScPatternAttr is traditionally derived from SfxPoolItem
(or better: SfxSetItem) and held in the ScDocumentPool
as Item.
This is only because of 'using' the 'poolable'
functionality of the Item/ItemSet/ItemPool mechanism.
Lots of hacks were added to sc and Item/ItemSet/
ItemPool to make that 'work' which shows already that
this relationship is not optimal.
It uses DirectPutItemInPool/DirectRemoveItemFromPool
to do so, also with massive overhead to do that (and
with not much success). The RefCnt in the SfxPoolItem
that is used for this never worked reliably, so the
SfxItemPool was (ab)used as garbage collector (all
Items added and never removed get deleted at last
for good when the Pool goes down). For this reasons
and to be able to further get ItemSets modernized
I changed this. I did two big changes here:
(1) No longer derive ScPatternAttr from SfxItemSet/
SfxSetItem, no longer hold as SfxPoolItem
(2) Add tooling to reliably control the lifetime of
ScPatternAttr instances and ther uniqueness/
reusage for memory reasons
It is now a regular non-derived class. The SfxItemSet
formally derived from SfxSetItem is now a member. The
RefCnt is now also a member (so independent from
size/data type of SfxPoolItem). All in all it's pretty
much the same size as before.
To support handling it I created a CellAttributeHelper
that is at/owned by ScDocument and takes over tooling
to handle the ScPatternAttr. It supports to guarantee
the uniqueness of incarnated ScPatternAttr instances for
a ScDocument by providing helpers like registerAndCheck
and doUnregister. It hosts the default CellAttribute/
ScPatternAttr. That default handling was anyways not
using the standard default-handling of Items/Pools.
I adapted whole SC to use that mainly by replacing calls
to DirectPutItemInPool with registerAndCheck and
DirectRemoveItemFromPool with doUnregister, BUT: This
was not sufficient, the RefCnt kept to be broken.
For that reason I decided to also do (2) in this change:
I added a CellAttributeHolder that owns/regulates the
lifetime of a single ScPatternAttr. Originally it also
contained the CellAttributeHolder, but after some
thoughts I decided that this is not needed - if there
is no ScPatternAttr set, no CellAttributeHolder is
needed for safe cleanup at destruction of the helper.
So I moved/added the CellAttributeHolder to ScPatternAttr
where it belongs more naturally anyways. The big plus is
that CellAttributeHolder is just one ptr, so not bigger
than having a simple ScPatternAttr*. That way, e.g.
ScAttrEntry in ScAttrArray did not 'grow' at all. In
principle all places where a ScPatternAttr* is used can
now be replaced by using a CellAttributeHolder, except
for construction. It is capable to be initialized with
either ScPatternAttr instances from the heap (it creates
a copy that then gets RefCounted) or allocated (it
supports ownership change at construction time).
Note that ScAttrEntry started to get more a C++ class
in that change, it has a constructor. I did not change
the SCROW member, but that should also be done.
Also made registerAndCheck/doUnregister private in
CellAttributeHelper and exclusively used by
CellAttributeHolder. That way the RefCnt works, and a
lot of code gets much simpler (check ScItemPoolCache,
it's now straightforward) and safer and ~ScPatternAttr()
uses now a hard
assert(!isRegistered());
which shows that RefCnt works now (the 1st time?).
There can be done more (see ToDo section below) but I
myself will concentrate on getting ItemSets forward.
This decoupling makes both involved mechanisms more safe,
less complex and more stable. It also opens up
possibilities to further optimize ScPatternAttr in SC
without further hacking Item/ItemSet/ItemPool stuff.
NOTE: ScPatternAttr *should* be renamed to 'CellAttribute'
which describes what it is. The experiencd devs may know
what it does, but it is a hindrance for understanding for
attacting new devs. I already used now names like
CellAttributeHelper/CellAttributeHolder etc., but
abstained from renaming ScPatternAttr, see ToDo list below.
SfxItemSet discussion:
ScPatternAttr still contains a SfxItemSet, or better, a
SfxSetItem. For that reason it still depends on access to
an SfxItemPool (so there is acces in CellAttributeHelper).
This is in principle not needed - no Item (in the range
[ATTR_PATTERN_START .. ATTR_PATTERN_END]) needs that.
In principle ScPatternAttr could now do it's own handling
of those needed Items, however this might be done (linear
array, hash-by-WhichID, ...). The Items get translated
to and from this to the rest of the office anyways.
Note that *merging* of SfxItemSets is *still* needed what
means to have WhichID slots in SfxItemState::DONTCARE,
see note in ScPatternAttr::ScPatternAttr about that. And
there is also the Surrogates stuff which would have to be
checked.
The other extreme is to use SfxItemSet *more*, e.g. directly
derive from SfxItemSet what would make stuff easier, maybe
even get back to using the 'regular' Items like all office,
I doubt that that would be much slower, so why...?
Also possible is to remove that range of Items exclusively
used by ScPatternAttr from ScDocumentPool *completely* and
create an own Pool for them, owned by CellAttributeHelper.
That Pool might even be static global, so all SC Docs could
share all those Items - maybe even the ScPatternAttr
themselves (except the default per document). That would
remove the dependency of ScPatternAttr from a Pool
completely.
ToDo-List:
- rename ScPatternAttr to CellAttribute or similar
- use SfxItemSetFixed with range [ATTR_PATTERN_START
.. ATTR_PATTERN_END] instead of regular SfxItemSet
(if the copy-construtor works now...?)
- maybe create own/separate Pool for exclusive Items
- make ScAttrEntry more a C++ class by moving SCROW
to the private section, add get/set methods and
adapt SC
Had to add some more usages of CellAttributeHolder
to the SC Sort mechanism, there were situations where
the sorted ScPatternAttr were replaced in the Table,
but the 'sorted' ones were just ScPatternAttr*, thus
deleting the valid ones in the Table already. Using
CellAttributeHolder makes this safe, too.
Added a small, one-entry cache to CellAttributeHelper
to buffer the last found buffered ScPattrnAttr. It
has a HitRate of ca. 5-6% and brings the UnitTest
testSheetCellRangeProperties from 0m48,710s to
0m37,556s. Not too massive, but erery bit counts :-)
Also shows that after that change optimizations in
the now split functionality is possible and easy.
Change-Id: I268a7b2a943ce5ddfe3c75b5e648c0f6b0cedb85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161244
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
and rename it to ScItemPoolCache,
since its only use is to handle ScPatternAttr objects
Change-Id: I68a2dd5f47fcf902f9df552e1a1767d5061d85d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160162
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
To understand this, some look back in history will be needed to see
why it is as it is today. In some (reworked) comments 'poolable' is
described as flag to hold Items in the ItemPool, also always having
only one incarnation of each possible Item.
This is not the original intention, but a side-effect. The reason is
what the binary format in the office did: To save a document, the
Objects & the Pool were saved, *not* individual Items *together*
with the objects. The Pool was completely (binary) saved (and loaded)
in one run.
Temporary IDs were used to represent at the objects in file which
Items were referenced. This *required* to have only one incarnation
per item to have a minimal binary file size, thus this high effort
was put into this. At doc load, the pool was loaded, all Items were
set to RefCount 5000, the references from the objects were restored
and then for each Item the RefCount was lowered by 5000 again
and - if being zero - deleted. Items for UI were marked 'non-poolable'
to *not* safe them with the document, so poolable was a flag to decide
if that Info/Item was to be saved with the document - or more direct:
if it is Model Data.
Items are small, so if we prefer runtime it is okay to no longer being
strict with this, anyways does not happen often and has only marginal
memory effects - compared to runtime effects/savings.
Other problems which this caused: One example is that objects in the
UNDO stack were still in the pool, so e.g. deleted pictures were saved
with the document despite no longer being used (!). That is the reason
we have an UndoItemPool and a method MigrateItemPool to move stuff to
that Pool when objects go to the UNDO stack - all of this is also no
longer needed.
Cleaning this up means to ideally have all items in the SfxItemSet,
no longer at the Pool. The Pool should be reduced to a 'Default-Item-
Holder' and a 'Slot-to-whichId-mapper'.
This needs thorough cleanups/removals, but will be worth it because
that massive simplification(s) will increase safety an runtime and make
migrating to the goal of completely type-based ItemSet stuff easier for
the future. Hopefully only view code in the office working with items
will have to be changed for this.
In this 1st step I already found that some 'compromizes' will be
needed:
- There are still Items that have to be at the pool to make the
Surrogate-stuff working. This gives back all Items in a Pool of a type
and is used in ca. 80 cases. Each one looks at these Items *without*
context (e.g. a SfxItemSet at an Object would be a context), so if e.g.
a dialog is open that temporarily uses Items of that type you would
also get these - without knowing about it...
To make that work there is still a mechanism to have Items at the Pool,
but now just *registering* (and un-reg) them without any sort/search/
remove needs. Also only for Items that need that, so I evaluated the
GetItemSurrogates calls and added some asserts when GetItemSurrogates
tries to access an unregistered item type which needs to be added.
- Another caveat is that there are about 250 places that directly put
Items to the Pool (not all remove these, that is done at pool deletion,
so some kind of silent 'garbage-collection' is in place). To have an
overview I renamed the accessing methods to separate them from the same
functionality at the SfxItemSet, which had the same names. An
implementation does still add these directly to the pool, there is no
way to cleanup those usages for now. In principle all these should be
changed to hold the data at an SfxItemSet.
I am still hunting problems. But you can build the office, all apps
work (including chart) and you can do speed comparisons already.
There are test throwing errors, so I hunt these now. It is hard to
give an estimation about how much more changes/corrections will be
needed.
Completed adaptions to new registered Items at Pool, that reduces the
failing tests. Still many that I need to hunt.
Added stuff to work around that 'compromize' in ScDocumentPool: It
overloads ::PutImpl of the pool to implement special handling for
a single Item in SC, the ScPatternAttr. In former code that method
was used from SfxItemSet and ::PutImpl at the pool directly, so it
was only used in one place. I am not sure if it was used from
the SfxItemSet functionality, but better offer it for now. To not
waste too much runtime the callbacks depend on the boolean
'NewItemCallback' at the SfxPoolItem, it gets set for that single
Item in SC and only then the callbacks trigger. I hope to get rid
of those again, e.g. newItem_UseDirect is only needed since we have
no 'real' StaticPoolDefaults currently - another thing that needs to
be cleaned up in a next step.
Since usages of impl(Create|Cleanup)ItemEntry and
Direct(Put|Remove)ItemInPoolImpl got more and more similar I decided to
unify that: move impl(Create|Cleanup)ItemEntry to tooling, make it
globally available in svl and use it also directly for
Direct(Put|Remove)ItemInPoolImpl. This slightly increases the failing
tests again, but only since in Direct(Put|Remove)ItemInPoolImpl that
fallback (e.g. tryToGetEqualItem) was used before, thus this is the
same class of errors (SfxPoolItem ptr-compare) as the others which I
will need to find anyways. Also fixed some missing stuff.
Have now idenified and redirected all SfxPoolItem ptr-compares
to be able to debug these - one cause for the remaining errors is
probably that before with bPoolable those often were sufficient, but
are no longer. Used the [loplugin:itemcompare] and a local clang
build to do so, see https://gerrit.libreoffice.org/c/core/+/157172
Stabilized Direct(Put|Remove)ItemInPoolImpl forwards, added parameter
to implCreateItemEntry to signal that it gets called from DirectPool
stuff - currently needed. Hopefully when getting rid of that DirectPool
stuff we can remove that again
Added two more debug functionalities:
- Added a SerialNumber to allow targeted debugging for deterministic
cases
- Added registering & listing of still-allocated SfxPoolItems at
office shutdown
Found PtrComp error in thints.cxx - POC, thanks to
areSfxPoolItemPtrsEqual. Will hopefully help more with other tests
Found some wrong asserts/warnings where I was too careful and not
finding something/succeeding is OK, fixes some UnitTests for SC
For SC I now just tried to replace all areSfxPoolItemPtrsEqual with
the full-ptr-content compare SfxPoolItem::areSame. I also needed to
experiment/adapt the newItem_Callback solution but got it working.
Did that replacement now for SW too, found some places where the
direct ptr compare is OK.
Continued for the rest of occurrences, now all 160 places evaluated.
Also done some cleanups.
Massive cleanups of stuff no longer needed with this paradigm change.
Also decided to keep tryToGetEqualItem/ITEM_CLASSIC_MODE for now.
It is used for *one* Item (ScPatternAttr/ATTR_PATTERN) in SC that
already needs many exceptions. Also useful for testing if errors
come up on this change to test if it is related to this.
Added forwarding of target Pool for ::Clone in SvxSetItem and
SvxSetItem, simplified SfxStateCache::SetState_Impl and returned
to simple ptr compares in SfxPoolItem::areSame to not do the test
in areSfxPoolItemPtrsEqual.
Debugged through UITest_calc_tests9 and found that in tdf133629
where BoxStyle is applied to fully selected empty calc the Item-
reuse fallback has to be used not only for ATTR_PATTERN, see
comment @implCreateItemEntry. Maybe more...
Problem with test_tdf156611_insert_hyperlink_like_excel. Found that
in ScEditShell::GetFirstURLFieldFromCell the correct SvxURLField
is found and returned as ptr, but it's usage crashes. That is due to
the SfxItemSet aEditSet used there gets destroyed at function return
what again deletes the SvxFieldItem that is holding the SvxURLField
that gets returned.
This shows a more general problem: There is no 'SfxPoolItemHolder'
that safely holds a single SfxPoolItem - like a SfxItemSet for a
single Item (if Items would be shared_ptrs, that would be a safe
return value).
That will be needed in the future, but for now use another solution:
Since I see no reason why EE_FEATURE_FIELD should not be shareable
I wil change this for ow in the SfxItemInfo for EditCharAttribField.
That way the Item returned will be shared (RefCnt > 1) and thus not
be deleted.
I changed the return value for GetURLField() and
GetFirstURLFieldFromCell() in ScEditShell: At least for
GetFirstURLFieldFromCell the return type/value was not safe: The
SvxFieldItem accessed there and held in the local temporary
SfxItemSet may be deleted with it, so return value can be
corrupted/deleted. To avoid that, return a Clone of SvxFieldData
as a unique_ptr.
With all that UnitTest debugging and hunting and to get the paradigm
change working to no longer rely on shared/pooled items I lost a
little bit focus on speed, so I made an optimization round for the
two central methods implCreateItemEntry/implCleanupItemEntry to
get back to the speed improvements that I detected when starting this
change. It was mainly lost due to that 'strange' chained pool stuff
we have, so I added to detect the target pool (the one at which the
WhichID is registered) directly and only once. Next thing to cleanup
will/should be the pool and it's concept, all this is not needed
and really costs runtime.
Since implCreateItemEntry/implCleanupItemEntry are executed millions
of times, each cycle counts here.
Had an error in the last changes: pool::*_Impl methods use index
instead of WhichID - most of them. Another bad trap, I really need
to cleanup pool stuff next.
Change-Id: I6295f332325b33268ec396ed46f8d0a1026e2d69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157559
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
try to spend a little less time here, when searching twice, we can use
the index result of the first search as a hint
Change-Id: I7fc0c2fb4e5e338d2c3f8a3d642043a1b301e7b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157749
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change in Calc behaviour, dropping the 84 line limit.
This way, if all rows or columns are bordered, only up to the last
cell containing data is displayed in the Print Preview. In other
cases, all bordered cells are visible.
Change-Id: I7d874a093d76d5ed92b1b63b645b97582d52629e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153256
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
e4008dc0c3b43c9eacdd88511075be2b88 did this for ApplyBlockFrame()
but didn't chagne ApplyFrame() which is only called from there.
Change-Id: I9f1dce3dc7fda23b42e90432c13dfca0aa7f267e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135130
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Even ScDocument::GetDefPattern() can be modified by the user (it's
the default style that can be edited), so it's conceptually
incorrect to ignore it while iterating, and clamping to allocated
columns is also no longer needed. If this makes some code slow,
then that needs explicit handling in that code or some other
way of speeding things up.
Change-Id: I4a7c7fef0a8625b559bbce4580df19a5e9ed92a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132911
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
If there's e.g. an entire row bold, it's enough to set default
attribute for unallocated columns.
This also reverts the workaround from commit 297ab561c6754, as it's
no longer necessary.
Change-Id: I0b208709aeaff1c0d59da2410926876715cfe642
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131320
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Things like applying bold to an entire row no longer allocates
all rows after my recent changes, but the attribute change is
done in ScTable to the default attribute of unallocated columns.
That means that clamping column positions to the end of allocated
columns is no longer valid when handling attributes. Add functions
that clamp depending on whether unallocated columns have
a non-default attribute set.
Change-Id: I879d0a034c0b336064361d0f8cb12e5a8da22b9c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131265
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Just like already done for RowHidden(), avoid repeated calls
to HasAttrib() and IsVerOverlapped() that would return the same
value because it's the same underlying attribute range.
Change-Id: Ic270f5ba1333e15d46b5e54e14d9760602221ea7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131151
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ica57f18d3fd1bf9ec06f05869f4a956d7d1097b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131036
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
rather than on the heap, avoiding an allocation
Change-Id: I3f1504f9a2d4178a9ba59e98de182a0ab98cdce0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118356
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
sc, scaddins, sccomp, scripting
Change-Id: Ia99fec9e238033821cb784810edd4762c09bd5db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112049
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: I8f37a8d1174ed816df971b8cee036d4e88d4a7fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104526
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I06e4190235799d6ff231179ae3bbc8f76d4a3342
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102867
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This reverts commit fb1d3b580763a333bbbfe115d09e1b5cd8849675.
Now that we know that making fields has negative side effects
like disabling assignment operator generation.
Change-Id: Ib48334ffbeb2c768896dd8ced6818aa0b9910b0b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90333
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iafbdd3b7e872cd15718879e5c7f1256069156d5f
Reviewed-on: https://gerrit.libreoffice.org/71343
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This takes the loading time from 15s to 14s.
Reduce unnecessary allocation/copying by passing down ownership of the
newly created ScPatternAttr to the item pool
Change-Id: Iec38bbff572d10ff8d86f5e65fbe9a96b6a5a706
Reviewed-on: https://gerrit.libreoffice.org/71010
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If326175d571d15752efd1b63df45b2bc785f7541
Reviewed-on: https://gerrit.libreoffice.org/61653
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Remove ScDocument* member from ScColumn
and re-use the one in ScAttrArray.
This saves 8 bytes and makes the code more
homogenious by using GetDoc() member everywhere.
(cherry picked from commit 1168a11278ed3c2a00058e1f802f6e44cb925318)
Reviewed-on: https://gerrit.libreoffice.org/46680
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit dc3f0bde0bdef2a1e94055be146b433cb9fc54ba)
Change-Id: I16a94b7ef7c45ef3af14e812b45f255f39939a6e
Reviewed-on: https://gerrit.libreoffice.org/46990
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
|
|
Change-Id: I8e790f9253279c9135ea1a4bcdd663ae7df44015
Reviewed-on: https://gerrit.libreoffice.org/45464
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2cdd66b9819f070548c2a0af7388d9bfbd3689c1
Reviewed-on: https://gerrit.libreoffice.org/45144
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
instead of re-implementing it ourselves.
Which lead to some changes in Xf::AttrList since the import process
wants to donate it's array to ScAttrArray.
Change-Id: I176148131fb5f163e25691ad690f63398ba1a556
Reviewed-on: https://gerrit.libreoffice.org/42205
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
since it's the last row that the pattern applies to
Change-Id: I80d6d5787768b1e98e958d7adc4c13c37c560ccd
Reviewed-on: https://gerrit.libreoffice.org/42211
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Check if attribute changed during ApplyAttributes. If it did not change,
it is unnecessary to recalculate cell size, repaint etc.
Change-Id: Ic3a3fa24efa9ad3619b8979a67e972a7635311cc
Reviewed-on: https://gerrit.libreoffice.org/40198
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Bunth <btomi96@gmail.com>
|
|
Change-Id: I004e1f0292c8a40515880546574255ab835dbdbe
Reviewed-on: https://gerrit.libreoffice.org/39875
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id2fdffa4d7bba8225ea5fcf583a562467342ad3d
Reviewed-on: https://gerrit.libreoffice.org/38728
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I672785b273eaa8862f43112d7f25ae495b65b0c7
|
|
Change-Id: Ie65fce6041278c6758df266c4ef097a5758f75dd
Reviewed-on: https://gerrit.libreoffice.org/38448
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
which are exactly the same as the regular SCROW/etc typedefs, and have
been this way since
commit 43a21999a92c99867bc3417291719996776b0647
Author: Oliver Bolte <obo@openoffice.org>
Date: Fri Jun 4 09:00:39 2004 +0000
INTEGRATION: CWS rowlimit (1.1.2); FILE ADDED
Change-Id: Ia7f75d71227ca3167b5fd56019bb9bdf0697d1b0
Reviewed-on: https://gerrit.libreoffice.org/37911
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I00f82387ce67ce7d6e8708c7def994767cd79b6f
Reviewed-on: https://gerrit.libreoffice.org/36269
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: Ibcb3068318180f2adfdc41aac5d75299c1ffaffc
Reviewed-on: https://gerrit.libreoffice.org/34711
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
For a default column, now ScAttrArray does not store the default
format. So the case of default pattern from 0 to MAXROW is represented
as nCount = 0 and pData = nullptr in ScAttrArray.
A new ScAttrArray object (aNextColAttrArray) is introduced as a member
of ScTable. This is used to store the formatting of *unallocated*
columns (whose indices are from aCol.size() to MAXCOL).
In next patches for this bug, I plan to refactor table*.cxx functions
related to formatting such that :
1) In formatting setter functions, if colspan of the input range
spans the colrange(aCol.size() to MAXCOL) then instead of
allocating columns, apply that formatting to aNextColAttrArray.
2) In formatting getter (const) functions, if requested colspan has some
intersection with the colrange(aCol.size() to MAXCOL) then use the
formatting info stored in aNextColAttrArray to calculate the formatting
of the input range.
3) In general setter (non-const) functions if we really need to allocate
new columns (example, when data is entered), use the formatting info
stored in aNextColAttrArray to create pAttrArray of the new column.
Change-Id: Ieb56f853209b396d92fdb2c27e39361703576423
Reviewed-on: https://gerrit.libreoffice.org/27828
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: Ib417c5e978fca563f8c0ef0dbe6b9d50fead9828
Reviewed-on: https://gerrit.libreoffice.org/30566
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This should ensure that as long as the style does not change the cell
style name is the same after an import export cycle.
Each ScPatternAttr stores a unique ID and we store the ID to name
mapping during import. During export if we find a ScPatternAttr that has
a key that is also stored in the map we write back the style name from
the map.
To avoid name collisions we block the style names from the import for
the export.
The missing piece to make this completely awesome is now to make sure
that styles are sorted by name during export. That way we can reduce the
diff between import and export even more.
Change-Id: Ie4fe2aa00f07efec27ea129e314ac0b6b7e0d8c0
Reviewed-on: https://gerrit.libreoffice.org/29255
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Remove unused constant RTL.
Inline PAINTEXT constant since it is only used in one place.
Change-Id: I7b2c15e7579fc5bc475d00fe714f17592bd5e2a1
|
|
Change-Id: Ib162ba9297b9d900ea42c7e5216e152d3e58a361
Reviewed-on: https://gerrit.libreoffice.org/25769
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I3089006b502e33710bfb2564f051ebf2892ad08a
Reviewed-on: https://gerrit.libreoffice.org/25085
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ia414f7845425ef73859ed04853378e96cc738795
Reviewed-on: https://gerrit.libreoffice.org/22971
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
I made small changes to disable some test code conditionally by adding a few
new debug macros.
Change-Id: Ieaf6f1b29343fb896cc64163a116c629165e8db3
Reviewed-on: https://gerrit.libreoffice.org/22711
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I3ccc98d2e042120093e2e8508518681588692393
|
|
Change-Id: I765d2a600f9c57da50c85354688e3ae796750d94
|
|
Change-Id: I328ac7a95ccc87732efae48b567a0556865928f3
|
|
Change-Id: Ieeca9fe957e7bc6a4cf9d7d6ac57f9ed150aab78
|
|
Change-Id: I76488045eba281227124041da505e38c4c3d31c1
|
|
Change-Id: Ib26b448f49c2ca633c557075b282ecbfb99dadea
|
|
Change-Id: Ida47df6223a20939ad5971dc00b8f3462a92dd3e
|
|
sorry, huge one...
|
|
This is a very common operation. Let's speed it up a bit.
TODO : Handle cell comments.
Change-Id: I5442bf19008475a9427b889c1eb641cacd8ff161
|
