Converted them as usual service implementations.
Otherwise - if static singletons are used -
it does not show menu for some reason.
Change-Id: I0673d0bfbba268728a3fa676f2af95aa6c74bbb2
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
In commit 363cc397172f2b0a94d9c4dc44fc8d95072795a3
"convert equalsAsciiL calls to startWith calls where possible"
I incorrectly converted equalsAsciiL calls to startsWith calls.
This commit fixes those places to use the == OUString operator.
Change-Id: If76993baf73e3d8fb3bbcf6e8314e59fdc1207b6
A final pass through the code, converting code to use the new
OUString and OString methods that can detect string literals.
Change-Id: Ifa6382335e5650a1c67e52006b26354e0692c710
This is both an optimisation and a cleanup.
This converts code like
aStr.indexOf("XX") == 0
to
aStr.startsWith("XX")
and converts code like
aStr.lastIndexOf("XXX") == aStr.getLength() - 3
to
aStr.endsWith("XXX")
Note that in general
aStr.lastIndexOf("X") == aStr.getLength() - 1
converts to
aStr.isEmpty() || aStr.endsWith("X")
so I used the surrounding context to determine if aStr could be empty
when modifying the code.
Change-Id: I22cb8ca7c2a4d0288b001f72adb27fd63af87669
- "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
Required creating a new merged interface.
The service interface is going to be shared by some other services,
which is why it's name is != the service name.
Change-Id: I9af3c27b367807147a0052fb6fa4e42eb1ad32de
...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
Create a merged XToolkit2 interface for this service to implement.
Which is backwards-compatible, but does not require creating a new service.
Also mark sub-interfaces as non-optional.
Change-Id: I278d0288e92be277033013302267cf93f7d70480
avoid where possible (by checking beforehand), and assert when caught
Conflicts:
framework/source/fwe/classes/framelistanalyzer.cxx
framework/source/helper/titlebarupdate.cxx
framework/source/services/frame.cxx
framework/source/uifactory/windowcontentfactorymanager.cxx
sfx2/source/notify/eventsupplier.cxx
