Age | Commit message (Collapse) | Author |
|
This was a feature requested by mmeeks, as a result of
tdf#92611.
It validates that things that extend XInterface are not
directly heap/stack-allocated, but have their lifecycle managed
via css::uno::Reference or rtl::Reference.
Change-Id: I28e3b8b236f6a4a56d0a6d6f26ad54e44b36e692
Reviewed-on: https://gerrit.libreoffice.org/16924
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
...to avoid lots of loplugin:staticmethods warnings. Also enables DBG_ASSERT
etc. also for --enable-debug builds in addition to --enable-dbgutil builds.
Change-Id: Ib89ecd9ab8ce7abb2c64790ace248b31f9d2b64d
|
|
Change-Id: Id9296115f30858e7fd470a199e59343a96d7deec
Reviewed-on: https://gerrit.libreoffice.org/16712
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
|
|
Change-Id: I2828f5fe78efffaa5dee19a3d56592d12878d956
|
|
Idea from bubli - look for loops where the index variable is of such
size that it cannot cover the range revealed by examining the length
part of the condition.
So far, I have only run the plugin up till the VCL module.
Also the plugin deliberately excludes anything more complicated than a
straightforward incrementing for loop.
Change-Id: Ifced18b01c03ea537c64168465ce0b8287a42015
|
|
Change-Id: I7ea52365157fc642401db64c3b4a40d4643d16ae
|
|
Change-Id: I7b8c7ece656589c50fb066e9fa1565fd59f930da
|
|
Change-Id: I61a85caf1587291eaa6b999050a52c92d9e416e3
|
|
Change-Id: I982ba552579019e4902ae59fddf14a6b34ba5954
|
|
...to match what is recorded in the .component files
Change-Id: Ie548cd37872d3b8540222201afaac73040e65c8f
|
|
Change-Id: I4a33bd92fc8448638a4bfe1eab7e5041a4c5cc39
|
|
Change-Id: Ibc378fa5f515de61bb768b4ef082638b40c94e00
|
|
Change-Id: I151957e415eff793e3d054050526b7d6892d28d4
|
|
found with
$ git grep -lP 'return\s*\(\s*\w+\s*\)\s*;'
Change-Id: Ic51606877a9edcadeb647c5bf17bc928b69ab60e
|
|
Change-Id: Ib2a311f0341d165a8f9d3f7a11ec36378fd69519
Reviewed-on: https://gerrit.libreoffice.org/14373
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I7223530ae37297a76654cd00cc1fedb56dbe3adb
|
|
...try
GetProcessServiceManager().createInstance("stardiv.UnoControls.ProgressMonitor").addText("foo", "bar", false)
in Basic...
Change-Id: I30318c3e8e671a97b6a3fe2dd9ec03add21794ab
|
|
...try
GetProcessServiceManager().createInstance("stardiv.UnoControls.StatusIndicator")
in Basic...
Change-Id: Iafc22188feb8a1d3f1b19ac4f6e209be62a44d17
|
|
Change-Id: Iebf1c42c384909f6226c25eb151985f8bc244c93
|
|
It looks like the cleanest method of getting lok_init into
a LibreOfficeKitInit.h header (in a c89 compatible way) is to
have it as a static function.
(inline is only available in C99 or later -- this is actually
available on Linux which is the only place that we can actually
use lok_init anyways currently, however given we have to keep
c89 for the C code (for MSVC) compatibility, selectively enabling
c99 would likely be more messy.)
Conflicts:
libreofficekit/Module_libreofficekit.mk
Change-Id: I0493e7a68ed5397479220bb6ba8c3db870b6dd32
|
|
Change-Id: I41ba46831f24b2960a1fe982b74a2b623e682e0b
|
|
It turns out that almost none of them were necessary.
Change-Id: I1311ed28409c682b57ea8d149bcbaf2c49133e83
Reviewed-on: https://gerrit.libreoffice.org/12133
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I28443b688f8ab752162846e5cea661f26d269cad
|
|
Change-Id: If30d43a2693c6df2d483ec135efa54ccb643fdb0
|
|
Change-Id: I2e477d66f25bde7256938ccb1f95ab26add24922
|
|
Change-Id: I6d5a952901648e01904ef5c37f953c517304d31e
|
|
Change-Id: If546680f4c16ccd733188a65d82129ec2358017b
|
|
Change-Id: I42119f656ca528286fb25d2d36c0af54b7d04a6b
|
|
Change-Id: If87cdfb2c605254f6d69baa4ca5aec09091caa68
|
|
Attempt to clean up most but certainly not all the spelling
mistakes that found home in OpenOffice through decades.
(cherry picked from commit e62c0f54ef18a5a79b76e934834b148523c69847)
Conflicts:
LICENSE
NOTICE_category_b
UnoControls/source/base/basecontainercontrol.cxx
UnoControls/source/base/registercontrols.cxx
UnoControls/source/controls/OConnectionPointContainerHelper.cxx
UnoControls/source/controls/progressbar.cxx
UnoControls/source/controls/progressmonitor.cxx
UnoControls/source/controls/statusindicator.cxx
UnoControls/source/inc/framecontrol.hxx
Change-Id: I882a1d640d931b4e89b2d19f3585fd35fdd320ca
|
|
Change-Id: Iae55083160eee86ac8301f272634dd3ae65fd847
|
|
Change-Id: Ic25bd678dc299627299b22145efd7bebcf2b39d0
|
|
Change-Id: I6517028670a953954b31599fa3e23f4c8ee8cfc9
|
|
Change-Id: I2c5c2c2e8c57796d147141748fb57a4c5645a96a
|
|
Change-Id: Ieb7956acdc24d6b18939e916e33eb12dc268e778
|
|
It appears that the C++ standard allows overriding destructors to be marked
"override," but at least some MSVC versions complain about it, so at least make
sure such destructors are explicitly marked "virtual."
Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
|
|
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
|
|
Change-Id: I59fb7843d5c9a6cf2873b6d668d0e9dccff316d2
|
|
Change-Id: I6ad8bb98f967d7bfa062ae24d9ff35837620a77a
|
|
Change-Id: I56e32131b7991ee9948ce46765632eb823d463b3
|
|
Change-Id: I0ffbc08cf769e39e8c3b7519e8d2e13ccbe6e3d8
Reviewed-on: https://gerrit.libreoffice.org/8331
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I939160ae72fecbe3d4a60ce755730bd4c38497fb
Reviewed-on: https://gerrit.libreoffice.org/8182
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic548cf07fe115c101771999a0dc8d370e57cd3ab
|
|
Change-Id: Ic0187495d8f7f64ddf9d3c202ec41201c9ac3a8c
Reviewed-on: https://gerrit.libreoffice.org/8001
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Marcos Souza <marcos.souza.org@gmail.com>
|
|
Change-Id: I0dc09b7a6ee2849bd0c2ffc31be45f81cd2c15ee
|
|
Change-Id: I9869d9709f28b68ef7b518527175589d80644668
|
|
Change-Id: I24fae431d9e2b99cd6ac937956bb401ecfebc943
|
|
Change-Id: Ia5f104bfd707bcf4e159c78ca2764c861fb0b6d9
|
|
Looks like no code instantiated these via those odd service names (except for
ProgressMonitor/StatusIndicator instantiating ProgressBar via odd
"com.sun.star.awt.XProgressBar" service name until that got cleaned up in the
previous commit).
Also looks like no code instantiates them via their implementation names either
(in which case ProgressBar/ProgressMonitor/StatusIndicator would be dead code),
but maybe there is code that dynamically constructs those implemenation names
and calls creeateInstance on them? So best leave the implementations in for
now...
Change-Id: I20b92345e343b1f776387f63d9b02a5b0a47fe21
|
|
...and create ProgressBar directly in ProgressMonitor/StatusIndicator, instead
of going via service manager.
Change-Id: I798e0c415c113cfc65d70ed17cb16aafded41a6d
|