Instead of making all chart objects exempt from unloading, check each OLE
object on whether or not it already has its persistent storage created.
If not, don't unload it else it would have nothing to load back from once
unloaded.
Change-Id: I2312e86c9376d3699ef4aa1e0cf2f4c04f706c1e
This approach looks much better. We get size and position correct
without much work and can easily plug the window into the sc window
hierarchy.
We still have a crash on exit as the ScGridWindow goes out of scope and
the SystemChildWindow is still alive. We need to fix it and bind the
lifecycle of the SystemChildWindow to ScGridWindow.
Another open item is the OpenGL context work. Right now it looks like
the best way forward is to create a subclass of SystemChildWindow that
contains the OpenGLContext.
Change-Id: Ie0a74531e1b818cea92912345464c8fa219bbae2
To replace single-instance com.sun.star.util.PathSettings service,
incorrectly converted in 89b0017b22889af6a8afe28b94c06e7095dc8c6f
Keeping util::PathSettings::create in
sc/source/ui/vba/vbaapplication.cxx because for some reason
util::thePathSettings::get does not work in sc_macros_test
while testing sc/qa/extras/testdocuments/Ranges.xls.
Change-Id: I75b68ae56ac5b58f72416070dba100ab3ab70fe8
com.sun.star.frame.thePopupMenuControllerFactory
com.sun.star.frame.theStatusbarControllerFactory
com.sun.star.frame.theToolbarControllerFactory
To replace their single-instance service variants.
Change-Id: I00586d0d61e63f9482cb659071e88aa9cf02d5b5
To replace com.sun.star.frame.AutoRecovery single-instance service,
incorrectly converted in 279859fdbc40f68d8f1649fa5b928d9de49e8d9e
Unfortunately needs a lot of changes in autorecovery.cxx.
Change-Id: Iba5188dffea3e03803236f23e0b3f343746ace90
To replace com.sun.star.task.JobExecutor single-instance service,
incorrectly converted in 748aa84e9808ad31c6ff6b71459525c82de10e58
[including changes by Stephan Bergmann <sbergman@redhat.com>]
Change-Id: I4cea2c63a20b5b22f6e1f822fb35fcc4d0397687
Reviewed-on: https://gerrit.libreoffice.org/7609
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
This will make the border and fill shape to be drawn first, then everything
else drawn on top.
This commit may look large, but it's actually a very trivial change. The
important part is in SvxShapeGroup where new methods have been added to allow
different insertion positions for the new shapes being inserted, and have
the chart2 code make use of it to insert the fill rectangle to the bottom
rather than to the top.
Change-Id: I999160daf6fc9ce3d7e641f57b1998543df1cc4e
and there's a strange stray ifdef in MSAAService.idl
add mode-lines and remove unnecessary headerguard etc
Change-Id: I072960ac073b2c33d7d820e7dbfe02145685d3f3
- gb_UnoApi_get_target returns the files in INSTDIR
- stop using rdb files from OUTDIR
- remove gb_UnoApi_install
- remove pointless 2nd parameter of gb_UnoApi_UnoApi
- order-only dependency from gb_UnoApi_get_target to
gb_UnoApiHeadersTarget_get_target because INSTDIR .rdb is always outdated
Change-Id: Id418f75e9b38d6fe135b55eca2594c2624bc41cc
Had been totaly broken by the recent changes. (Which is fine, it is
just an experimental hack anyway, I am not sure whether it will ever
be used in anger. Just a pet peeve of mine, I dislike seeing
libraries, configuration files, resources etc mixed together in one
"program" folder, especially on OS X, where the convention is to have
app-specific dylibs and frameworks in "Frameworks", and resource files
in "Resources". But this is not any requirement as such; there are
apps in the Mac App Store that blatantly "break" this convention.)
Basically, replace uses of gb_PROGRAMDIRNAME and
gb_Package_PROGRAMDIRNAME with more specific LIBO_FOO_FOLDER, which
for normal builds all expand to the same "program" anyway.
Change-Id: I16c2b3351caa00e251e229aafbccb8346042d3c1
...via unoidl-write and the new source-format registry provicers, instead of
using idlc to produce .urd files, regmerge to merge them into legacy .rdb files,
and unoidl-write to translate those to new UNOIDL .rdb files.
gb_UnoApi and gb_InternalUnoApi ctors take an additional argument now that is
the path (below $(SRCDIR)) of the source-format registry from which to obtain
UNOIDL entity definitions. It can either be an .idl file (in which case no
*_add_idlfiles calls should be used and the resulting .rdb will contain all the
entities from that one .idl file; used in some tests to conveniently define all
test-specific entities in a single file) or a directory denoting the root of an
.idl file tree (in which case *_add_idlfiles calls specify the entites to
include in the resulting .idl file). (In the first case, the generated .rdb
file needs to depend on that single .idl file, so the gb_UnoApiTarget ctor
contains a dependency on that additional argument, which happens, as a side
effect, to trigger rebuilds in the second, tree-based case when addition/removal
of .idl files in the tree causes updates of directory time-stamps.)
UnoApiPartTarget and all the dependency-tracking logic based on .urd files in
solenv/gbuild/UnoApiTarget.mk is gone. Generation of an .rdb file now depends
on its source registry (see previous paragraph) and all the .idl files specified
with *_add_idlfiles (in the second, tree-based case above).
A consequence of that is that gb_UnoApi_add_idlfile, -_nohdl, and -_noheader all
do the same now. I left them in for now anyway, maybe they become relevant
again when the use of cppumaker is changed to read directly from a source-format
registry instead of going via a .rdb registry.
The legacy tools idlc, regcompare, regmerge, and regview are still contained in
the URE or SDK for now.
cb344cd59e1ddb7c6db66dbd9263b4755969d4ba "Revert 'Looks like idlc resolved
typedefs inside sequence<...>'" is re-reverted as now "the current offapi.rdb is
generated via unoidl-write instead of idlc."
Change-Id: I3d9d92f17326bc9f49dd934c85aab6a17951d06d
...obtained from the old .rdb files via "unoidl-read --published". This removes
the need for update-rdb.sh.
Change-Id: I73c0d026af7e27370602f83c61dfa76fc4d17a83
...for checking compatibility with the reference rdbs. unoidl-check is no
longer based on the legacy registry format, but can process all the various new
UNOIDL registry formats. regcompare is still included in the SDK for now.
(gb_UnoApi[Target]_set_reference_rdbfile now takes a non-empty sequence of rdb
files, any necessary dependencies of the final rdf file preceding it just like
it is required on the unoidl-check command line. Also, executing the
unoidl-check now properly depends on those rdb files.)
TODO: unoidl-check is too conservative for now and flags some changes as
incompatible that are not.
Change-Id: I92e4c69403c5e3fcb31707c98c65a2f509592dd4
...it had been deprecated at least since late OOo times, with the
css.sheet.NamedRangeFlag constant group as replacement. (UNOIDL identifiers
starting with an underscore are illegal. It would be good to be able to enforce
that in code parsing UNOIDL files, but some existing identifiers like this one
violate that.)
Change-Id: Ib8067dee47cec46356065b7b70cc6b47b97e5bc0
...doxygen still picks them up, as it traverses the complete udkapi/ and offapi/
soruce trees. (And rename udk-modules.idl to modules.idl for consistency.)
Change-Id: Ic52c333756810c285059f03edc207a0913ead160
(cherry picked from commit 122e10cfd23b379b97e2d8ec002e7f0562ebd6f7)
Conflicts:
extensions/source/update/feed/updatefeed.cxx
offapi/com/sun/star/ucb/makefile.mk
offapi/type_reference/typelibrary_history.txt
offapi/type_reference/types.rdb
ucb/source/ucp/webdav/DAVResourceAccess.cxx
ucb/source/ucp/webdav/DAVResourceAccess.hxx
plus headerize.pl
(Would be an incompatible API CHANGE if we had not unpublished
XWebDAVCommandEnvironment with 78cca63070ae6cf82b45ec3bc75fafa2db31a7f2 "Revert
publishing of lots of UNO types.")
Change-Id: I153e394a194d0fcad29d3e3b27d5b24f7c259fc4
Revert "fdo#46808, Convert frame::FrameControl service to new style"
This reverts commit 32eaa77db33b3b1f5793e92167b9f8c2708ea543.
Conflicts:
UnoControls/source/controls/framecontrol.cxx
UnoControls/source/inc/framecontrol.hxx
.. because I can't work out how it causes fdo#67213 - I suspect my
changes might be interacting with UNO aggregation, which
is always tricky.
Change-Id: Icd14f9a7df98585393c5527a3817e05c26246de9
Add IsUTC member to:
com.sun.star.util.DateTime
com.sun.star.util.DateTimeRange
com.sun.star.util.Time
Add new stucts with explicit time zones:
com.sun.star.util.DateTimeWithTimezone
com.sun.star.util.DateWithTimezone
com.sun.star.util.TimeWithTimezone
Adapt the sax::Converter to read/write timezones, and fix the unit test.
Everything else just uses default (no time zone), this commit is just
to fix the API.
STRUCT: /UCR/com/sun/star/util/DateTime
nFields1 = 7 != nFields2 = 8
Registry2 contains 1 more fields
STRUCT: /UCR/com/sun/star/util/DateTimeRange
nFields1 = 14 != nFields2 = 15
Registry2 contains 1 more fields
STRUCT: /UCR/com/sun/star/util/Time
nFields1 = 4 != nFields2 = 5
Registry2 contains 1 more fields
Conflicts:
sc/source/filter/oox/unitconverter.cxx
Change-Id: I01f7a6d082a6b090c8efe71d2de137474c495c18
Reviewed-on: https://gerrit.libreoffice.org/4833
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
This reverts commit fcd01fba69db6de6cfc983fae65b6ba6764de0d6.
Service DefaultTreeDataModel actually doens't exist ( and we can't find
when/where it used to :-( ) The treecontrolpeer.cxx change to
use the new service also had the undesired effect of throwing an exception
when the UnoTreeControl model is inserted ( previously this failed silently )
The net effect is the dialog control is malformed and not initialised
correctly
This bug fixes the DOCX import and export filters, adds a new property
to the document model and updates the UNO API.
There is no need to add layout \ UI updates, because in Word
the only way to turn this on\off is using a simple button,
and there is no way to control the shading color itself.
However, ODF import \ export filters should be updated in a future
commit.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Change-Id: I1d34cec79289e38c08e42a4c6265d998e1edfdef
Reviewed-on: https://gerrit.libreoffice.org/4452
Reviewed-by: Miklos Vajna <vmiklos@suse.cz>
