The related code is not being used now...
So, it's safe to just correct it before it is put
to use.
Change-Id: I1ba5f1d6d511c965c0ce08dd08bfcabc567da2c3
Reviewed-on: https://gerrit.libreoffice.org/36103
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
The EndDialog callback Hdl was disposing the Dialog, which is a little
troublesome since the stack wants to go back through the Dialog code
when the callback is done.
Rather just the more normal synchronous Execute() style of Dialog
execute, instead of the asynchronous StartExecuteModal.
Change-Id: I14933bd475da228c9648a6fa0564bda4a60d9d12
Reviewed-on: https://gerrit.libreoffice.org/36074
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
According to Extensible Markup Language (XML) 1.0 (see
https://www.w3.org/TR/2008/REC-xml-20081126/#sec-prolog-dtd),
all parts of XML prolog (including XML declaration) are optional,
so XML stream without <?xml ... ?> is well-formed (though not
valid).
XMLFilterDetect uses only XML declaration to detect if the file is
to be processed further. However, this creates problems with said
documents.
This commit checks if the document has MediaType set to one of
known XML media types, in case when the check for XML declaration
failed.
Change-Id: I31627c0e3a39bee241f609650280ebac3f1cede8
Reviewed-on: https://gerrit.libreoffice.org/36101
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
When PROPFIND fails on a WebDAV resource, its IsDocument property
stays undefined, and so stream creation fails. Proposed solution
is to default to IsDocument=true for all WebDAV documents where
we cannot get the property from server.
Such resources also fail to return their locking options, so
defaulting to server properties. When later locking is attempted
on it, the attempt fails with user notification (a dialog saying
that getting information from server failed). Proposed solution
is to check Content-Disposition header in such resources, and in
case it's attachment, disable lock on this resource. The rationale
for this is that "In a regular HTTP response, the Content-Disposition
response header is a header indicating if the content is expected
to be displayed ... as an attachment, that is downloaded and saved
locally" (see MDN:
https://developer.mozilla.org/en/docs/Web/HTTP/Headers/Content-Disposition
Also, Content::getProperties wasn't ready for PROPFIND returning
empty result.
Change-Id: I91dbffa8bdf0fe900c11d2f8c9c9394d2104bb49
Reviewed-on: https://gerrit.libreoffice.org/36090
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
i.e. Bitmap::HsGreyPalette checks that the palette has entries before calling
Palette::IsGreyPalette
Change-Id: I287647869ad615327f3119b7798f410e22140302
There is lots of (Windows-only) code that relied on sal_Unicode being the same
as wchar_t, and the best change may be different in each case (and doing the
changes may be somewhat error prone). So for now add SAL_U/SAL_W scaffolding
functions to sal/types.h, remove their uses one by one again, and finally drop
those functions again.
Change-Id: I2cc791bd941d089901abb5f6fc2f05fbc49e65ea
Reviewed-on: https://gerrit.libreoffice.org/36077
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
My Windows 7 KVM QXL VM fails the bounding rect test with:
complextext.cxx:98 VclComplexTextTest::testArabic equality .. failed
- Expected: 71x14@(0,1)
- Actual : 70x14@(1,1)
This doesn't happen using a SSHd on Cygwin64 based session.
Adding a SAL_DEBUG to WinSalGraphics::GetGlyphBoundRect shows many
different glyph rects, which - probably by pure chance - almost add
up to just a single pixel line missing on the left.
So this simply drops the first pixel column, if the bounding rect
starts with an offset. Works for me.
Change-Id: Ia496a208523a9c358d4128ecad887b5c77283fbc
Reviewed-on: https://gerrit.libreoffice.org/35647
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The rare crashes in MenuFloatingWindow::ImplGetStartY() and
MenuFloatingWindow::ImplScroll(bool) likely happen because
of a disposed Menu.
Let's guard against invalid accesses.
Change-Id: Ie31240abbc48c06edd40d0a95f319725cdb3db16
Reviewed-on: https://gerrit.libreoffice.org/36026
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
One big paragraph spacing control was splitted
to separated widgets. It will be possible to
reuse that in the sidebar. Also layout is better
because explicit size setting is no longer needed.
Change-Id: Ieb200af4a9a6120ae03b22b27da56256aa816193
Reviewed-on: https://gerrit.libreoffice.org/35801
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
This is a squashed commit of the pivot chart implementation.
Some of the changes:
- Add pivot chart specific (pivot table) data provider which
provides the data from a pivot table to the associated chart.
- When inserting a chart and the cursor is in a pivot table,
in that case insert a pivot chart
- Modify the pivot chart when the pivot table changes
- Collect and set the number format for the values
- isDataFromSpreadsheet check for the creation wizard
- In ChartView (and VLegend) check if the data provider is a
pivot chart data provider and get the pivot table field names
to create the buttons on the UI.
- Adds the functionallity to show a filter pop-up (from calc)
when clicking on row / column / page field buttons.
- Remove (X)PopupRequest as we won't need it.
- Add ODF import/export for pivot charts:
+ Added loext:data-pilot-source attribute on chart:chart
which is the internal name of the pivot table with which the
pivot chart is associated with. If the element is present, then
the it means the chart is a pivot chart, else it is a normal
chart
+ Added service to create pivot chart data provider through UNO
+ Add new methods to XPivotChartDataProvider to create value and
label data sequences separately from the data source, which is
needed for pivot chart import
+ When importing defer setting the data provider until a later
time when we know if we are creating a chart od a pivot chart
- Pivot chart ODF round-trip test
- Add table pivot chart supplier API:
This adds the XTablePivotChartSupplier and related interfaces so
we can access, create, delete pivot charts from UNO in a sheet
document. With this we now distinguish between normal charts
and pivot charts. This was mainly needed because we can't extend
the "published" interfaces of TableChartSupplier.
- Added an extensive test, which uses the API to create a new
pivot chart when there was none, and checks that the pivot chart
updates when the pivot table updates.
Change-Id: Ia9ed96fd6b1d342e61c2f7f9fa33a5e03dda21af
Reviewed-on: https://gerrit.libreoffice.org/36023
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
