This is required fro two reasons:
1. For our custom LOSPSupport.OpenDocuments, it allows SharePoint site's
js code to properly find out the supported methods of the object.
Previously we only registered v.1 for it, and that made SharePoint to
assume that only older subset of methods is supported.
2. For SharePoint.OpenDocuments, which is used to register MS component
to point to our implementation, leaving out v.4 and v.5 made problems on
systems with co-existing MS Office; leftover registration of v.4 and v.5
resulted in mixed results: when opened from web view, documents used MS
ActiveX, while for documents opened from list view in SharePoint, our
ActiveX was used. Registering all versions produces consistent results.
Change-Id: I7e8d4216cce1708e676c834a465654751f079c89
Reviewed-on: https://gerrit.libreoffice.org/74776
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Build spsupp for both x64 and x86, regardless of target platform.
This allows to install the ActiveX component to be used by both
64-bit and 32-bit applications on 64-bit systems (especially IE,
which runs both 64-bit and 32-bit processes simultaneously at
least on Win10), no matter which LO (32/64) was installed.
Move the DLLs from activex feature to ooo, to copy unconditionally.
Registration of LO-specific component will be also unconditional;
registration of replacement of MSO component will need own feature.
This doesn't yet register the component in system: TODO later.
Change-Id: Iccf5e73dfae306cb777f844d40611e23c4520a13
Reviewed-on: https://gerrit.libreoffice.org/71925
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Rationale is the same as in described in commit
4aa6049062
("gbuild: treat $({QT,KF}5_CFLAGS) as cxxflags, not defines").
Change-Id: I1253e33118956b72561bd56bbc668ca345006c37
Reviewed-on: https://gerrit.libreoffice.org/73700
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... in preparation for further changes.
Thanks to Noel Grandin for the hint!
Change-Id: I2b223322d1d42099b56a74a92e3c39631d6b581c
Reviewed-on: https://gerrit.libreoffice.org/72470
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
ViewDocument3 method takes OpenType parameter, which allows to decide
if user can choose opening the document read-only or to edit.
Since we need to show localizable strings, we need to bootstrap part
of LO (l10n), which is impossible when e.g. 64-bit ActiveX DLL tries
to load installed 32-bit sal DLLs. Thus, we need a separate helper
.exe, which architecture matches the rest of installed LO, and which
handles user interaction.
Change-Id: I0ad53ba64272fb84728d2221e3dc85d3eefdda68
Reviewed-on: https://gerrit.libreoffice.org/72355
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
This prevents SharePoint from trying to download documents in browser
after they were already opened by LibreOffice SharePoint integration
ActiveX control.
The implementation just returns true, to avoid instant refresh of the
site in browser. TODO: fine-tune when understood when and why it makes
sense to return false.
Change-Id: I1ceae82db16ca8e418850fafd8c171ee6a2e039b
Reviewed-on: https://gerrit.libreoffice.org/72266
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Two use-cases here in kde5backend
1) kde or qt vclplug has already started qt event loop => just use this
loop to read KDE settings
2) no qt event loop runs (we're most likely in gtk3_kde5 vclplug) =>
start a new event loop, read the settings and stop it
In case 2) letting qt event loop run means subsequently all UI ops
need to happen in main thread. This is problematic to enforce in
non-qt-based vclplugs
In both cases, cache those settings for future use - the assumption is,
most of them are static during a session anyway.
Change-Id: Ifa203f4cdb9a753db808f945762fb131ee83393c
Reviewed-on: https://gerrit.libreoffice.org/70808
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
this copy'n'pasta blunder looks innocuous but can slow down loading
of JVM (which reads proxy settings among others) in KDE environment
significantly
Change-Id: I98f0fb107a2ee825bcd47731a5a9d15017ba63bc
Reviewed-on: https://gerrit.libreoffice.org/70806
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
The code is using expicit (mostly W) Windows API, and is independent
from the macro. Removing it here allows to catch places where some
UNICODE-dependent macro is used unintentionally.
Change-Id: I5dff40aecfc3c3dc7fc4cf7271a995a675943a45
Reviewed-on: https://gerrit.libreoffice.org/70237
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
... for My Documents and My Templates.
It seems customary to name XDG_*_DIR in all uppercase. This also
fixes buffer overrun IIUC, as osl_readLine() does not return the
newline delimiter.
Change-Id: If85ca7e6abe663e29d36b65a08d358d3d7d27c4b
Reviewed-on: https://gerrit.libreoffice.org/67741
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Since it is now possible to use C++14, it's time to replace
the temporary solution with the standard one
Change-Id: I6eea0877eaa1886b64c0cce06a43b8088cbccd8e
Reviewed-on: https://gerrit.libreoffice.org/66751
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
KDE4 is out of maintenance upstream since Nov. 2014, and binaries
provided by TDF have switched to KDE5 as the official backend.
Change-Id: I165465b56d3ba3a18912b203c06ae8fc6111c0c9
Reviewed-on: https://gerrit.libreoffice.org/60014
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
V547 Expression 'procHandle != nullptr' is always false.
The code was nonsensical overall. First, the launched process handle
was never returned by ShellExecuteExW, because SEE_MASK_NOCLOSEPROCESS
wasn't used, so GetProcessId couldn't succeed. Then, nullptr window
handle was passed to GetWindowThreadProcessId, thus never returning a
meaningful result.
This reimplements this to find the launched process' main window by
first waiting for process idle (up to 1-second delay is possible),
then enumerating all the top-level windows and checking their process.
Change-Id: I5fb4c04147b3f9414e27650a023f7844523c18bd
Reviewed-on: https://gerrit.libreoffice.org/62478
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I444c43b9d549977039f25bec2b5bf666c3e15e0e
Reviewed-on: https://gerrit.libreoffice.org/62041
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
...where "inline" (in its meaning of "this function can be defined in multiple
translation units") thus doesn't make much sense. (As discussed in
compilerplugins/clang/redundantinline.cxx, exempt such "static inline" functions
in include files for now.)
All the rewriting has been done automatically by the plugin, except for one
instance in sw/source/ui/frmdlg/column.cxx that used to involve an #if), plus
some subsequent solenv/clang-format/reformat-formatted-files.
Change-Id: Ib8b996b651aeafc03bbdc8890faa05ed50517224
Reviewed-on: https://gerrit.libreoffice.org/61573
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
Mike Kaganski