We want to introduce another type of ScMatrix that will directly contain
DoubleVectorRefToken and operate on that. The idea is that it is pointless to
construct a ScMatrix via lots of copying around, when we already have a nice
array of doubles.
Change-Id: I3e5d7b9e2e0f9b9bf350336a8582cfd852586b3f
...as in both files the direct use of non-ASCII characters in ordinary string
literals has since been changed to use \xXX escapes instead
Change-Id: Ic3e17a9849288a02dc69d7702782fefccb7026ee
Reviewed-on: https://gerrit.libreoffice.org/20148
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Zoom level of SwEditWin is kept in sync with the client, so that the
pixel-based comment widgets can be positioned correctly. But that does
not mean in general the SwEditWin map mode should not be disabled: so
that we don't have to tweak the map mode for each and every
postMouseEvent() call and still be able to send them using logic
coordinates.
Change-Id: I6f686b93d2509d52fdd34e84a502cf04e1ce6e59
Without this, vcl::Window::ImplTrackTimerHdl() will be called on a
deleted vcl::Window.
Can be reproduced with a comment having a scrollbar in a LOK client,
then clicking on the down button of the scrollbar a number of times ->
crash on exit.
Change-Id: I5d67f96e8baa199f65ec5cf39cb5d39c8162ff33
With this, if a comment has a vertical scrollbar, then not only the
buttons of the scrollbar can be clicked on, but also the slider of the
scrollbar can be dragged.
Change-Id: I2e39e18bf60c42a878bb8bfd808f1d47be27eecb
This is similar to the mouse button down handling. When the map mode is
disabled and the map mode is in twips, then in general it's possible to
send mouse coordinates in twips. The scrollbar is usually in pixels, so
add extra code to still make this possible.
Change-Id: I0c7e404ecd7ac839e000266e396683bb7d15c505
Currently, negative scaling (mirroring) is lost in
SdrTextObj::NbcSetSnapRect, when rect is justified.
This patch cares for this.
Possibly it's better to make these changes directly in
SdrTextObj::NbcSetSnapRect?
Change-Id: I353ff01626e15b398de95e28eae78572991dfdc3
Reviewed-on: https://gerrit.libreoffice.org/20109
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
This moves us towards unifying timeouts, events, idle handlers leaving
only the OS main-loop integration in the backends.
Change-Id: Iebfb0db21777d8018b33f216b13acb4ea2068659
If a comment had a scrollbar, and the user clicked on the down arrow of
it, then the button remained in the "pushed" state, as the scrollbar
invalidations were not routed to the LOK client.
With this, the button gets back to its non-pushed state after the mouse
button is released.
Change-Id: Ie4ba5d0ec07229b0cfc08532e8e91ae25f7a4c9e
We don't support cross-compiling with MinGW currently, and in any case
if we ever attempt such again, in the meantime the free replacement
Win32 headers most likely have been updated to include the
SCRIPT_CONTROL::fMergeNeutralItems field, so no conditional
compilation is needed.
Change-Id: I38701d6c41c44952466c1ece7c8433abe67642be
set this back to its original code pre..
commit e5bc8b60ec
Date: Tue Aug 5 12:18:20 2014 +0200
to silence coverity about it
Change-Id: I9d8f1bda1a32fbf97c0bdc73edfeab9f74d6443a
cids: 1326180<->1326190
Regression from commit 2b78f2cd7b (rhbz#988516:
DOCX import: fix context stack when importing header/footer, 2014-03-05),
though that just made an existing Writer layout problem visible.
RTF/WW8/newer (drawingML) DOCX import doesn't have this problem, as those
import pictures as sw graphics, not draw ones.
<w10:wrap type="through"/> is normally mapped to our page wrap (as it uses
"through" in the "not only wrap around, but also in the holes of the shape, if
it has any" context, not in our "text should go through it, so no wrapping"
one), but for some reason in this case (most probably due to the extreme large
negative margins) Word handles the situation as our through, i.e. the text
should not go to the second page, as it would normally happen with a "Word
through" wrapping.
Work around the strange situation by ignoring the wrapping request for extreme
top margin values.
Change-Id: I20555b1fa7a769e20c40a3a5ff3873807403e937
