summaryrefslogtreecommitdiff
path: root/svx/xml/SvxUnoTextContentEnum.xml
AgeCommit message (Expand)Author
2012-06-22.xml files don't need executable bitsMichael Stahl
2011-03-12Merge commit 'ooo/DEV300_m101' into integration/dev300_m101Thorsten Behrens
2001-03-08changed dtdChristian Lippka
2000-11-16#80400# added Author TagChristian Lippka
2000-10-20#78916# added missing entitiesChristian Lippka
2000-09-18initial importJens-Heiner Rechtien
generated by cgit (git 2.34.1) at 2025-01-24 21:47:24 +0000
mmit/odk/source?id=6cbb60688a90ee473563f5ee3f0950ed58eb41dc'>Replace an instance of MAX_PATH (plus some) with 32767Mike Kaganski ... which is the approximate maximum of Windows API, as documented in https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation Change-Id: Id166f425238e50d4131f72bcfd22b5268dea0c3f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163915 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> 2023-01-27Remove support for AIXStephan Bergmann As discussed in the mailing list thread starting at <https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html> "Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)", the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is apparently dead and should thus be removed. However, that was the only bridge implementation for AIX, which implies that support for the AIX platform as a whole is dead and should thus be removed. Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2022-09-15cid#1500416 Resource leakCaolán McNamara Change-Id: I090e10604562665cf22aa98758e81dd398f4f9c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139997 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> 2022-08-18cid#1500586 Resource leakCaolán McNamara Change-Id: I32d837af7574f6eb4ac7db4759139d0b78f63e75 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138479 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> 2022-04-11-Werror,-Wstrict-prototypes (clang-cl)Stephan Bergmann Change-Id: I72e35f51eb607662608ccaf944bec64ed422cef4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132835 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2020-12-05Silence cid#1470402 FB.DM_DEFAULT_ENCODINGStephan Bergmann ...where the default encoding should be the appropriate one for reading the Runtime.exec output Change-Id: Ib64bfcbcca985f2de506f8628b506e6dc7bfc035 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107255 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2020-12-03Replace unowinreg.dll with execution of `reg QUERY`Stephan Bergmann The SDK's <https://wiki.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/ Transparent_Use_of_Office_UNO_Components> on all platforms included the Windows- specific unowinreg.dll in generated jars (so that those jars, when distributed to a Windows environment, would find a LO installation by inspecting the Windows registry). That unowinreg.dll was originally built as a 32-bit DLL (though when building a 64-bit Windows LO, it happened to be built as a 64-bit DLL). For non-Windows LO builds, it could either be built locally with a MinGW toolchain (--enable-build-unowinreg) or downloaded from dev-www.libreoffice.org. However, that had various issues: For one, unowinreg.dll was not necessarily available in a distributed jar as a 64-bit DLL for use with a 64-bit JRE on Windows. (Theoretically, running such a jar with a 32-bit JRE to access a 64-bit LO installation's URE jars could have worked. But practically, those URE jars in turn require native DLLs, which would then not have been available as 32-bit DLLs for use in the 32-bit JRE.) For another, at least the unowinreg.dll resulting from --enable-build-unowinreg on Fedora 33 would have had a dependency on libgcc_s_dw2-1.dll that would generally not have been available in a target Windows environment. There appears to be no pure Java way to read the Windows registry, but instead of using a native code DLL for that, it appears to work just as well to call out to reg.exe and parse its output. This removes the --enable-build-unowinreg and --with-mingw-cross-compiler configuration options. (The sole use of the MinGW toolchain in LO was for building unowinreg.dll.) Change-Id: I3283ea38c884d3221a205e5ab6ec99a2691ef474 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107140 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins 2020-08-21Fix typosAndrea Gelmini Change-Id: I8dc0cdcfe6bd90efc596df28e6c6d968b92618b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101098 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins 2019-11-19loplugin:fakebool (clang-cl)Stephan Bergmann ...plus follow-up loplugin:implicitboolconversion and loplugin:redundantcast Change-Id: I9fc9c5cb46fbb50da87ff80af64cb0dfda3e5f90 Reviewed-on: https://gerrit.libreoffice.org/83207 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-11-17cid#706181 Use of untrusted string valueCaolán McNamara use an annotation here and add one to the windows equivalent Change-Id: Ife54949c2e89ae606d7931be82807db4bbb132dc Reviewed-on: https://gerrit.libreoffice.org/83024 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> 2019-03-31tdf#120703 PVS: Silence V575 warningsMike Kaganski V575 The potential null pointer is passed into 'foo' function Add asserts to those cases that are related to OOM cases. There's nothing to be done if the assertions fail anyway. Change-Id: I92ac95d44f512aa1948b1552b0e1f6da695a9f92 Reviewed-on: https://gerrit.libreoffice.org/70008 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> 2018-09-24loplugin:external (clang-cl)Stephan Bergmann Including: * expanding STDAPI to its definition (as per <https://msdn.microsoft.com/library/ms686631(vs.85).aspx> "STDAPI"), to add __declspec(dllexport) into its middle, in extensions/source/activex/so_activex.cxx; as discussed in the comments at <https://gerrit.libreoffice.org/#/c/60691/> "Get rid of Windows .def files in setup_native, use __declspec(dllexport)", having a function both listed in a .def file EXPORTS and marking it dllexport is OK, and the latter helps the heuristics of loplugin:external; however, the relevant functions in extensions/source/activex/so_activex.cxx probably don't even need to be exported in the first place? * follow-up loplugin:salcall in sal/osl/w32/file-impl.hxx Change-Id: Ida6e17eba19cfa3d7e5c72dda57409005c0a0191 Reviewed-on: https://gerrit.libreoffice.org/60938 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2018-09-21Get rid of redundant odk/source/unowinreg/win/unowinreg.defStephan Bergmann ...similar to 28b4f4aeaf160c7721dfecf5bd2445d7dbc6f01c "Get rid of Windows .def files in setup_native, use __declspec(dllexport)". And JNIEXPORT (with which the listed functions are decorated in odk/source/unowinreg/win/unowinreg.cxx) already implies __declspec(dllexport). Change-Id: I45fd1d50cd3b072d124002e469c70eb1d6ed7610 Reviewed-on: https://gerrit.libreoffice.org/60819 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 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-02-01odk: MSVC: pragma warning: make more specific, remove obsoleteMike Kaganski Change-Id: Ie5957edb3954507505a7df9fad9f8da6b87b09d0 Reviewed-on: https://gerrit.libreoffice.org/49038 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> 2017-10-27loplugin:includeform: odk (Windows)Stephan Bergmann Change-Id: I654aa2cf1175f91619b70c9257e88f7006b0c04c 2017-10-23loplugin:includeform: odkStephan Bergmann Change-Id: Ic8ede7a0377d9ec4f360b63889e0ccf3c5dda93f 2017-09-27cppuhelper_detail_findSofficePath: use Unicode on WindowsMike Kaganski On Windows, UTF-8 is never current locale encoding; so using 8-bit strings will always fail for paths containing characters outside of current codepage. Also fix leaks caused by failing to release its result: previously it could return either result of getenv (that shouldn't get freed), or an allocated string, but never got freed; now the result is always allocated and properly freed. Change-Id: I8b255dea20040eec0572de2b34280749fe8f071c Reviewed-on: https://gerrit.libreoffice.org/42743 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> 2017-09-18Some more WIN32_LEAN_AND_MEANMike Kaganski Change-Id: Iadb0ebb66809c192fb817b8c7cf2f8cdb4d0b874 Reviewed-on: https://gerrit.libreoffice.org/42419 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> 2017-08-31loplugin:constparams: odk (clang-cl)Stephan Bergmann Change-Id: I2daf0b0868d4bdfb412575b25dbe644e76607342 2017-03-25Fix typosAndrea Gelmini Change-Id: I14dca0d55c09187690dc1d94936c40b890ca5cea Reviewed-on: https://gerrit.libreoffice.org/35637 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr> 2017-01-09New loplugin:externvar: odkStephan Bergmann Change-Id: I1f60c6b606a1ac96acbfa0777797acdaaea38c3c 2016-12-16-Werror,-Wstrict-prototypes (clang-cl)Stephan Bergmann (sal/inc/rtllifecycle.h only hits on Windows as that is the only platform that happens to actually include it in a C compilation unit, sal/osl/w32/dllentry.c) Change-Id: I2878b52daf713ea45eaa2968cc5d2686b86abfe6 2016-10-16clang-cl loplugin: odkStephan Bergmann Change-Id: I8c524bd6522a04339d5e30d6e315347a48b6473f Reviewed-on: https://gerrit.libreoffice.org/29859 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>