This is much better approach compared to the callback function, as it allows
passing arguments to the c++ constructor directly, while still allowing some
additional initialization after having acquired the instance.
Change-Id: I5a0f981915dd58f1522ee6054e53a3550b29d624
Many of the initalizations (in eg. framework) have to be done on an
acquire()'d object, so instead of doing the initialization directly, return
the initialization member function back to the createInstance() /
createInstanceWithContext() / ... and perform the initialization there.
As a sideeffect, I belive the calling initialize() from servicemanager is not
that much a hack any more - whoever converts the implementation to be
constructor-base has the choice to provide the callback, or still initialize
through XInitialization, where the callback is preferred by servicemanager
when it exists.
Change-Id: I8a87b75c54c1441ca0f184967d31ff4902fc4081
Convert code like:
aOStringBuf.append( RTL_CONSTASCII_STRINGPARAM( " is missing )") );
to:
aOStringBuf.append( " is missing )" );
which compiles down to the same code.
Change-Id: I3d8ed0cbf96a881686524a167412d5f303c06b71
This internal API has always been problematic because we cannot
support it under the Linux toolkits, where it has in fact always
just returned the size of the screen.
Change-Id: I406bcbca8a4161b4261ef46940823bb07c6ad18b
Reviewed-on: https://gerrit.libreoffice.org/4976
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@suse.com>
Tested-by: Michael Meeks <michael.meeks@suse.com>
- "ModuleName" --> "ModuleIdentifier": the IDL definition for
css::frame::PopupMenuControllerFactory and
css::frame::StatusbarControllerFactory tells to use a property named
"ModuleIdentifier", but in the code it is named "ModuleName"
- Undocumented css::frame::ToolbarControllerFactory
- Fix service name of ToolbarControllerFactory (ToolbarControllerFactory
instead of ToolBarControllerFactory)
- Convert the three service factories to new style, and use these
new-style services in the source code
- Implement multiple inheritance: added new css::frame::XUIControllerFactory
- Added a (true) base class and implemented the three factories in a
single file
(cherry picked from commit acc7fed28f54f836b0923180431a0c180f91e98c)
Conflicts:
framework/inc/pch/precompiled_framework.hxx
framework/inc/uielement/toolbarmanager.hxx
framework/inc/uifactory/popupmenucontrollerfactory.hxx
framework/inc/uifactory/statusbarcontrollerfactory.hxx
framework/inc/uifactory/uicontrollerfactory.hxx
framework/source/uielement/addonstoolbarmanager.cxx
framework/source/uielement/menubarmanager.cxx
framework/source/uielement/popupmenucontroller.cxx
framework/source/uielement/statusbarmanager.cxx
framework/source/uielement/toolbarmanager.cxx
framework/source/uifactory/popupmenucontrollerfactory.cxx
framework/source/uifactory/statusbarcontrollerfactory.cxx
framework/source/uifactory/uicontrollerfactory.cxx
framework/source/unotypes/fwk.xml
offapi/com/sun/star/frame/PopupMenuControllerFactory.idl
offapi/com/sun/star/frame/StatusbarControllerFactory.idl
offapi/com/sun/star/frame/makefile.mk
svtools/source/uno/toolboxcontroller.cxx
Change-Id: Ia8580539badf650a84bc6e57a6b832071e011f0a
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
The LayoutManager for some reason has both a ToolbarLayoutManager
pointer field, and a uno::Reference to an aspect (or whatever term one
should use) of the same ToolbarLayoutManager. (I.e. esssentially two
fields for the same thing. Why it doesn't create such variables where
needed instead I don't know.)
Anyway, for some reason there were lots of instances where a local
variable was initialised with this second field but then never used. I
removed those. (Surely just copying the field into a local variable
doesn't have any interesting side effect that would explain this
pattern?)
Change-Id: Ibdfbd9476c39d3e83b58e81469b94d9a87444ca8
This service was never documented in an IDL file.
All it did was provide a wrapper around some VCL module API.
Now that we can link the VCL stuff into SD and SDEXT, just
access the API directly.
Change-Id: Ic0ba34c2bca797baa7319878d98cfe3a4ec59d4d
...in favor of existing new-style configuration::theDefaultProvider singleton.
Theoretically, ConfigurationProvider instances can be created with specific
Locale and EnableAsync arguments, but this is hardly used in practice, and thus
effectively all uses of the ConfigurationProvider service use the
theDefaultProvider instance, anyway.
theDefaultProvider is restricted to the XMultiServiceFactory interface, while
ConfigurationProvider also makes available XComponent. However, dispose must
not be called manually on theDefaultProvider singleton anyway, and calls to
add-/removeEventListener are so few (and in dubious code that should better be
cleaned up) that requiring an explicit queryInterface does not really hurt
there.
This commit originated as a patch by Noel Grandin to "Adapt
configuration::ConfigurationProvider UNO service to new style [by creating] a
merged XConfigurationProvider interface for this service to implement." It was
then modified by Stephan Bergmann by deprecating ConfigurationProvider instead
of adding XConfigurationProvider and by replacing calls to
ConfigurationProvider::create with calls to theDefaultProvider::get.
Change-Id: I9c16700afe0faff1ef6f20338a66bd7a9af990bd
