This likely never worked as there is no SbiInstance in that step,
but worked by chance when running a module's code that was
compiled with VBA support where the VBA-only function was added as
a symbol to be resolved later during runtime and then the
SbiInstance exists and the symbol was magically resolved.
Found when trying to correct vba_tests to actually fail if all
subtests fail that then started to fail in Atn.vb because of the
Round() function being VBA-only.
Change-Id: I7d9f6e2640a73388a2a58c3d180820c6ef85abe3
Reviewed-on: https://gerrit.libreoffice.org/45425
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
The plan is to remove the getDialogInfo from LOK API but one more step
before doing that is to find out why the dialog size in 'created'
dialog callback is less than what the actual dialog after painting is.
Change-Id: I5176e175cbf7ed81c1465feeeea053c9a024fbd9
This allows registering & de-registering of non-sfx windows too, and makes the
Calc autofilter popup to appear.
Change-Id: I7cbbe94d208115aabcb6fa5f964646c7b7ce4c93
We need to tunnel more than just dialogs, so this is the 1st step to get the
Autofilter popup rendered.
Change-Id: I6523a39ddc7a6eb2a204e48ab364130a5822f548
This will help launching multiple instances of dialog from multiple
views. The earlier approach of using the UNO command strings as dialog
id would not have been useful for multi-view case.
Change-Id: I01cfb3c8b204d5654df2417efdac6b50dc920f0e
With this, we do away with initial approach of rendering the dialog on a
large surface. We now create the cairo surface with dimensions of the
dialog.
Change-Id: Icb034693c7f1c656b7daae7f5c711b5bd4d8e880
Split IDialogNotifier from IDialogRenderable and make SfxViewShell
implement it.
We now just send the dialog UNO command to the backend and wait for core
to emit a 'created' dialog callback which signals dialog creation in the
backend. The client is then supposed to send the paint commands for
rendering the dialog.
Change-Id: I1bfbce83c17955fa0212408376d6bcd1b2d2d1dd
When /opt/lo/bin/clang-format was missing, we "found" clang-format in
the last item of PATH, which doesn't make sense.
(Fix a spelling error in a formatted file to trigger the hook as part of
CI.)
Change-Id: I3b56a8ad02b4a55dba58e07286e31436a2842cf6
Also avoid librevenge::RVNGBinaryData::appendBase64Data() for
performance reasons. Times with and without the XMLBase64ImportContext
rework for sw/qa/extras/odfexport/data/embedded-font-props.odt:
- before: 1m32.254s
- after: 0m7.045s
(Need to insvestigate macOS font embedding situation in general, later.)
Change-Id: I5aa56bfbfa8dc64f19c021202a1b87618b4b2775
Reviewed-on: https://gerrit.libreoffice.org/45385
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
'man ctags' says that emacs mode will be enabled if the ctags binary is
renamed as etags or '-e' flag is provided to ctags binary.
Before this patch, the script assumes that host system has an 'etags'
binary renamed from 'ctags' program. This is not always the case in all
hosts. Eg: In Fedora, 'etags' binary is provided by emacs-common package
which doesn't understand the flags given later in the script.
It is safe to just explicitly enable the emacs mode via '-e' flag to the
ctags binary.
Change-Id: Ic7ded56cff32683fc5e9d3fcc7405e79da4c23b7
Reviewed-on: https://gerrit.libreoffice.org/45358
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: pranavk <pranavk@collabora.co.uk>
This also fixes a potentially large memory leak depending on zoom,
and particularly with non-paginated rendering.
Change-Id: Ia24e0b7baea725020f000a369708b0be3fc20c95
Reviewed-on: https://gerrit.libreoffice.org/45414
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Not exactly, though. The FIXME said "Make this a comparison operator
at the TokenArray?" but I think that would be misleading as the code
in question specifically does not check the TokenArrays for being
completely identical; it intentionally ignores the RPN part. So make
it a member function 'EqualTokens' instead.
Change-Id: I15d840c422844fa144415a76c1f8fcbd6cae3c83
Reviewed-on: https://gerrit.libreoffice.org/45404
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
...see mail sub-thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-November/078966.html>
"Re: New Defects reported by Coverity Scan for LibreOffice" about cid#1424266 et
al; lets see if this makes Coverity happy again...
Change-Id: If488b9f61f084f2286b35326917741051ec8d5ce
Reviewed-on: https://gerrit.libreoffice.org/45403
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
We don't need this info ourselves, but when converting the flat ODF
output to other formats, this information is hard to find out, so state
them explicitly. Names correspond to existing CSS ones, where it's
necessary to state these explicitly. The EPUB export will make use of
these attributes.
(It is unclear why the test fails on the windows_msc_dbgutil_32 slave,
it works for me locally.)
Change-Id: I05030b6a14aca842e5a740786f3743e9ae838293
Reviewed-on: https://gerrit.libreoffice.org/45384
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
e.g. when compiling against system libxml2, which in turn includes system
ICU include files, which may use C++11 chart16_t. So assume that -std=gnu++14
is acceptable for any GCC version for which at least on of -std=gnu++17,
-std=gnu++1z, -std=c++17, -std=c++1z is acceptable, and just fall back to C++14.
Change-Id: Id9f07ab4f419e5683f4fb9c9b2d3bdda251cdd1b
Reviewed-on: https://gerrit.libreoffice.org/45409
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
