But function definition uses "pSFrom" instead anyway, so consistently use param
names from definition in declaration.
Change-Id: I03fb8dd0fbab5c84f89c7276849d62f9a17cbfea
...that were apparently meant to flag cases where conversion from old tools
strings to rtl strings was done wrongly. But that flagging is probably of no
use: SAL_INFOs are usually disabled, so won't be noticed; and SAL_WARN or assert
would not be acceptable, as cases like 'nLen == 0x0FFFF' can legitimately
happen with long strings. I did a successful 'make check' with these SAL_INFOs
temporarily turned into assert, so there seems to be at least no gross
conversion error remaining.
Change-Id: I57f11db9119fb12555e3bfef17c077ee5eef3844
...deriving from VclReferenceBase. Complicated by the fact that the argument
type may be incomplete at the time of template instantiation. So this approach
may be less precise than the change to loplugin:vclwidgets from
cbf5b21f2a "Catch some misuses of VclPtr
construction" when the argument type becomes complete later in the comilation
unit. However, this approach would also catch the two misuses in UnoControls
found by cbf5b21f2a, so go with this approach for
now and revert the change to loplugin:vclwdigets.
Change-Id: I7888f23d2b9e2db81ae2ce4bf4c8277912317685
Reviewed-on: https://gerrit.libreoffice.org/31966
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Ito probably made sense only with bitmap fonts which we no longer
support, and if we don’t need the fallback for printer devices then we
don’t need it on screen either (that whole printer/screen distinction
needs to die someday).
Change-Id: Icf77cd70f0f1b2c186a3c856900295caba72e903
Reviewed-on: https://gerrit.libreoffice.org/31914
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
This reverts the following commits:
commit 722f4e1d86
tdf#104573 - Assertion failed: SolarMutex not locked
commit f04ec99f5e
tdf#104573 - Assertion failed: SolarMutex not locked
commit 71b1e3ff63
tdf#104573 - Assertion failed: SolarMutex not locked when trying
commit e794ce1eef
verify that we hold the SolarMutex when ref-counting VclPtr
IRC discussion:
<noelgrandin> sberg, maybe I should revert this whole "VclPtr assert" series, I don't have mental bandwidth to sort this out properly now
<sberg> noelgrandin, what I fear is that you'll end up adding lots of SolarMutex locks to small places, where the proper fix would be to add it further out; and once such a dreaded recursive SolarMutex lock is in place (but needlessly so, once the proper fix is done), it's hard to clean that up again
<noelgrandin> sberg, yeah, in that case I'll just remove all of this, leave it for another day
Change-Id: Ie4f84b72b79a1b7e80164b5c7693af398c2c569a
Reviewed-on: https://gerrit.libreoffice.org/31946
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
all of them work, except "Fall" doesn't look right, but it has
the exact same problem under gtk2/gen to.
Change-Id: I73cb9c0fb8211f727198be78d90d4f80a4f8c7c8
Reviewed-on: https://gerrit.libreoffice.org/31214
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Looks like the XRestartManager keeps all command line arguments when
restarting, so it also keeps --safe-mode.
Solution is to add a flag file when restarting from safe mode,
to prevent going into safe mode again.
Change-Id: I9820d3ccbddf98b0bf6132f254c989f52ea5e808
Reviewed-on: https://gerrit.libreoffice.org/31913
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
sal_Bool and sal_uInt8 are typedefs for the same underlying type, so any use of
ORowSetValue with sal_Bool instead of bool, apparently intending to treat the
value as a boolean, actually treated it as a TINYINT. (See e.g. recent
7b0c57b2fa "some compilers don't like implicit
bool-to-ORowSetValue conversion".)
Now that there's no way to create a sal_uInt8 ORowSetValue, getUInt8 and the
m_uInt8 union member can probably go away, too.
Change-Id: Ia27554f76e7e9edce6410284b578064573e54fd3
Reviewed-on: https://gerrit.libreoffice.org/31909
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
There was a race condition that the OpenGL code was initialized before
the old report has been uploaded. Therefore the OpenGL setting was
overwritten by the new start and we were not getting the old value.
Now we store any value that wants to be added before the dump.ini is
ready in a temporary map and will write them as soon as we write all the
common information.
This problem was introduced by the dialog requesting permission to
upload the crash report.
Change-Id: I29391a1ff56bac6381218c5a4aefb58c2c03f024
Reviewed-on: https://gerrit.libreoffice.org/31846
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
For markers (resize markers, anchors,...) we contain them all in
one image atlas. This was generally done because of resource
limitiations in Windows 95/98 which aren't a problem anymore in
present systems.
This is however problematic in HiDPI as we scale the image and
the coordinates of aren't correct anymore. Another problem is
that it uses its own cache instead of common cache in
ImplImageTree. So this commit extracts all the markers into its
own images for galaxy theme and uses them when we scale.
In the future when we extracted all the markers to its own
images for all icon themes we can remvoe the old code with the
image atlas.
Change-Id: Ibee181b529d30e20050df8cd396d338bd53532c0
Notes
(*) In SC, BULK_DATACHANGED was or'ed into the hint id. Replaced with a
dynamic_cast check.
(*) In SC, removed the hint id field from ScIndexHint, no point in
storing the hint id twice
(*) Fold the SfxStyleSheetHintId enum into the new SfxHintId enum, no
point in storing two different hint ids
(*) In some cases, multiple #define's used to map to the same SFX_HINT
value (notably the SFX_HINT_USER* values). I made all of those separate
values.
Change-Id: I990e2fb587335ebc51c9005588c6a44f768d9de5
Reviewed-on: https://gerrit.libreoffice.org/31751
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
...base template" (like a90d4d5f03 did for
OSLOutputStreamWrapper), in preparation for
<https://gerrit.libreoffice.org/#/c/31679> "tdf#88206 replace
cppu::WeakImplHelper* in unotools".
Beats me why a solution like 4f918cd5da
"comphelper: give up on the XPropertySetInfos for now" apparently doesn't work
there---almost feels like MSVC recursively treats as dllexport'ed all the (non-
llim-/export'ed) base classes all the way down until reaching a template.
Change-Id: Id42610e7fd5c5762dffdeb15623bfe3a37ec0aa6
Reviewed-on: https://gerrit.libreoffice.org/31732
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Since commit a4dee94afe Writer no
longer forces drawing objects to be entirely on one page. However since
there is only one SdrPage for the entire document, a drawing object
dangleing off the bottom of one page will be painted again on the next
page, which is clearly undesirable since Word doesn't do that
(and it also destroys the nice invariant that a fly on page N never
overlaps a fly on page N+1).
So force the SdrPageView code to ignore the drawing object on the next
page, by passing in the area of the page frame so that
ViewObjectContactOfSdrObj::isPrimitiveVisible() can verify that the
anchor position of the SdrObject is actually on the painted page.
This requires passing in another parameter; in the usual case the
DisplayInfo::maRedrawArea already contains the page frame since
commit 8af09bf332, but there are special
cases in SwFrame::Retouch() and SwFlyFrameFormat::MakeGraphic() where
some sub-area is passed in, which cannot be used to check the anchor.
Change-Id: Ia0476216ca41dbdaa3de1063fa18cb94fe2e5ae8
