/*************************************************************************
*
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* Copyright 2000, 2010 Oracle and/or its affiliates.
*
* OpenOffice.org - a multi-platform office productivity suite
*
* This file is part of OpenOffice.org.
*
* OpenOffice.org is free software: you can redistribute it and/or modify
* it under the terms of the GNU Lesser General Public License version 3
* only, as published by the Free Software Foundation.
*
* OpenOffice.org is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Lesser General Public License version 3 for more details
* (a copy is included in the LICENSE file that accompanied this code).
*
* You should have received a copy of the GNU Lesser General Public License
* version 3 along with OpenOffice.org. If not, see
* The interaction handler service has a numerof of built-in handlers, responsible
for a lot of well known interactions. Additionally, there's a configuration module which allows to
configure additional handlers, responsible for arbitrary requests.Built-in Handlers
The following well-known requests can be dealt with by the built-in handlers:
The requests marked with an asterisk are only handled if (a) their
continuations match certain restrictions (see below), and (b) the
necessary resource strings are available (this can be exploited by
applications that carry only a subset of all resource files with
them).
The continuation restrictions are as follows: Let C be the
subset of the provided continuations that are of type
An
"Uri"
"ResourceName"
"ResourceType"
"volume"
(e.g., a file system volume) and
"folder"
(i.e., a resource that contains other
resources)."Removable"
"Folder"
"Volume"
and "OtherVolume"
It is possible to configure additional interaction handlers, to which certain requests can be delegated. The
configuration node /org.openoffice.Interaction/InteractionHandlers
is evaluated and respected
by the InteractionHandler
implementation.
A custom interaction handler can declare itself responsible for an arbitrary number of UNO types, specified by full-qualified type name. Also, for each type, it can specify whether it is responsible for only this particular type, or all possibly existent derived types.
Whenever the InteractionHandler
encounteres a request it cannot fulfill itself, it will examine
the configuration, to find a handler implementation for the request, and delegate it to the first matching
handler.
If multiple custom interaction handlers declare themself responsible for the same request type, it is not defined which handler will actully be invoked. Thus, when deploying a custom interaction handler, ensure that the types you specify are general enough to cover all requests you want to handle, but also specific enough to not cover requests which other handlers might be interested in.
*/ published service InteractionHandler { //------------------------------------------------------------------------ /** Handle an interaction request. */ interface com::sun::star::task::XInteractionHandler; //------------------------------------------------------------------------ /** Initialize the interaction handler.The arguments must be a sequence of
"Parent"
of type
"Context"
of type