5687eba49f
...which were used by ildc, which is gone since
a8485d558f "[API CHANGE] Remove deprecated idlc
and regmerge from the SDK", and have always been ignored as legacy by its
unoidl-write replacement.
This change has been carried out (making use of GNU sed extensions) with
> for i in $(git ls-files \*.idl); do sed -i -z -E -e 's/\n\n((#[^\n]*\n)+\n)*(#[^\n]*\n)+\n?/\n\n/g' -e 's/\n(#[^\n]*\n)+/\n/g' "$i"; done && git checkout extensions/source/activex/so_activex.idl odk/examples/OLE/activex/so_activex.idl
which apparently happened to do the work. (The final two files are not UNOIDL
source files.)
Change-Id: Ic9369e05d46e8f7e8a304ab01740b171b92335cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135683
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
97 lines
4.7 KiB
Text
97 lines
4.7 KiB
Text
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
|
|
/*
|
|
* This file is part of the LibreOffice project.
|
|
*
|
|
* This Source Code Form is subject to the terms of the Mozilla Public
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
*
|
|
* This file incorporates work covered by the following license notice:
|
|
*
|
|
* Licensed to the Apache Software Foundation (ASF) under one or more
|
|
* contributor license agreements. See the NOTICE file distributed
|
|
* with this work for additional information regarding copyright
|
|
* ownership. The ASF licenses this file to you under the Apache
|
|
* License, Version 2.0 (the "License"); you may not use this file
|
|
* except in compliance with the License. You may obtain a copy of
|
|
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
|
|
*/
|
|
|
|
|
|
module com { module sun { module star { module ucb {
|
|
|
|
/** manages one or more complete sets of hierarchy data and serves as a factory
|
|
for objects that provide access to a subset of the data.
|
|
|
|
<p><b>Note:</b> This is an abstract service. This means, that there should
|
|
never be implementations that can be instantiated using the service name
|
|
<code>com.sun.star.ucb.HierarchyDataSource</code>. Each implementation must
|
|
provide its own service name that can be used to create instances of that
|
|
service implementation. Important for those service specifications is also
|
|
to specify which of the optional parts are supported by the implementation.
|
|
*/
|
|
published service HierarchyDataSource
|
|
{
|
|
/** allows creating access objects for specific views such as subsets and
|
|
fragments of the hierarchy data.
|
|
|
|
<p>The parameter <var>aServiceSpecifier</var> passed to
|
|
com::sun::star::lang::XMultiServiceFactory::createInstanceWithArguments()
|
|
supports at least the service specifier
|
|
<code>"com.sun.star.ucb.HierarchyDataReadAccess"</code>, which will
|
|
create a <b>read-only view</b> to the data. The object that is created
|
|
implements the service HierarchyDataReadAccess.
|
|
|
|
<p><b>Optionally</b> the factory may support <b>writable views</b>. A
|
|
writable view is requested by passing the service specifier
|
|
<code>"com.sun.star.ucb.HierarchyDataReadWriteAccess"</code> to
|
|
com::sun::star::lang::XMultiServiceFactory::createInstanceWithArguments()
|
|
The object that is created implements the service
|
|
HierarchyDataReadWriteAccess.
|
|
|
|
<p>The arguments passed to
|
|
com::sun::star::lang::XMultiServiceFactory::createInstanceWithArguments()
|
|
in parameter <var>aArguments</var> specify the view of the data that
|
|
should be created. That is, they determine the subset of elements that
|
|
can be accessed starting from the returned object. Each element of the
|
|
argument sequence should be a
|
|
com::sun::star::beans::PropertyValue, so that the
|
|
parameters can be identified by name rather than by position.
|
|
|
|
<p>With both of the standard service specifiers above, an implementation
|
|
must accept a property named <code>nodepath</code> of type
|
|
`string`. This property must contain the absolute path to an
|
|
element of the data. The view that is selected consists of the named
|
|
element and all its descendants. A path consists of segments that are
|
|
separated by a single slash ("/"). There is neither a leading nor a
|
|
trailing slash allowed. The <b>root</b> of the hierarchy data always
|
|
has an empty path. Refer to HierarchyDataReadAccess for
|
|
more information on hierarchical names.
|
|
|
|
<p>Other arguments can be used to control the behavior of the view.
|
|
These are different for different implementations. Whether and how they
|
|
are used may also depend on the configuration store and configuration
|
|
that were selected when the provider was created.
|
|
|
|
<p>An implementation must ignore unknown arguments.
|
|
|
|
<p>The implementation of
|
|
com::sun::star::lang::XMultiServiceFactory::createInstance()
|
|
must behave exactly as if
|
|
com::sun::star::lang::XMultiServiceFactory::createInstanceWithArguments()
|
|
were called passing one single property named <code>nodepath</code>
|
|
where the property value is an empty string. Thus it always creates a
|
|
view to the root of the hierarchy data.
|
|
*/
|
|
interface com::sun::star::lang::XMultiServiceFactory;
|
|
|
|
/** allows controlling or observing the lifetime of the hierarchy data
|
|
source and its views.
|
|
*/
|
|
interface com::sun::star::lang::XComponent;
|
|
};
|
|
|
|
|
|
}; }; }; };
|
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|