Exported Interfaces |
::com::sun::star::container::XContainerQuery |
- Description
- provides search on flat filter configuration
After a TypeDetection an internal name of a type which presents
the requested document will be well known. With this interface it's possible
to find out which filter(s) are registered for that. It's possible to use
implementation dependend query commands (strings) or sets of properties which
must supported by searched filter(s). Returned enumerations contains a reference
to sub sets of filter(s) (means to her flat data structures represented as
::com::sun::star::beans::NamedValue [] ) which can be used
for further steps then; e.g, to create the filter(s).
(see list of properties below on XNameAccess )
Same functionality (for searching) will be provided by the follow interface
XNameAccess - but that willn't be very comfortable
to do so.
|
::com::sun::star::container::XNameAccess |
- Description
- provides simple access on flat filter configuration
ExportFilter / ImportFilter ) is specified by
some properties wich are represented as ::com::sun::star::beans::NamedValue [] .
This interface provides pure access (read/write) on these data.
A name for the calling methods must the internal filter name be used only.
Returned any capsulate the flat property lists then. May this interface will be neccessary
to extend missing funtionality of XContainerQuery or for
changing the configuration (if implementation of this service allow that! may they will be readonly).
Query interface before provides readonly access only.
Follow properties are supported by a filter:
property name |
value type |
description |
Type |
[string] |
filter is registered for this internal type name
(see TypeDetection for further informations) |
UIName |
[string] |
localized name of filter to show at the UI |
DocumentService |
[string] |
service name which presents the document type
(e.g. ::com::sun::star::text::TextDocument ) |
FilterService |
[string] |
service name of filter implementation
Note: It means the implementation name of the service realy.
Because it's not possible to distinguish between
more then one filters otherwise. |
Flags |
[integer] |
describe the filter more specific
(e.g. for import/export or as default) |
UserData |
[string] |
contains filter specific configuration formated as string
for historical reasons |
FileFormatVersion |
[integer] |
specifies supported format version if there exist more then ones |
TemplateName |
[string] |
name of suitable template |
|
::com::sun::star::lang::XMultiServiceFactory |
- Description
- factory to create filter objects
After using the interfaces before an internal
filter name should be well known. It can be used at this interface to create
the real filter object for using. Furthrr it's possible to use optional arguments
for initializing too.
If created filter supports the interface ::com::sun::star::lang::XInitialization ,
the factory will pass his own configuration data and the optional
arguments to it. (see ExportFilter::XInitialization or
ImportFilter::XInitialization for further informations)
If this interface is not support, nothing will be done. The filter will be returned
uninitialized and must get his configuration by itself.
Additional it should support the interface ::com::sun::star::container::XNamed
to provide his own internal name. Any owner of it can use this name
to get more information about the filter by calling the FilterFactory service.
|
Copyright © 2002 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA.