A connector shape can be connected to a shape, if the end of connector shape is released inside the target shape, it will automatically attach to the best possible connection point.
It takes into account the shape type, geometric properties, and
user-defined glue points.
In this case, if we export the ODP file to PPTX, we need to use the GetConnectorRule() method to get the correct connection index(idx).
this regression is
caused by commit 4d15351718
(tdf#149697 PPTX export: fix changing place of connection points).
Change-Id: I8eda059e72f595edc62fd5bc7f3e6466988af5bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181226
Tested-by: Jenkins
Reviewed-by: Nagy Tibor <tibor.nagy.extern@allotropia.de>
Previously, it required for some reason, that in order to be found,
the new paper size must be better than the previous-best, in *both*
dimensions. Thus, if the previous-best e.g. matched one dimention
perfectly, but not the other, no better match could be found.
Change-Id: Ia8cd4fd98f324c8450577859dbdd21831b66e2e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180164
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
test drive the new bin/find-unneeded-includes --fwdecl mode
with iwyu 0.23 instead of 0.21, this seems to find more unneeded
fw declarations
Change-Id: I451e571c70eb74f46c799753e3c5a53c0110da36
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/179707
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
...was made by: Iefb9d97e0eb10a04c39b515b11e549aeb7be8f25
This regression occurred because there is a feature in MSO that allows
the shape of a placeholder to be changed. In this case, the placeholder
is converted into a custom shape after the import and saving custom shape from .pptx to .ppt didn't work.
Change-Id: I85305b65742da8b4966d4956b9141c59b4563973
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172091
Reviewed-by: Nagy Tibor <tibor.nagy.extern@allotropia.de>
Tested-by: Jenkins
The events may be processed after the shell has been destroyed. This is
happening reliably after commit e2bfc34d14
(Reimplement OleComponentNative_Impl to use IGlobalInterfaceTable,
2024-03-11) when controlling LibreOffice from external Java scripts; but
obviously, it could happen before as well.
Now SotObject inherits from cppu::OWeakObject, instead of SvRefBase.
Change-Id: I73a3531499a3068c801c98f40de39bdf8ad90b2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164458
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Turns out there was already a function MSWordStyles::CreateStyleId()
doing the same thing as FilterChars(), presumably better.
Change-Id: Idd0129c753841b86bd026e1300aa57a56721c89e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146609
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Without a correctly formatted ID, LO was unable to import
the shape into the spreadsheet. Now at least the button
shows up and can be pressed.
MS Word already showed the button before the patch,
so nothing there has changed. That suggests that our
problem may be more during import.
This code path is also followed by DOC and DOCX formats,
but they do completely different things with the results.
This is super nasty code...
Change-Id: I383736a7de9c3e94b427d5747e5949c0348dcecd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145509
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Unlike Word, ThisWorksheet cannot hold auto-running
subroutines for Open/Close/New.
This fixes a LO 7.4 regression caused by
commit beb6c62e99.
Change-Id: Idb8f72775d9392b306cb924ee776821272b12f3b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141127
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Note: this should NOT apply to Document_Open which normally
is a private subroutine and runs fine as private.
I tested and it DOES apply to all three version of AutoOpen:
-ThisDocument.AutoOpen,
-<AnyModule>.AutoOpen,
-AutoOpen.Main
Note: this is different from Excel.
Private Auto_Open runs just fine there.
Change-Id: If10c8c90c35275c2b14dc2e15fb357674fc580b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141114
Tested-by: Justin Luth <jluth@mail.com>
Reviewed-by: Justin Luth <jluth@mail.com>
Which means we can get rid of the majestic hack of ScCaptionPtr
Previously, SdrObject was manually managed, and the ownership
passed around in very complicated fashion.
Notes:
(*) SvxShape has a strong reference to SdrObject, where
previously it had a weak reference. It is now strong
since otherwise the SdrObject will go away very eagerly.
(*) SdrObject still has a weak reference to SvxShape
(*) In the existing places that an SdrObject is being
deleted, we now just clear the reference
(*) instead of SwVirtFlyDrawObj removing itself from the
page that contains inside it's destructor, make the call site
do the removing from the page.
(*) Needed to take the SolarMutex in UndoManagerHelper_Impl::impl_clear
because this can be called from UNO (e.g. sfx2_complex JUnit test)
and the SdrObjects need the SolarMutex when destructing.
(*) handle a tricky situation with SwDrawVirtObj in the SwDrawModel
destructor because the existing code wants mpDrawObj in
SwAnchoredObject to be sometimes owning, sometimes not, which
results in a cycle with the new code.
Change-Id: I4d79df1660e386388e5d51030653755bca02a163
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138837
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Let them use types that know string lengths, don't require conversion,
and are convenient at call sites.
Also inline the maps initialization, instead of having separate arrays
and initialization loops.
Change-Id: Id4469f3f99f3f0eb2cd83f0671cf892df4e420a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131550
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Andrea Gelmini