.... and references. This gives numerous false positives as pointers may
be re-set prior to shutdown, so needs a white-list.
Change-Id: I19a011c6f19501cc31b3d9ae76b599296f132478
Reviewed-on: https://gerrit.libreoffice.org/19949
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
CHECK_GL_ERROR() is now zero-cost in a production build, so no reason
to avoid it.
Don't check for OpenGL errors after glX or wgl calls. They don't
generate OpenGL errors but use the X and Win32 error mechanisms, as
far as I see.
Change-Id: I8f97ef434cbdc89d6e345a247456cfc4a1a82bb6
Earlier, CHECK_GL_ERROR() always called OpenGLHelper::checkGLError().
That function looks up the OpenGL error status using glGetError(),
which might be a not so light-weight operation, and outputs error
information using SAL_WARN(). In a production build where SAL_WARN()
is a no-op anyway, that is fairly pointless.
Change-Id: I2d044bff6128a8ac7739020f8e414d7d3615e8d5
On one hand, neither our binary DOC import, nor Word maps the "TOC
Heading" style to something special, and that's how the DOCX import
added that property to some paragraphs in the document, moving the
as-char picture from the first to the second page.
OTOH, the DOCX export filter has a lcl_guessQFormat() function that
explicitly assumes that such a style name exists in Writer document
models, so again it doesn't make sense to handle this style name with
special care.
Change-Id: I3af548930f9683695fc3ad56b486e013f107d61a
It was possible to set a tooltip for a certain toolbar entry.
However, this hasn't been used since that tooltip needed to be repeated for each occurence of the same command.
Instead, a TooltipLabel property has been introduced lately (see 9c2f197e8e).
This doesn't affect extensions (They have their own format to specify toolbars).
Change-Id: I0f0fd05b310bb49dd5b4123e31d3e7fec997dd15
This fixes a buffer overflow writing over the end of pCaretXArray,
which can happen e.g. when drawing mnemonics in the password dialog.
Based on a similar calculation of nCurrIdx found in
GenericSalLayout::GetCaretPositions().
Change-Id: I7d723cf8cfaeb66f340c7d9ea5b3bc728c6d6209
Reviewed-on: https://gerrit.libreoffice.org/19385
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
This may happen if the last RPN token is put and the function has a
ForceArray parameter but now again would be wrong if not all parameters
are ForceArray.
Change-Id: I890fb6b5b88337033cfcf2e8189371ee39461205
Regression of b5cd11b4b0
It was always wrong to propagate ForceArray already if a function had a
ForceArray parameter *somewhere*, we need to do this per parameter
instead.
Change-Id: If188d45366279d9a7bf641edc7e4dd7095d6d035
... file format by default if the requested filter does not exist.
Much better to write an error message and do nothing.
Change-Id: Ie5404772e7aae5751126bd4c2784b58177804448
JunitTest_sc_unoapi crashed when accessing a disposed ScTextWnd from
~ScAccessibleEditLineTextData(), but the ScTextWnd::dispose() would also
call ScAccessibleEditLineTextData::Dispose() and clear mpWindow, so it
seems impossible to observe a disposed ScTextWnd in the dtor?
Change-Id: If571ee61d9a29601acb1de552ec1b9cc36d0d51e
