Skip to content

C
core
Dal (branch)/etiket değiştir
  1. 30 May, 2018 7 kayıt (commit)
    • Noel Grandin's avatar
      Bitmap->BitmapEx in FixedBitmap · 86555baa
      Noel Grandin yazdı 
      Change-Id: I0e409beb0d046d927b6a0c1987abec42df76727d
Reviewed-on: https://gerrit.libreoffice.org/55032Tested-by: 's avatarJenkins <ci@libreoffice.org>
Reviewed-by: 's avatarNoel Grandin <noel.grandin@collabora.co.uk>
      86555baa
    • Tor Lillqvist's avatar
      Hack to make properties work better from Automation clients · 7873bba6
      Tor Lillqvist yazdı 
      There were a couple of problems apparent at this stage when using the
ooovbaapi things from a test Automation client (written in VBScript,
to be precise).

Accessing for instance the ActiveDocument property of an
ooo::vba::word::XGlobals instance worked fine. But properties of other
objects, like instances of ooo::vba::word::XDocument, did not work.

When attempting to access any property of an
ooo::vba::word::XDocument, the code ended up calling the hasProperty()
of SwVbaDocuemnt. That function is for checking a totally different
kind of "properties", namely named form controls. Why form controls
are con-fused with oovbaapi properties I don't know. Maybe it is
intentional and as expected when using the oovbaapi from the built-in
Basic interpreter in LibreOffice. Or then just an accident in history.
Still, surely it can't be changed, that would break Basic scripts
embedded in existing ODF documents.

Anyway, from an OLE Automation client, for instance when asking for
the Content property of an ooo::vba::word::XDocument object, we
definitely don't want any form control that happens to have the name
"Content". We want an object with two integer properties, Start and
End.

Make this work by always creating an invocation factory instead of
using the object itself. Pass the invocation factory's
createInstanceWithArguments() function an extra argument indicating
this is the case of use from OLE Automation.

In the Invocation_Impl class in the stoc module, when this extra
argument is noticed, set a new mbFromOLE flag. Modify the behaviour
slightly when that is true. I am not at all sure that this will work
in all cases, but let's see, at least for simple tests so far it had
the intended effect.

Another issue was that looking up these properties was case sensitive.
This is wrong at least from languages like VBScript. Use the mbFromOLE
flag also to affect the case sensitivity behaviour.

Maybe I should simply make sure that _xDirect is null in the
Automation case? _Direct (a reference to an XInvocation) being
non-null probably means that we are using the document interface's own
implementation of XInvocation, which is probably always wrong in the
OLE Automation case. (Just see the SwVbaDocument implementations of
hasProperty() and invoke(), for instance.)

Change-Id: I2fd174f69f430893aef538cc9bf2a99d1c86b567
Reviewed-on: https://gerrit.libreoffice.org/55023Tested-by: 's avatarJenkins <ci@libreoffice.org>
Reviewed-by: 's avatarTor Lillqvist <tml@collabora.com>
      7873bba6
    • Luboš Luňák's avatar
      fix incorrect example in rtl_Instance docs · d4d64887
      Luboš Luňák yazdı 
      Change-Id: I1cb0c9bfca7ebcf8de96ef25554a41d52b9d7df5
      d4d64887
    • Stephan Bergmann's avatar
      Adapt solenv/flatpak-manifest.in to recent opens___.ttf changes · 102fc242
      Stephan Bergmann yazdı 
      Change-Id: I82173e7ab3f374e014b2ade060f44aa97451e439
      102fc242
    • Mike Kaganski's avatar
      ww8export: Fix testTableKeep · b7da22a6
      Mike Kaganski yazdı 
      The tables in the test .ODT contain a cell with text "With merged cells".
The text is supposed to wrap, so that cell height includes the two lines.
The width of the cell is 32.72 mm. When it is exported to .DOC, due to
rounding errors, the width becomes 32.76 mm. It happens that the text
width is too close to these numbers, so depending on rounding when text
layouting, it may start to not wrap in .DOC.

This just adds an extra space character to the line, to stop depend on
rounding errors.

This also reverts commits b2a05316 and
a30a36b3, which had workarounded this
issue.

Change-Id: Ifdb7a042f78a1a3cce3a385e9db865a1b8c7b134
Reviewed-on: https://gerrit.libreoffice.org/53906Reviewed-by: 's avatarJustin Luth <justin_luth@sil.org>
Tested-by: 's avatarJenkins <ci@libreoffice.org>
Reviewed-by: 's avatarMike Kaganski <mike.kaganski@collabora.com>
      b7da22a6
    • Luboš Luňák's avatar
      Revert "UITest_calc_tests: disable randomly failing assert for now" · 173c3a73
      Luboš Luňák yazdı 
      Fixed by my previous commit.
This reverts commit 27cc0064.

Change-Id: Ib64e7341251d848b4db0dbb1f58c4fcef51437ed
      173c3a73
    • Luboš Luňák's avatar
      make CharClass also mutex-protect calls to its dependent class · a2045f94
      Luboš Luňák yazdı 
      When calc_tests runs test_tdf53482_Range_contains_column_headings_file()
with Calc's threading enabled, it ends up calling ScInterpreter::ScProper()
from threads, which calls to CharClass. And while CharClass tries to be
thread-safe (guessing from the mutex usage), it forwards calls to i18npool's
CharacterClassificationImpl and cclass_Unicode, both of which aren't
thread-safe. Which makes thread safety of CharClass itself pointless.

Since CharClass already acquires the mutex anyway because of getMyLocale(),
just extend the duration for the entire call, which hopefully shouldn't
make that much of a difference.

Change-Id: I544b34d7e58c4a901f3b6e3a3ff52156b9e320a8
Reviewed-on: https://gerrit.libreoffice.org/54999Reviewed-by: 's avatarMichael Meeks <michael.meeks@collabora.com>
Tested-by: 's avatarLuboš Luňák <l.lunak@collabora.com>
      a2045f94
  3. 29 May, 2018 33 kayıt (commit)