...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
.. to Reference<XComponentContext>
mostly in the dbaccess module, but it also affected some other
modules.
Change-Id: I09b3f6fe7a9b33498b11d98b5521b5aeeb8882be
I have cleared out String and ::rtl::OUString calls in module dbaccess/source/core/misc.
It was mainly file dbaccess/source/core/misc/dnstypes.cxx , and it's usages. There are
still some calls in dbaccess for this class(ODnsTypeCollection), that needs refactoring
(eg. in file DbAdminImpl.cxx, method "String ODbDataSourceAdministrationHelper::getConnectionURL() const").
Remaining calls will be my next task (in module dbaccess). I also clear out deprecated macro
RTL_CONSTASCII_USTRINGPARAM every time I find one. The class I've mentioned above
(ODnsTypeCollector) is OK.
Change-Id: Ia0f3bb8cc649d1ecf8decc093f8a1a20ee23c33c
Reviewed-on: https://gerrit.libreoffice.org/2289
Reviewed-by: Andras Timar <atimar@suse.com>
Tested-by: Andras Timar <atimar@suse.com>
I had to drop XEventBroadcaster from the merged interface
because it introduced method name conflicts (addEventListener).
Shouldn't be an issue since it was scheduled to be dropped anyhow,
and the service implementation still implements it, so existing clients
will be fine.
I dropped the interface XPropertySet from the combined IDL because nobody
seems to be using it, and it's primary purpose appears to be to set weird
flags.
I dropped the optional interfaces
XStatusIndicatorFactory
XDispatchInformationProvider
from the combined IDL because the service does not implement them, and
nobody seems to be using them. I suspect they were mistakenly copied
from XFrame.
I also did not convert the Title, UserDefinedAttributes and LayoutManager
properties to attributes, again because no-one is using them.
Change-Id: I678a00006ed2cca2d6c37c4e39465811442c33af
* UUIInteractionHandler still needs to implement XInitialization.
* Moved ambiguating InteractionHandler typedef out of the way.
* Removed InteractionHandler.createDefault, as it was originally stated that "it
is strongly recommended that [the "Parent"] property is supplied."
* Added back documentation about Parent and Context.
* Simplified some call-sites to directly use XInteractionHandler2.
Change-Id: I1029b8f3cf079171c75920cafaaa44b5bbada883
Since we don't need to expose XInitialisation, we can make the new-style
service implement XInteractionHandler2.
Change-Id: Ib27beed1c12df17592c6472d6f58c233d2c41558
* As UCB is only ever initialized with "Local"/"Office", remove this
configuration vector completely. The "create" ctor creates an instance
internally initialized with those "Local"/"Office" keys. Special (test) code
can still instantiate an uninitialized one via plain createInstance. And for
backwards compatilibity process startup still ensures to create an initialized
instance early, in case there is still code out there (in extensions) that
later calls plain createInstance and expects to get the already-initialized
(single) instance.
* XInitialization is an "implementation detail" of the UniversalContentBroker
service, do not expose in XUniversalContentBroker.
* ucbhelper/configurationkeys.hxx is no longer needed and is removed.
* ucbhelper/contentbroker.hxx is an empty wrapper and is removed; however, that
requires ucbhelper::Content constructors to take explicit XComponentContext
arguments now.
* The only remaining code in ucbhelper/source/client/contentbroker.cxx is
Android-only InitUCBHelper. Is that relevant still?
Change-Id: I3f7bddd0456bffbcd13590c66d9011915c760f28
The generic css.task.InteractionHandler implementation in module uui is now able to instantiate "sub handlers", i.e.
components to delegate a request to, based on the type of the request, and some configuration data.
The "old" (and now deprecated) configuration scheme at org.openoffice.ucb.InteractionHandler did not contain type
information, so any handlers registered there were always called when no default implementation for a given request
was available.
The "new" configuration scheme at org.openoffice.Interaction contains UNO type information. That is, a given handler
implementation can declare itself responsible for an arbitrary set of UNO types, and for each of those types, whether
it is also responsible for sub types.
The generic interaction handler implementation uses this configuration data, when it encounteres an interaction
request it cannot fullfill itself, to instantiate a component to delegate the request to.
As with the "old" data, such a component is required to support the css.task.XInteractionHandler2 interface. Also,
if it supports css.lang.XInitialization, then it will be initialized with a name-value pair, the name being
"Parent", the value being the XWindow interface of the parent window for any message boxes.
As an examplary implementation for this feature, the css.sdb.InteractionHandler has been deprecated. Now the
css.sdb.DatabaseInteractionHandler is reponsible for database-related interactions, and the new configuration scheme
is pre-filled with data assigning this responsibility.
Consequently, a lot of places previously creating an css.sdb.InteractionHandler have been modified to create the
default css.task.InteractionHandler.
