summaryrefslogtreecommitdiff
path: root/dbaccess
AgeCommit message (Collapse)Author
2024-04-02simplify SotTempStream and lifetimeNoel Grandin
It is really just an SvStream instance, and the lifetime does not need reference counting Change-Id: Idb5ffd96f852aae0dc1a94cddc0a83fbcdf974ff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165655 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-20Related: tdf#108057 Use autoincrement for automatically added primary keyMike Kaganski
This partially undoes commit 24940e2c3717ad7b07d43db4f08cf7e09cfcc22f (#100599# #95927# check if row is readonly and disable autoincrement column for auto primarykey, 2002-06-27), enabling autoincrement again. Make sure to use the largest type that supports autoincrement. Change-Id: I4dfdbfb0c3d9b94c7634082b029c6e66aa01c782 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165027 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-20tdf#103068: make sure to update and use current MySQL connection typeMike Kaganski
1. Don't set selection in OGeneralPageWizard::getEmbeddedDBName. The method should only provide a name of an embedded database - either in the passed set, or the default one; the activation of controls and related actions will be done in the calling implInitControls. This makes sure, that ODbTypeWizDialogSetup::m_sURL doesn't get rewritten unnecessarily, keeping the current preference intact. 2. In ODbTypeWizDialogSetup::activateDatabasePath, do not use the hardcoded MySQL URL from the control, if the current value of m_sURL is already a MySQL one. This allows to keep the selected kind intact. 3. In OMySQLIntroPageSetup::implInitControls, do not assume that the existing selection means that there's nothing to do. The page keeps the selection, even when the wizard's active path was changed; and so, the wizard's idea which page to show next may differ from the selection. Just make sure to update the setup mode. Change-Id: Iad98d54a615dccc58b2852a1c0d8aefad6b0b898 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164987 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-15tdf#114441 change use of sal_uLong to better integer types in dbaccessanish.deshpande
Reason for changing m_nThreadEvent: This variable denotes the number of events happening on one thread of the processor and is calculated from a sal_Int32 value. Change-Id: I1c76368b3dc1f649e6d800cde8c2a841ff5b82f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164170 Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2024-03-13reduce symbol visibility in --enable-mergelibs=more modeNoel Grandin
Change-Id: If811c9ec336543227db73c990248b9113846cf2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164657 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-23Fix warning C4312 when building with MSVC without -Wv:18Mike Kaganski
Discovered by https://gerrit.libreoffice.org/c/core/+/163717 Like these: C:/lo/core/sw/source/ui/dbui/addresslistdialog.cxx(426): warning C4312: 'reinterpret_cast': conversion from 'int' to 'void *' of greater size Change-Id: Idbfbe8add89c8e219bdabcf28b741e2e31a5e345 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163781 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-19ITEM: Speedup SlotIDToWhichID translationsArmin Le Grand (allotropia)
With ItemInfoPackages we now can have a buffered, static global translation table from SlotIDs to WhichIDs since the ItemInfoStatic used already contains all the needed information. Register that in registerItemInfoPackage at the Pool and use it for lookup. That speeds up the lookup from O(n) to O(1). Since that lookup is used in UI and UNO API implementations this has positive effect on load/safe, but also all interactive stuff in the whole office. NOTE: I tried to use a merged version of that translation table in the parent pool, but this shows double SlotIDs, what is no wonder since that's what those are used for: To get different WhichIDs for a SlotID in Item handling. This *might* prevent getting rid of the chanined Pools at all - sadly. The returned WhichID directly depends on which Pool the function(s) GetWhichIDFromSlotID and GetTrueWhichIDFromSlotID are called. NOTE: Very strange is that the parameter 'bDeep' in that functions is *not* passed down to the call to the secondary Pool - probably an error, but risky to fix, that may change already the behaviour :-( Change-Id: Iea77ffad0f6a5401ab74fea0bbfc2589c66680ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163597 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-02-14Fix typoAndrea Gelmini
Change-Id: I67e2769f3b60ef48a785d5eefc3dbad64b04b2eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163322 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-02-13try reenabling CppunitTest_dbaccess_hsqldb_test on macOSCaolán McNamara
Change-Id: Ic2d2bdf2e472b04ddaba8585082256b560115d40 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163247 Tested-by: Jenkins Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-12ITEM: ItemPool Rework (I)Armin Le Grand (allotropia)
Driving forward the Item reworks I now take the ItemPool in focus: It now does not hold any items anymore and should be renamed to something like ItemInfoProvider/ItemHelper, since it's main purpose is to provide the Defaults for the Item functionality. There is that SfxItemInfo, only a struct and bundling SlotID and ItemFlags. There are also the DefaultItems, just handled as ptrs in an array. It is/was always error-prone to keep these in sync. Remember that it's also necessary for the order to not only being sorted but being increments of one with no gaps allowed in the WhichIDs to which the Items are bound. I now bundled that to a new class ItemInfo that joins WhichID, SlotID, ItemFlags and the default Item. This is a pure virtual base class, it comes in three derivations: (1) ItemInfoStatic: This is supposed to be global static and hosts the Item in a std::unique_ptr to ensure cleanup. It is designed to be constructed once during runtime and being shared globally. It allows the ItemPtr to be nullptr to mark as non-static (if initial static is not possible for some reason) but still offers the needed data. Most cases (95%+) are of that case. The contained Item is owned by that instance. The flag isStaticDefault() is set at the Item. (2) ItemInfoDynamic: This is supposed to be used for cases where the Item cannot be static: Mainly for SfxSetItem (that needs a Pool itself in the contained SfxItemSet, so lifetime is bound to that Pool), but other cases showed up in the transition. These instances live while the Pool lives and get destructed when the Pool goes down. Also uses std::unique_ptr for the Item instance for as much automated cleanup as possible, the contained Item is owned by that instance, the instance by the Pool. The flag isDynamicDefault() is set at the Item. (3) ItemInfoUser: This is used for UserDefaults that can be set for every ItemInfo entry to 'overshadow' the default from the 'outside'. It uses a regular Item and the central access methods implCreateItemEntry/ implCleanupItemEntry to manage the Item instance, thus works like a SfxPoolItemHolder. The Item instance can be globally shared and re-used even when the Pool goes down. Instances belong to the Pool and are cleaned up when the Pool goes down. This Item does not need any further flag to be set. The ItemInfos are organized using a class called ItemInfoPackage: This bundles groups of ItemInfoStatic to functional instances. There are derivations/ implementations of this e.g. for Writer ItemPool bundling all the needed defaults for Writer, similar for draw/impress, Calc and other usages. These ItemInfoPackage can be 'registered' at an ItemPool using it's method registerItemInfoPackage. This does all the needed stuff to setup that group of ItemInfos at the Pool (It even sets internal vars First/LastWhich, that info can just be derived from the buildup ItemInfo Ptrs). The ItemInfoPackage has methods 'size()' and 'getItemInfo(index) to allow looping over it and deliver the infos the Pool needs. The (forced, pure virtual) overloads of getItemInfo in the specific implementations check for the ItemPtr being nullptr and create a exclusive incarnation of ItemInfoDynamic for the Pool if needed, returning that. The Pool owns the ItemInfoDynamic incarnations and uses the ItemInfoStatic directly. On shutdown it cleans up the ItemInfoDynamic as needed. The ItemInfoUser is used by the Pool when a UserDefault is set/used: for SetUserDefaultItem, GetUserDefaultItem, ResetUserDefaultItem. It is not held in a 2nd list, but directly in the list of ItemInfo'ptrs: To keep track of this an unordered_map is used that helds the original ItemInfo associated with the WhichID. That way no two lookups (as before) are needed to get the current Pool's default for any WhichID. The derivations of ItemInfoPackage are encapsulated and just allow access to an ItemInfoPackage& with a single method as return value. All use a static local instance of a std::array<ItemInfoStatic, FIXED_SIZE> which constructs all ItemInfoStatic and the static Item instances - if already possible. Sometimes it is necessary to overload the constructor to set some static instances for Items later than the lib init. These are also just marked with nullptr as Item instance. Some need to overload getItemInfo to complete instances of ItemInfoStatic, if needed, or create and deliver instances of ItemInfoDynamic. The registerItemInfoPackage also offers a optional lambda callback: there were two cases where local data from the Pool was needed to incarnate the item - just add that to the call to registerItemInfoPackage if needed, see examples in the adapted code. For the re-use of Items this means that now in SfxItemSet/SfxPoolItemHolder *true* static Items can and will be used without RefCount directly and globally. This is also the case for dynamic Items, with the exception of differing Pools for SfxSetItems which cannot be done. Future: That design is already prepared to allow solving that Pool-chaining problem: currently there are master/sub-pools and all accesses have to traverse that structure before even doing anything. For the future the idea is more to 'compose' a Pool by registering ItemInfoPackages, e.g. for Writer pool you may start with SfxItemPool, register the writer-specific ItemInfoPackage, then the one for DrawingLayer (if needed) and the one for EditEngine. It should also be possible to get to smaller granularities of that packages. Ideas for new ones will emerge. We might also think about composing Pools which can e.g. run Writer and Chart, so allowing to use Chart *without* OLE stuff in Writer - just ideas... More changes: - Adapted all stuff, cleaned up old stuff/ definitions - Removed FreezeIdRanges, that can be done once per Pool on-demand (and cannot be forgotten to be called) - Merged XOutdevItemPool with SdrItemPool and offered a ItemInfoPackage which joins both needed sets of Items - All the cleanup hassle with Pools and defaults cleaned up - Adapted all access methods of the pool to use that new stuff. Pool chaining currently stays, but I use a central method 'getTargetPool' instead of recursive calling to get the correct Pool for the action Change-Id: I2b8d3d4c3cc80b1d0d0b3c0f4bd90d7656b4bab7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163157 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-01-27ITEM: Cleanup some Pool stuff with DefaultsArmin Le Grand (allotropia)
Sorted out some methods at ItemPool which process Defaults to make more clear what is going on and what which method is doing. Change-Id: I2568d3e03d0a56a14b6fe4e04521e1a8e22c000b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162643 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-01-27Drop std::as_const from css::uno::Sequence iterationsMike Kaganski
Obsoleted by commit 2484de6728bd11bb7949003d112f1ece2223c7a1 (Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and commit fb3c04bd1930eedacd406874e1a285d62bbf27d9 (Drop non-const Sequence::operator[] in internal code, 2021-11-05). Change-Id: Idbafef5d34c0d4771cbbf75b9db9712e504164cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162640 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-22cid#1586675 Missing move assignment operatorCaolán McNamara
and cid#1586677 Missing move assignment operator Change-Id: I1bd2cd0f102d8ce44feb579b85c41b3c1f789f23 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162369 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-16loplugin:unusedmethodsNoel Grandin
Change-Id: I24c429c7cb8283a384b72499d1c3f4c2f1457c33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162155 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-01-14ITEM: Move Shareable ItemFlag to SfxPolItemArmin Le Grand (allotropia)
Currently a Pool-Attribute (in SfxItemInfo), but should be a SfxPoolItem property. Originally 'moved' from old 'poolable' used as hint. I identified needs more general and moved it to where it belongs. Also reworked SfxItemInfo to no longer have/support single bollean flags, but a FlagVariable and defined SFX_ITEMINFOFLAG_* entries to access these, that will make future changes easier without having to change all palces where these get defined over and over again. Added CheckItemInfoFlag for gereral access to that flag and e.g. NeedsSurrogateSupport to directly check for the SFX_ITEMINFOFLAG_SUPPORT_SURROGATE flag as syntactical sugar, that makes the intention clear. Change-Id: I09c238c7c5b7f721b657d7b0a44dbc8d14e02528 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161982 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-01-13cid#1546059 xRow is always emptyCaolán McNamara
Change-Id: Ic5c6b2463600cd449bf2e0fed829ce199172578c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162025 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-03UnoApiTest::loadFromURL -> UnoApiTest::loadFromFileMike Kaganski
The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-01Remove OApplicationController::getStrippedDatabaseName which only adds a layerJulien Nabet
Change-Id: Ife0435f52b1abe62337623aa5c6010195802760b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161523 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-31Replace "size() == 0 with empty()" (dbaccess)Julien Nabet
Change-Id: Icd15299fbf9515d35a143995bcf131d267fe2fe0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161466 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-30cid#1545965 COPY_INSTEAD_OF_MOVECaolán McNamara
and cid#1545849 COPY_INSTEAD_OF_MOVE cid#1545814 COPY_INSTEAD_OF_MOVE cid#1545685 COPY_INSTEAD_OF_MOVE cid#1545583 COPY_INSTEAD_OF_MOVE cid#1545575 COPY_INSTEAD_OF_MOVE cid#1545517 COPY_INSTEAD_OF_MOVE cid#1545474 COPY_INSTEAD_OF_MOVE Change-Id: I79a47ee34dace3a4664bfece26c59e719f469cab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161448 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-27tdf#158803 Fix issues detected by pyflakesChenxiong Qi
Change-Id: Iaa329dff61db894e7d5fecd840e785a53a48b26f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160889 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org>
2023-12-24cid#1545470 COPY_INSTEAD_OF_MOVECaolán McNamara
and cid#1545468 COPY_INSTEAD_OF_MOVE cid#1545446 COPY_INSTEAD_OF_MOVE cid#1545435 COPY_INSTEAD_OF_MOVE cid#1545419 COPY_INSTEAD_OF_MOVE cid#1545415 COPY_INSTEAD_OF_MOVE cid#1545410 COPY_INSTEAD_OF_MOVE cid#1545390 COPY_INSTEAD_OF_MOVE cid#1545384 COPY_INSTEAD_OF_MOVE cid#1545374 COPY_INSTEAD_OF_MOVE cid#1545371 COPY_INSTEAD_OF_MOVE cid#1545368 COPY_INSTEAD_OF_MOVE cid#1545366 COPY_INSTEAD_OF_MOVE cid#1545335 COPY_INSTEAD_OF_MOVE cid#1545331 COPY_INSTEAD_OF_MOVE cid#1545327 COPY_INSTEAD_OF_MOVE cid#1545308 COPY_INSTEAD_OF_MOVE cid#1545280 COPY_INSTEAD_OF_MOVE cid#1545199 COPY_INSTEAD_OF_MOVE Change-Id: If05a13125b05ccd93d34d0eced566e7b3b58aaef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161256 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-23Fix b26611017a75867efe97b4cf53df96cbd025cc5eJulien Nabet
Following Caolán's comment here: https://gerrit.libreoffice.org/c/core/+/161185 Thank you Caolán for the review! Change-Id: I8ac949fccc8a11cf483f679d4c0d2dc16e8c680c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161193 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-22Use emplace_back instead of push_back (dbaccess)Julien Nabet
Change-Id: I659e211928dce2a5b8a44ceb3ec95745f66fbd1f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161185 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-19cid#1557601 COPY_INSTEAD_OF_MOVECaolán McNamara
and cid#1546498 COPY_INSTEAD_OF_MOVE cid#1546384 COPY_INSTEAD_OF_MOVE cid#1546376 COPY_INSTEAD_OF_MOVE cid#1546374 COPY_INSTEAD_OF_MOVE cid#1546373 COPY_INSTEAD_OF_MOVE cid#1546368 COPY_INSTEAD_OF_MOVE cid#1546365 COPY_INSTEAD_OF_MOVE cid#1546356 COPY_INSTEAD_OF_MOVE cid#1546340 COPY_INSTEAD_OF_MOVE cid#1546266 COPY_INSTEAD_OF_MOVE cid#1546236 COPY_INSTEAD_OF_MOVE cid#1546188 COPY_INSTEAD_OF_MOVE cid#1546178 COPY_INSTEAD_OF_MOVE cid#1546166 COPY_INSTEAD_OF_MOVE cid#1546156 COPY_INSTEAD_OF_MOVE cid#1546144 COPY_INSTEAD_OF_MOVE cid#1546143 COPY_INSTEAD_OF_MOVE cid#1546100 COPY_INSTEAD_OF_MOVE cid#1546078 COPY_INSTEAD_OF_MOVE cid#1546041 COPY_INSTEAD_OF_MOVE cid#1546036 COPY_INSTEAD_OF_MOVE cid#1546033 COPY_INSTEAD_OF_MOVE Change-Id: Ib3586d93198992e206baf5c2de5a663d5574aa3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160979 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-17tdf#119931 Fix accessibility warningsAdam Seskunas
Fix accessibility warnings in: dbaccess/uiconfig/ui/specialjdbcconnectionpage.ui Change-Id: I90eedb80db71d087a1bea5c2565809951d8c6f89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160874 Tested-by: Jenkins Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2023-12-16cid#1545970 COPY_INSTEAD_OF_MOVECaolán McNamara
and cid#1545957 COPY_INSTEAD_OF_MOVE cid#1545944 COPY_INSTEAD_OF_MOVE cid#1545939 COPY_INSTEAD_OF_MOVE cid#1545931 COPY_INSTEAD_OF_MOVE cid#1545926 COPY_INSTEAD_OF_MOVE cid#1545909 COPY_INSTEAD_OF_MOVE cid#1545899 COPY_INSTEAD_OF_MOVE cid#1545896 COPY_INSTEAD_OF_MOVE cid#1545894 COPY_INSTEAD_OF_MOVE cid#1545858 COPY_INSTEAD_OF_MOVE cid#1545823 COPY_INSTEAD_OF_MOVE cid#1545820 COPY_INSTEAD_OF_MOVE cid#1545819 COPY_INSTEAD_OF_MOVE cid#1545772 COPY_INSTEAD_OF_MOVE cid#1545749 COPY_INSTEAD_OF_MOVE cid#1545743 COPY_INSTEAD_OF_MOVE cid#1545739 COPY_INSTEAD_OF_MOVE cid#1545635 COPY_INSTEAD_OF_MOVE cid#1545603 COPY_INSTEAD_OF_MOVE cid#1545602 COPY_INSTEAD_OF_MOVE cid#1545592 COPY_INSTEAD_OF_MOVE cid#1545544 COPY_INSTEAD_OF_MOVE cid#1545532 COPY_INSTEAD_OF_MOVE cid#1545520 COPY_INSTEAD_OF_MOVE cid#1545512 COPY_INSTEAD_OF_MOVE cid#1545490 COPY_INSTEAD_OF_MOVE cid#1545483 COPY_INSTEAD_OF_MOVE cid#1545467 COPY_INSTEAD_OF_MOVE cid#1545461 COPY_INSTEAD_OF_MOVE cid#1545458 COPY_INSTEAD_OF_MOVE cid#1545428 COPY_INSTEAD_OF_MOVE cid#1545394 COPY_INSTEAD_OF_MOVE cid#1545385 COPY_INSTEAD_OF_MOVE cid#1545383 COPY_INSTEAD_OF_MOVE cid#1545366 COPY_INSTEAD_OF_MOVE cid#1545357 COPY_INSTEAD_OF_MOVE Change-Id: I76224326977b4067b94ca3176cad1ca6de17930a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160847 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-13loplugin:unusedfieldsNoel Grandin
The sPassword field in SvtHistoryOptions became redundant after commit c0fffdc36df687fe8e4eff49e5a00d3a3c1eb370 Author: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> Date: Mon Oct 2 12:35:21 2023 +0200 [API CHANGE] Remove deprecated Password config item Change-Id: Ie0c4597da5cd510f405400c215110c1e357cb497 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160615 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-12-12cid#1546444 COPY_INSTEAD_OF_MOVECaolán McNamara
and cid#1546389 COPY_INSTEAD_OF_MOVE cid#1546388 COPY_INSTEAD_OF_MOVE cid#1546360 COPY_INSTEAD_OF_MOVE cid#1546158 COPY_INSTEAD_OF_MOVE Change-Id: I3707d55b88674dfb5ae786fc2cc45000862340de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160611 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-10cid#1545177 COPY_INSTEAD_OF_MOVECaolán McNamara
and cid#1545179 COPY_INSTEAD_OF_MOVE cid#1545187 COPY_INSTEAD_OF_MOVE cid#1545188 COPY_INSTEAD_OF_MOVE cid#1545189 COPY_INSTEAD_OF_MOVE cid#1545196 COPY_INSTEAD_OF_MOVE cid#1545197 COPY_INSTEAD_OF_MOVE cid#1545204 COPY_INSTEAD_OF_MOVE cid#1545223 COPY_INSTEAD_OF_MOVE cid#1545236 COPY_INSTEAD_OF_MOVE cid#1545239 COPY_INSTEAD_OF_MOVE cid#1545253 COPY_INSTEAD_OF_MOVE cid#1545274 COPY_INSTEAD_OF_MOVE cid#1545286 COPY_INSTEAD_OF_MOVE cid#1545309 COPY_INSTEAD_OF_MOVE cid#1545311 COPY_INSTEAD_OF_MOVE cid#1545345 COPY_INSTEAD_OF_MOVE cid#1545358 COPY_INSTEAD_OF_MOVE cid#1545361 COPY_INSTEAD_OF_MOVE cid#1545365 COPY_INSTEAD_OF_MOVE cid#1545367 COPY_INSTEAD_OF_MOVE cid#1545372 COPY_INSTEAD_OF_MOVE cid#1545373 COPY_INSTEAD_OF_MOVE cid#1545377 COPY_INSTEAD_OF_MOVE cid#1545392 COPY_INSTEAD_OF_MOVE cid#1545399 COPY_INSTEAD_OF_MOVE cid#1545404 COPY_INSTEAD_OF_MOVE cid#1545408 COPY_INSTEAD_OF_MOVE cid#1545430 COPY_INSTEAD_OF_MOVE cid#1545439 COPY_INSTEAD_OF_MOVE cid#1545449 COPY_INSTEAD_OF_MOVE Change-Id: I3afe836a0bbc8bd70937035e60eb020435e413d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160539 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-08cid#1545692 std::swap COPY_INSTEAD_OF_MOVECaolán McNamara
Change-Id: Ic0679eccd7cc781fb799b15fbb2660fcbd1445f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160447 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-08cid#1546472 COPY_INSTEAD_OF_MOVECaolán McNamara
and cid#1546459 COPY_INSTEAD_OF_MOVE cid#1546452 COPY_INSTEAD_OF_MOVE cid#1546403 COPY_INSTEAD_OF_MOVE cid#1546396 COPY_INSTEAD_OF_MOVE cid#1546394 COPY_INSTEAD_OF_MOVE cid#1546338 COPY_INSTEAD_OF_MOVE cid#1546324 COPY_INSTEAD_OF_MOVE Change-Id: If61457cfaf1d7ce4a069bcecdc0cc657aeb43c68 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160445 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-07simplify and modernise ScopedBitmapAccessNoel Grandin
(*) Make all of it use a "Scoped" paradigm (*) pass by value, no need to allocate on heap (*) make all of the construction go via the *Access constructors, instead of it being some via the constructors and some via the Acquire*Access methods. (*) take the Bitmap& by const& in the constructor, so we can avoid doing const_cast in random places. Change-Id: Ie03a9145c0965980ee8df9a89b8714a425e18f74 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160293 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-12-04cid#1545597 Using invalid iteratorJulien Nabet
and : cid#1545537 Using invalid iterator cid#1545508 Using invalid iterator cid#1545494 Using invalid iterator cid#1545478 Using invalid iterator cid#1545427 Using invalid iterator cid#1545420 Using invalid iterator cid#1545400 Using invalid iterator cid#1545300 Using invalid iterator cid#1545258 Using invalid iterator cid#1545257 Using invalid iterator cid#1545200 Using invalid iterator cid#1545183 Using invalid iterator Change-Id: Ibf3a41902f34286967195c5c3b22e337a4b06809 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160322 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-04cid#1546275 Using invalid iteratorJulien Nabet
and : cid#1546219 Using invalid iterator cid#1546088 Using invalid iterator cid#1546070 Using invalid iterator cid#1546061 Using invalid iterator cid#1546055 Using invalid iterator cid#1546049 Using invalid iterator Change-Id: I6f3a786852b5c262d60c3195e446a37967ed9b59 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160311 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-04cid#1546422 COPY_INSTEAD_OF_MOVECaolán McNamara
and cid#1546416 COPY_INSTEAD_OF_MOVE cid#1546415 COPY_INSTEAD_OF_MOVE cid#1546391 COPY_INSTEAD_OF_MOVE cid#1546390 COPY_INSTEAD_OF_MOVE cid#1546317 COPY_INSTEAD_OF_MOVE cid#1546252 COPY_INSTEAD_OF_MOVE cid#1546251 COPY_INSTEAD_OF_MOVE cid#1546249 COPY_INSTEAD_OF_MOVE cid#1546243 COPY_INSTEAD_OF_MOVE cid#1546195 COPY_INSTEAD_OF_MOVE cid#1546193 COPY_INSTEAD_OF_MOVE cid#1546137 COPY_INSTEAD_OF_MOVE cid#1545738 COPY_INSTEAD_OF_MOVE cid#1545782 COPY_INSTEAD_OF_MOVE Change-Id: I10d5091aa72b682371764b8a18cc5062e272c031 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160285 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-03cid#1546503 Using invalid iteratorCaolán McNamara
and: cid#1546480 Using invalid iterator cid#1546479 Using invalid iterator cid#1546454 Using invalid iterator cid#1546419 Using invalid iterator cid#1546410 Using invalid iterator cid#1546150 Using invalid iterator cid#1546039 Using invalid iterator cid#1545831 Using invalid iterator cid#1545736 Using invalid iterator cid#1545701 Using invalid iterator cid#1545630 Using invalid iterator cid#1545381 Using invalid iterator Change-Id: I9e151b623f751ee1e982b5da0011ff08ab0ad5e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160270 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-11-29cid#1554867 silence Out-of-bounds accessCaolán McNamara
Change-Id: I11acf38f1243e1eea180b478055f12839c58f551 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160015 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-11-20Extended loplugin:ostr: dbaccessStephan Bergmann
Change-Id: Ib6a310f78d8f168e5524d4115cf6f00d679b7cbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159719 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-18c++20: use std::erase(_if) instead of std::remove(_if)+erase (part 3)Julien Nabet
Change-Id: I1ea95e0bfeaed88b9484403e6796574f1d06f133 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159612 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-11-10loplugin:fieldcast in OTableStyleContextNoel Grandin
Change-Id: I8c5c1d569d022ac679e4939d97fdd293000c23ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159300 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-09enable unchecked lint for our java codeNoel Grandin
and annotate where necessary, mostly just suppressing the warnings Change-Id: I8e39d797cde6c7c3f4e3e1bd93a128965ecec81d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159205 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-09tdf#114441 Convert sal_uLong to better integer typesYli875
The maximum value of the width in BrowserColumn is LONG_MAX. tools::Long value range is the closest among other integer types. It is widely used in these files. Also, other parameter types and return types have been changed to match the width type. Change-Id: Ia8b941a8ea02075a0d9b4d44675d5809005738bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157477 Tested-by: Hossein <hossein@libreoffice.org> Reviewed-by: Hossein <hossein@libreoffice.org>
2023-11-09default to ignoring libreoffice special-purpose protocols in calc hyperlinkCaolán McNamara
Change-Id: Ib9f62be3acc05f24ca234dec0fec21e24579e9de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158911 Tested-by: Jenkins Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.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-11-07Pass XInteractionHandler to hasTrustedScriptingSignature instead of a boolMike Kaganski
This allows to use the same interaction handler there, as used in DocumentMacroMode::adjustMacroMode. hasTrustedScriptingSignature used to find its own interaction handler; and that would conflict with e.g. ODatabaseModelImpl::adjustMacroMode_AutoReject, which passes nullptr to adjustMacroMode, with intention to not show any UI; but with signed macros (see tdf#97694), the UI would still appear. Change-Id: Ia209f96bef67dccfe1da23c4d172ac47497f8eb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159070 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-10-23Extended loplugin:ostr: Rewrite some O[U]StringLiteral -> O[U]StringStephan Bergmann
...in include files. This is a mix of automatic rewriting in include files and manual fixups (mostly addressing loplugin:redundantfcast) in source files that include those. Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-22tdf#119931 Fix accessibility warnings in dbaccessnirnay
Added accessibilty to some UI files Change-Id: Id9d1eae93151e232040fdcf22810ba67ead05609 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151138 Tested-by: Jenkins Reviewed-by: Samuel Thibault <sthibault@hypra.fr> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-10-20dbaccess/source/core/inc/object.hxx unused since initial importJulien Nabet
Change-Id: Iad9c4f234833ce4c605040b9d0f9b86150791c99 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158210 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2023-10-19Extended loplugin:ostr: Automatic rewrite O[U]StringLiteral: dbaccessStephan Bergmann
Change-Id: I5f92e390ef57ae8f2aba43782c11ca5ee31dba93 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158187 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2025-01-10 22:30:18 +0000