In order to indicate the entire row or column
(for the benefit of a spreadsheet program that may eventually
increase the supported number of rows or columns it supports)
a short-handed form of the range can be used
like "B:B" for the entire column,
or "1:10" for the first 10 rows of all columns.
Shorthand is nicer for humans
and allows for future expansion of row/column space
This reverts 24.8 commit a29d91ac40
xlsx export: never export short-hand version of range address
which reduced the likelihood that we will ever see
such a range, because Excel seems to always
write out the full address.
However, the shorthand version is definitely valid for Excel.
Earlier patchsets checked that the new method and the old method
returned the same values for all existing unit tests.
Change-Id: I7677dfc207771a32222095416f728f7cd34a4f75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166570
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
After the change of tdf#139858 the comments checkbox was not remembered anymore after closing the dialog. In order to fix this issue, additionally check not only the NOTE flag but also for the ADDNOTES one.
Change-Id: I8b24d231313b57a05b7e527c0865686762e5a2b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166762
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Tested-by: Jenkins
Using the Double.compare() method is often preferred over the == comparison
operator for comparing double values due to several reasons:
Handling NaN (Not-a-Number) values: The Double.compare() method correctly
handles NaN values, while the == operator does not. If either of the operands
is NaN, the == operator will always return false, regardless of the other
operand. In contrast, Double.compare() will correctly evaluate NaN values
according to the IEEE 754 floating-point standard.
Handling positive and negative zero: The == operator treats positive zero and
negative zero as equal, whereas they are distinct values in IEEE 754
floating-point representation. Double.compare() correctly distinguishes
between positive and negative zero.
Robustness against rounding errors: Floating-point arithmetic can introduce
rounding errors, causing two double values that should be equal to differ
slightly. Directly comparing them with the == operator might yield unexpected
results due to these small differences. Double.compare() allows you to define
a tolerance level if necessary, providing more control over how equality is
determined.
Consistent behavior: The behavior of Double.compare() is consistent and
predictable across different platforms and JVM implementations, as it follows
the IEEE 754 standard. On the other hand, the behavior of the == operator
might vary depending on the platform and compiler optimizations.
Suitability for sorting: Double.compare() returns an integer value that can
be directly used for sorting double values in ascending or descending order.
This makes it convenient for sorting arrays or collections of double values.
Overall, while the == operator might work in some cases, using
Double.compare() provides more robust and predictable behavior, especially
when dealing with floating-point numbers in Java.
Change-Id: I5756936a0d2b4fe11b9113ddd33b6ae691f5103f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166796
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
if msvc -analyze is used
Change-Id: I5905447a79e8e50d70281e0c230d1ce3b13fc475
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166704
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Number formats can have different keywords in different
languages: D - Day(EN), T - Tag(DE).
This can cause problem when we use format which will not
be recognized by current number formatter, then we put
unknown keyword as string in quotes. As the result we get
for example: formatCode=""TT."mm".JJJJ""
The problem exists especially in multi-language setup in LOK
when we use non-English languages:
1. open xlsx using FR
2. join with DE
3. modify number formats in both
4. leave spreadsheet with both so it will be saved
Result: after we open it again we have some keywords as
strings, user has to apply new number format to see the
real value
Signed-off-by: Szymon Kłos <szymon.klos@collabora.com>
Change-Id: Ice04d890b38cd2d08d06f41fc7b3cc55f64fadbe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166711
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
Implement a proper list mode for VerticalTabControl.
Before this was only used in the Hyperlink dialog with large icons.
Change-Id: I227643392ef4840a705555b379734e2993db0f13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166702
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Fixed row height can crop cell content, including images
anchored as character. Resizing the row height with mouse
was not possible there, because selection of the cropped
image avoided to drag & drop the horizontal cell border.
Change-Id: I6dde79e77563468059794548b6c058cad61586a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166795
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
It was not possible to select and edit the content of the bottom
cell, if an image cropped by the fixed row height "covered" it,
i.e. the image was in the previous row, anchored as character.
Note: table cells with fixed row height are usable to crop images
easily, with a single drag & drop, according to the requirement of
the text layout, while the cell above or bottom of the cell with
image is for the caption of the image. This is very useful to
adjust a book layout with sections with multiple columns and
illustrations.
Change-Id: I8683b4066db6ce43549ec3aa69b0e639a59e3681
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166794
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
If the cursor wasn't in the table, only column width of text
tables was resizeable by dragging the horizontal cell borders:
It was possible to drag the horizontal border, showing its
preview, but the drop cancelled the operation instead of
resizing the table row according to the selected position.
Now it's possible to resize the height of the table rows
without moving the text cursor inside the table.
Note: This is important for floating tables containing images:
here it's not possible to put the cursor inside the table, if
the image is cropped only by the cell borders: so it was not
possible to resize the row height.
Change-Id: I181d79a28cdeefabb796b7b978ee1368a9378888
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166793
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
The outside color still needs to be white for the content
so only apply the fix for tdf#157795 to the alpha mask.
Change-Id: I7486b2c9062ca96bf127f2bce6b1bd5e65d00ff6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166806
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Tested-by: Jenkins
Also the key path was wrong in SlsCacheConfiguration.cxx:
MultiPaneGUI/SlideSorter/PreviewCache
but in Impress.xcs we have
MultiPaneGUI/SlideSorterBar/PreviewCache
hierarchy so this may actually now start to work :)
Change-Id: I4b552be713e6e157edb45692ba78101429aa1c85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166755
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
2 pbs here:
1) bug described in the bugtracker, the uncheck isn't kept
=> just remove all the buggy GetOldItem stuff
2) after unchecked the option then saving the file and reloading the file, the option is still checked
=> change the buggy
rOutSet->Put( SvxFormatSplitItem( eState == TRISTATE_FALSE, _nWhich ) );
to
rOutSet->Put( SvxFormatSplitItem( eState == TRISTATE_TRUE, _nWhich ) );
In fact, I just mimicked the code used for "keep paragraphs" which works well.
Also change the QA test since "allow to split paragraph" is checked by default
so if the QA simulates a click on it, we expect the value to be false when dialog is opened again
Change-Id: I947feb02e0c282304621a252ad5e4c168c1d295a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166774
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
xPropertySet->getPropertyValue("_MarkAsFinal") can retrieve an Any
containing a boolean or a string
Change-Id: I1c8bafc12cdaf7fb98d3500507ba83b3e90f69cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166763
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
I had done these a while ago, when I looked into extending loplugin:ostr to do
more automatic rewriting, and these were places where I needed to do something
manually, for one reason or another, because the automatic rewriting would not
pick it up correctly.
However, I got distracted, and a wholesale automatic rewrite would still run
into cases where an _ostr/_ustr instance from a library's .rodata would still be
referenced after the library has already been dlcose'd. So I never came around
to finishing all that.
But there appears to be renewed interest in (automatic) rewritings here now, so
it probably makes sense if I share this part of my work anyway.
Change-Id: I3da9d38398e4bca373cb0000a9d34b49a36ad58a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166792
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
...after 87e0feafd3 "use more concrete UNO classes
in writerfilter (SwXDocumentSettings)"
Change-Id: I4f57ef975dbee32b6f9ff6654b66483c8f1083a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166791
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
by copying the improvements from the normal find-can-be-private
script.
Change-Id: I3cb23022ca33d3008af962fa99b5b0907fe753b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166783
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
