summaryrefslogtreecommitdiff
path: root/vbahelper
ModeNameSize
-rw-r--r--Library_msforms.mk2958logplain
-rw-r--r--Library_vbahelper.mk3167logplain
-rw-r--r--Makefile225logplain
-rw-r--r--Module_vbahelper.mk1457logplain
-rw-r--r--README43logplain
d---------inc / pch30logplain
d---------source70logplain
d---------util45logplain
generated by cgit (git 2.34.1) at 2024-07-18 23:44:39 +0000
missing. Maybe with C++20 we should more use the default generated op== (or op<=>) that may turn out to be more safe. For class Cell at least all members (and sub-members of Style) are simple and simple comparable. Change-Id: Idea2ef2abe68c4bb14aa776a8393ba5da92abd5c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159798 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2023-11-21Cleanup some ScPatternAttr specific stuffArmin Le Grand (allotropia) Removed some special stuff in the ItemSet/Item tooling regarding ScPatternAttr. There are still quite a view (grep for isExceptionalSCItem), but all these are identified and isolated. Only for that Item (of over 500) are these exceptions, so that raelly does not fit into the Item schemata in any way. Not even the pool default of ScPatternAttr is without trouble. It is the only and last Item that needs to be 'pooled' in the sense to avoid copies on any price. That is OK, but should not be done in the ItemSet schemata. In short: It should not be an Item at all. It should be changed and renamed to something describing it's role (CellAttributes..?) and get helped/assisted by something called CellAttributeHelper at SC's model or Pool. It should not even be derived from SetItem, it could just contain an shared_ptr of SfxItemSet (allows more and better optimizations - think about Clone() and op==). In parallel, all these hacks in the ItemSet/Item stuff could be removed, making that faster and easier. Also quite some usages of DirectPutItemInPool could be cleaned-up, this only exists since there *is* no defined place to hold that data (coud be CellAttributeHelper in the future). Putting Items directly to the pool (and in most cases never remove them again) is just nonsense and another hint that all this does not fit to the Item/ItemSet schema at all. This is now - after hard isolation of problems and have all working - doable. It may be one of the next things to do, but there are other candidates, too. Doing this would mostly only help SC... Found another hack that uses DirectPutItemInPool and *never* removes any Item again, see comments framelinkarray.cxx And another one: PoolItemTest::testPool() explicitely tests DirectPutItemInPool stuff - which makes no sense long-term, but for now keep it and make it work by marking the slots used as _bNeedsPoolRegistration == true Have now overhauled the framelinkarray stuff to work without DirectPutItemInPool and Cell not being a SfxPoolItem. That will be much less complex and use much less calls/checks. Since this is the data structure created for every calc repaint that should get faster, too. Also for now and memory loss security I added code to DirectPutItemInPool to behave the same as with the unchanged implCreateItemEntry: register Items so that the garbage collection still is used. This will/can be removed when all usages of DirectPutItemInPool is cleaned up. Directly registering in DirectPutItemInPoolImpl is more tricky than thought, but a good thing to do. Looking at that I saw that tryRegisterSfxPoolItem is not used anymore, so rearranged some stuff. Change-Id: If07762b0a25e2739027f81872441772dc82a25d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159685 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> 2023-11-07ITEM: Get away from classic 'poolable' Item flagArmin Le Grand (allotropia) 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> 2023-09-01remove DBG_ASSERT in MergedCellIteratorNoel Grandin this does not actually seem to be an error Change-Id: I6d286a3e614bc18f9655fa7e7c9716d2ae067fb0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156409 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2023-07-02loplugin:singlevalfieldsNoel Grandin Change-Id: I091fac5ed41b2fb58dee5e3e1b8dd805c8dc4966 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153813 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2023-06-29loplugin:unusedfields make it a little smarterNoel Grandin around dealing with operator[] on map data-types Change-Id: Idd6654948ae2d03d634fcf30a8d98530a78ab4ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153740 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2023-06-19tdf#150534 reduce the memory consumption of cells when calculatingNoel Grandin borders - if there are a lot hidden columns, we end up allocating a lot of cells. Since most of the cells have the same settings, use a SfxItemPool to consolidate them. Change-Id: If2dd77b3eabc5d37eb8804953f8c89ffa04f2400 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153258 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2023-04-28optimise find/insert calls to mapsNoel Grandin Instead of doing two lookups, we can just call insert and then update the mapped-to value if the insert actually succeeded. Change-Id: I3df3b98f0debe6bf74c739dd5850e7714d9c2789 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151030 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2023-01-30tdf#150534 reduce allocation in SdrFrameBorderPrimitive2DNoel Grandin Change-Id: Ib55ce7882e87823cca95e00cb5ae990213d1e766 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146339 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2023-01-30tdf#150534 use unordered_set for checking of lines already crossedNoel Grandin Change-Id: Ib864f9e8b7a3a2e6c4db5f2eec5333dc74bf9f6a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146334 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2022-10-31Fix typoAndrea Gelmini Change-Id: I5090a74ff98240821555ce749316df3721da4a9b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142067 Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> 2022-10-31tdf#143377 Correct maximum Skew for TextOrientation in CalcArmin Le Grand (allotropia) For zero or 180 degree text orinentation errors can happen in the Border visualization, theoretically also in the Text rendering. Ths has to do with sin(0) and sin(180) being zero and lead internal to numerical problems, e.g. a very huge Skew that when applied show the reported 'errors'. I limit this mechanism now to +/- 1/2 degree from the critical mentioned places, for Border and Text - to not risk to have different points of corrections. The UI only allows angles of 1 degree steps, but UNO API and pdf import may allow more. Change-Id: Idbc68f6a7beab84df0672165c2a813d96eeff84e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141999 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> 2022-03-24loplugin:constantparamNoel Grandin Change-Id: Ib65abd0546f1219387fe3fd7ad4f6ba0eb029bd1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131987 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2022-01-17tdf#135843 tdf#146731 Fix the missing border handlingGülşah Köse Reverts fa5ab8aa5d88e7128015127af75980a65f945cbb inside. And fix the missing border problem with better way. Reason of the problem is using ORIGCELL cell style for bottom and right of merged ranges is wrong. Eg: We have Row X Col 3X3 table. (0,1) and (0,2) merged. The right side of right border style should be same with (0,2). But ORIGCELL points (0,1) instead. In case we should use LASTCELL. Same reason is valid for bottom case. Change-Id: I5282083541f0bd02f3765943da4f34cabe05ef13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128493 Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com> Tested-by: Gülşah Köse <gulsah.kose@collabora.com> 2021-12-30tdf#126269 Add clipping to diagonal border linesArmin Le Grand (Allotropia) See task for in-deep discussion. Needed to do some re-arrangements to add clipping to diagonal border lines. It is necessary to only clip visible geometry but not touch vectors that get added to be able to solve all that dynamic border line style start/end overlapping. Change-Id: I656a5cd63a011140ee1281873e44ab5e60606b67 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127713 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> 2021-12-27tdf#126269 Handle diagonal borderline better for merged cellsArmin Le Grand (Allotropia) Change-Id: I04776bbd237dc1fa881385bfe9be7f034b58e35a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127431 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> 2021-12-03sal_Int32 is sufficient for svx::frame::ArrayNoel Grandin Change-Id: Icc1ebf769796d23e226b72a3decf74ab15e09e0c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126274 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2021-02-21Typo fix: supress -> suppressTor Lillqvist Change-Id: I72aeaff1bc8ac67253265ea99de91b9b9906e5d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111275 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> 2020-10-28convert some more long -> tools::LongNoel grepping for stuff in template params this time Change-Id: Ia37bfd85480b3a72c3c465489581d56ad8dde851 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104855 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2020-10-26switching long to a 64-bit type on 64-bit windowsNoel (*) create a rewriting plugin to do most of the work, heavily based on the fakebool plugin (*) but there are still a number of "long"s in the codebase that will need to be done by hand (*) the plugin needs lots of handholding, due to needing to add #include and update macros Change-Id: I8184d7000ca482c0469514bb73178c3a1123b1e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104203 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2020-07-02Upcoming improved loplugin:staticanonymous -> redundantstatic: svxStephan Bergmann Change-Id: I6f4b927f9c869925825cc83cc36f0494d06c8faa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97698 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2020-03-13Revert "loplugin:constfields in svx"Noel Grandin This reverts commit 1a6397030381a45f27ab7a2a02e6e6d0f9987c84. Change-Id: Iaa706bb4ea3144ef57ab359b982400abc589b97e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90454 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2020-02-27loplugin:constantparamNoel Grandin Change-Id: I62a0b760e49e38a4565eebf272492159047dda5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89613 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2020-01-28tdf#96505: Get rid of cargo cult long integer literalsOnur Yilmaz I checked return values. Long variables didn't affect the calculation. Change-Id: I1d5b5cffa291c20f7940dc14efa05cc64f3ff1ed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87499 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com> 2020-01-17tdf#42949 Fix IWYU warnings in svx/source/[a-e]*/*cxx and svx/qa/Gabor Kelemen Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I68110cdc5cff99a3bc15184c04ae309412511f9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86633 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2020-01-15clang-tidy modernize-concat-nested-namespace in svxNoel Grandin Change-Id: I8a00f2823aa956afb995ee68c9f995bf08ad5239 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86824 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2019-11-22Extend loplugin:external to warn about classesStephan Bergmann ...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend loplugin:external to warn about enums". Cases where free functions were moved into an unnamed namespace along with a class, to not break ADL, are in: filter/source/svg/svgexport.cxx sc/source/filter/excel/xelink.cxx sc/source/filter/excel/xilink.cxx svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx All other free functions mentioning moved classes appear to be harmless and not give rise to (silent, even) ADL breakage. (One remaining TODO in compilerplugins/clang/external.cxx is that derived classes are not covered by computeAffectedTypes, even though they could also be affected by ADL-breakage--- but don't seem to be in any acutal case across the code base.) For friend declarations using elaborate type specifiers, like class C1 {}; class C2 { friend class C1; }; * If C2 (but not C1) is moved into an unnamed namespace, the friend declaration must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace.") * If C1 (but not C2) is moved into an unnamed namespace, the friend declaration must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882> "elaborated-type-specifier friend not looked up in unnamed namespace". Apart from that, to keep changes simple and mostly mechanical (which should help avoid regressions), out-of-line definitions of class members have been left in the enclosing (named) namespace. But explicit specializations of class templates had to be moved into the unnamed namespace to appease <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace". Also, accompanying declarations (of e.g. typedefs or static variables) that could arguably be moved into the unnamed namespace too have been left alone. And in some cases, mention of affected types in blacklists in other loplugins needed to be adapted. And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is not moved into an unnamed namespace (because it is declared in sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler doesn’t give this warning for types defined in the main .C file, as those are unlikely to have multiple definitions." (<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The warned-about classes also don't have multiple definitions in the given test, so disable the warning when including the .cxx. Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4 Reviewed-on: https://gerrit.libreoffice.org/83239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-10-10More loplugin:redundantpointeropsStephan Bergmann ...same as 7d361e96c9ea822790db21806e9fc05279423833 "loplugin:redundantpointerops" (that were presumably missed by that commit because I only pulled 682fdbf1312cf6ca70fe209bf4d7051dad8f5008 "loplugin:redundantpointerops check other pointer types" halfway through my local build) Change-Id: I1497e4fca2046cbcd107bb2ac5ed6f41bd68de98 Reviewed-on: https://gerrit.libreoffice.org/80569 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-05-08improve tools::Rectangle->basegfx::B2?Rectangle conversionNoel Grandin Improve the conversion method to do something reasonable with empty Rectangle. Use the conversion method in more places. Change-Id: I48c13f3d6dae71f39f03f7939101e545c8125503 Reviewed-on: https://gerrit.libreoffice.org/71853 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> 2019-01-22tdf#116051 Right border visible after hiding neighbour columnIlhan Yesil Added an else statement to take into account that a hidden column has a neighboured left column with a right border. Change-Id: Ia415d422dd2fa305604e48cce55661408b835ea6 Reviewed-on: https://gerrit.libreoffice.org/63326 Tested-by: Jenkins Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de> 2019-01-08convert "*xxx.get()" to "*xxx"Noel Grandin Change-Id: Ic307226591ff9702957ccdec486ccf70357eb6d9 Reviewed-on: https://gerrit.libreoffice.org/65951 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2019-01-07tdf#42949 Fix IWYU warnings in include/vcl/[v-x]*Gabor Kelemen Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I98f49765c6b74808dcbd692e0f375dd2848fcfd4 Reviewed-on: https://gerrit.libreoffice.org/65614 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2018-10-25Reorganize FrameBorderPrimitive creation (II)Armin Le Grand Step5: Move the view-dependent decomposition from BorderLinePrimitive2D to SdrFrameBorderPrimitive2D. It is now possible to use discrete sizes before the line and edge matching is done what will look much better. When it was done at BorderLinePrimitive2D and the matching was already done, that match was 'displaced' with the adapted forced scale to discrete units. The space and size used when zooming out for a single discrete unit (pixel) can heavily vary - it just covers a much larger logical area than the 'real' line/poly would do. All this needs to be handled (also for bound ranges) and can only be in a good way using primitives. Adapted to no longer do view-dependent changes in BorderLinePrimitive2D. Adapted to do these now at SdrFrameBorderPrimitive2D. Currently used to force the existing border partial lines (up to three) to not get taller than one logical unit. Adapted to no longer switch off AntiAliased rendering in VclPixelProcessor2D for processBorderLinePrimitive2D, this is problematic with various renderers on various systems (e.g. vcl still falls back to render multiple one-pixel-lines when taller than 3.5 pixels which looks horrible combined with other parts like filled polygons) All this needs fine balancing on - all systems - all renderers - all apps (which all have their own table implementation) - all render targets (pixel/PDF/print/slideshow/...) Done as thorough as possible, but may need additional finetuning. May also be a motivation to move away from vcl and implement these urgetly needed system-dependent primitive renderers... Adapted UnitTest testDoublePixelProcessing with the needed comments. Change-Id: Ie88bb76c2474b6ab3764d45a9cd1669264492acd Reviewed-on: https://gerrit.libreoffice.org/62344 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de> 2018-10-24Reorganize FrameBorderPrimitive creationArmin Le Grand Step1: Basic concept, move stuff to svx and new SdrFrameBorderPrimitive2D Step2: Adapt all creators/usages to use SdrFrameBorderData/SdrFrameBorderPrimitive2D, check functionality Step3: Re-implement mergre of BorderLinePrimitive2D during decomposition of SdrFrameBorderPrimitive2D to keep the number of primitives low from the start, make merge optional (not urgently needed) Step4: Migrate and isolate all helper methods and classes involved in geometry creation of border lines to the implementation (.cxx) of the new primitive Change-Id: I840b6765439bd995f2c57ef36315427b1f0f3e21 Reviewed-on: https://gerrit.libreoffice.org/62247 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de> 2018-10-08loplugin:constfields in svxNoel Grandin Change-Id: I643e8686e015ca85dd96221f1c93038f4fddf27b Reviewed-on: https://gerrit.libreoffice.org/61182 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2018-09-17New loplugin:externalStephan Bergmann ...warning about (for now only) functions and variables with external linkage that likely don't need it. The problems with moving entities into unnamed namespacs and breaking ADL (as alluded to in comments in compilerplugins/clang/external.cxx) are illustrated by the fact that while struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { struct S2: S1 { int f() { return 1; } }; int f(S2 s) { return s.f(); } } int main() { return f(N::S2()); } returns 1, both moving just the struct S2 into an nunnamed namespace, struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { namespace { struct S2: S1 { int f() { return 1; } }; } int f(S2 s) { return s.f(); } } int main() { return f(N::S2()); } as well as moving just the function f overload into an unnamed namespace, struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { struct S2: S1 { int f() { return 1; } }; namespace { int f(S2 s) { return s.f(); } } } int main() { return f(N::S2()); } would each change the program to return 0 instead. Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c Reviewed-on: https://gerrit.libreoffice.org/60539 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2018-08-20Simplify containers iterations, tdf#96099 follow-upArkadiy Illarionov Use range-based loop or replace with std::any_of, std::find and std::find_if where applicable. Change-Id: I2f80788c49d56094c29b102eb96a7a7c079567c6 Reviewed-on: https://gerrit.libreoffice.org/59143 Tested-by: Jenkins Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>