Not sure if MSVC would accept also the simpler thing, but anyway, the
dynamic_cast works for it, too.
Change-Id: I2dfa1e70b75bc17d38b5e95be0a0f1dd66767bf1
The services already existed, they just needed IDL files.
API CHANGE:
The return type of XUIConfigurationManager#getShortcutManager()
is now XAcceleratorConfiguration instead of XInterface.
This should not be a problem because XUIConfigurationManager is
unpublished and the client code was relying on the service
returning that type.
Change-Id: I399fe35de3394b02a4166b75eb7ff93b28be8bef
ExtCfRuleContext::onStartElement processing depends on some data now buffered
until CondFormatBuffer::finalizeImport runs. We now need to wait for this
data to be available. This change buffers up the processing that used happen
in ExtCfRuleContext startElement so it is now done as part of
CondFormatBuffer::finalizeImport
Change-Id: Ifbfe12740e6c4bc9791183dba89acb79cbbb6ef6
This change reorganizes the styles by column ( and by row ranges in that column )
so we can apply ScAttrEntry entries directly via Document.SetAttrEntries(...) this is
what the binary filter does also.
Change-Id: I7c1398c1d900e0a2b6c6ec3746b982ef60e653a0
...instead of returning a null XHierarchicalNameAccess. Otherwise, UCB's
globalTransfer from a vnd.sun.star.package URL that denotes a file that is not a
zip file to a file URL folder (i.e., to extract the zip content) silently
succeeds but just creates an empty file in the target folder. That, in turn,
causes "unopkg add foo.oxt", where foo.oxt is a file that is not a zip file, to
silently succeed and add an "empty" extension.
This change is somewhat bold in that it changes createPackage from "can return
empty reference" to "never returns empty reference, but can throw
RuntimeException." Especially, it considers "empty name" as a (silent)
violation of its contract with its caller now. I hope this does not affect any
legitimate scenarios---at least, it does not break a "make check" here. (In
turn, the two package_ucp::Content::getPackage overloads change to never return
a null reference, either. And I changed the parameters of createPackage, seeing
that all call-sites pass in some PackageUri's getPackage()/getParam() pair.)
Change-Id: I0eab5f8059dfedefc7030da38da528ba21ea8d79
with x86 gcc-4.1.2-54.el5 the sd import test fails while
x86-64 passes. Tracked it down eventually to this double
equality test failing on x86. Apparently excess precision
in registers compared with memory.
Change-Id: I61b43b2f0e9c9aded570448a1c5a7c9dbad8986e
I think we can distill this down to a "if the source or target
is a symbol font check for a recode table"
Change-Id: I6c674f10d9f1ab7fbe7274abfafb9082bae88218
When loading from odt, table cells which are covered (due to merging of
cells) are replaced with an empty cell by
SwXMLTableContext::ReplaceWithEmptyCell. However if there is a sequence
of cells covered from above then their replacements are accidentally
inserted in reverse order, which produces this infinite loop problem when
saving as doc.
The reverse ordering in SwXMLTableContext::ReplaceWithEmptyCell was because
the insert position came from SwXMLTableContext::GetPrevStartNode which was
very careful to skip previous covered cells. However those cells have
already been replaced with an empty cell so they should not be skipped.
Change-Id: I6a022cd1490afa181dbc3e4b2d6ed4af3077b363
Reviewed-on: https://gerrit.libreoffice.org/4008
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
ImplDevFontList::ImplFindByFont() will nearly always return a font, so
we do not go through the code path which sets up conversion.
Change-Id: Ice361f183c9f42aa562d4caab1d589417ad3fc9a
Reviewed-on: https://gerrit.libreoffice.org/4037
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
else clang/libc++ cannot decide between bool and a reference into a bit-vector
specialization
(cherry picked from commit 6a88a21257124d953637c4b8ead9c9771e15b899)
Change-Id: I694bbad82b1a05ebe86c5c941f3ac85c71f5fc9e
* sw/source/filter/ww8/ww8par5.cxx
MS Word Binary compatibility
Patch by: Jane Kang,<kangjane2012@gmail.com>
Found by: Yan Ji,<yanji.yj@gmail.com>
Review by: Jian Hong Cheng,<chengjh@apache.org>
(cherry picked from commit 720fc77527377968a45631d1c6a711b4cae02d39)
Change-Id: I428fadd46bbd5b57081e35dcbfd6bb0c10c08282