2010-10-27 12:33:13 +01:00
|
|
|
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
|
2012-06-14 17:39:53 +01:00
|
|
|
/*
|
|
|
|
* 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 .
|
|
|
|
*/
|
2000-10-25 12:00:01 +00:00
|
|
|
|
|
|
|
#ifndef _DBAUI_INTERACTION_HXX_
|
|
|
|
#define _DBAUI_INTERACTION_HXX_
|
|
|
|
|
|
|
|
#include <cppuhelper/implbase2.hxx>
|
|
|
|
|
2007-07-06 07:45:13 +00:00
|
|
|
#include "moduledbu.hxx"
|
autorecovery: more sophisticated configuration data for interaction handlers
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.
2010-02-01 21:32:33 +01:00
|
|
|
#include "apitools.hxx"
|
|
|
|
|
2000-10-25 12:00:01 +00:00
|
|
|
#include <com/sun/star/lang/XServiceInfo.hpp>
|
autorecovery: more sophisticated configuration data for interaction handlers
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.
2010-02-01 21:32:33 +01:00
|
|
|
#include <com/sun/star/task/XInteractionHandler2.hpp>
|
2000-10-25 12:00:01 +00:00
|
|
|
#include <com/sun/star/lang/XMultiServiceFactory.hpp>
|
|
|
|
#include <com/sun/star/ucb/AuthenticationRequest.hpp>
|
2000-10-26 17:08:16 +00:00
|
|
|
#include <com/sun/star/sdb/ParametersRequest.hpp>
|
2004-08-02 15:23:27 +00:00
|
|
|
#include <com/sun/star/sdb/DocumentSaveRequest.hpp>
|
2000-10-25 12:00:01 +00:00
|
|
|
|
|
|
|
namespace dbtools
|
|
|
|
{
|
|
|
|
class SQLExceptionInfo;
|
|
|
|
}
|
|
|
|
|
|
|
|
namespace dbaui
|
|
|
|
{
|
|
|
|
|
2013-08-17 23:43:14 +02:00
|
|
|
// BasicInteractionHandler
|
2000-10-25 12:00:01 +00:00
|
|
|
typedef ::cppu::WeakImplHelper2 < ::com::sun::star::lang::XServiceInfo
|
autorecovery: more sophisticated configuration data for interaction handlers
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.
2010-02-01 21:32:33 +01:00
|
|
|
, ::com::sun::star::task::XInteractionHandler2
|
|
|
|
> BasicInteractionHandler_Base;
|
2000-10-25 12:00:01 +00:00
|
|
|
/** implements an <type scope="com.sun.star.task">XInteractionHandler</type> for
|
|
|
|
database related interaction requests.
|
|
|
|
<p/>
|
|
|
|
Supported interaction requests by now (specified by an exception: The appropriate exception
|
|
|
|
has to be returned by the getRequest method of the object implementing the
|
|
|
|
<type scope="com.sun.star.task">XInteractionRequest</type> interface.
|
|
|
|
<ul>
|
|
|
|
<li><b><type scope="com.sun.star.sdbc">SQLException</type></b>: requests to display a
|
|
|
|
standard error dialog for the (maybe chained) exception given</li>
|
|
|
|
</ul>
|
|
|
|
*/
|
autorecovery: more sophisticated configuration data for interaction handlers
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.
2010-02-01 21:32:33 +01:00
|
|
|
class BasicInteractionHandler
|
|
|
|
:public BasicInteractionHandler_Base
|
2000-10-25 12:00:01 +00:00
|
|
|
{
|
autorecovery: more sophisticated configuration data for interaction handlers
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.
2010-02-01 21:32:33 +01:00
|
|
|
const OModuleClient m_aModuleClient;
|
2012-12-06 14:15:55 +02:00
|
|
|
const ::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext >
|
|
|
|
m_xContext;
|
autorecovery: more sophisticated configuration data for interaction handlers
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.
2010-02-01 21:32:33 +01:00
|
|
|
const bool m_bFallbackToGeneric;
|
|
|
|
|
2000-10-25 12:00:01 +00:00
|
|
|
public:
|
autorecovery: more sophisticated configuration data for interaction handlers
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.
2010-02-01 21:32:33 +01:00
|
|
|
BasicInteractionHandler(
|
2012-12-06 14:15:55 +02:00
|
|
|
const ::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext >& rxContext,
|
autorecovery: more sophisticated configuration data for interaction handlers
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.
2010-02-01 21:32:33 +01:00
|
|
|
const bool i_bFallbackToGeneric
|
|
|
|
);
|
2000-10-25 12:00:01 +00:00
|
|
|
|
2012-10-02 15:03:12 +02:00
|
|
|
// XInitialization
|
|
|
|
void SAL_CALL initialize( com::sun::star::uno::Sequence< com::sun::star::uno::Any > const & /*rArguments*/) throw (com::sun::star::uno::Exception) {}
|
|
|
|
|
autorecovery: more sophisticated configuration data for interaction handlers
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.
2010-02-01 21:32:33 +01:00
|
|
|
// XInteractionHandler2
|
|
|
|
virtual ::sal_Bool SAL_CALL handleInteractionRequest( const ::com::sun::star::uno::Reference< ::com::sun::star::task::XInteractionRequest >& Request ) throw (::com::sun::star::uno::RuntimeException);
|
2000-10-25 12:00:01 +00:00
|
|
|
|
autorecovery: more sophisticated configuration data for interaction handlers
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.
2010-02-01 21:32:33 +01:00
|
|
|
// XInteractionHandler
|
2000-10-25 12:00:01 +00:00
|
|
|
virtual void SAL_CALL handle( const ::com::sun::star::uno::Reference< ::com::sun::star::task::XInteractionRequest >& Request ) throw(::com::sun::star::uno::RuntimeException);
|
|
|
|
|
|
|
|
protected:
|
autorecovery: more sophisticated configuration data for interaction handlers
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.
2010-02-01 21:32:33 +01:00
|
|
|
sal_Bool
|
|
|
|
impl_handle_throw( const ::com::sun::star::uno::Reference< ::com::sun::star::task::XInteractionRequest >& i_Request );
|
|
|
|
|
2000-10-25 12:00:01 +00:00
|
|
|
/// handle SQLExceptions (and derived classes)
|
|
|
|
void implHandle(
|
|
|
|
const ::dbtools::SQLExceptionInfo& _rSqlInfo,
|
|
|
|
const ::com::sun::star::uno::Sequence< ::com::sun::star::uno::Reference< ::com::sun::star::task::XInteractionContinuation > >& _rContinuations);
|
|
|
|
|
2000-10-26 17:08:16 +00:00
|
|
|
/// handle parameter requests
|
|
|
|
void implHandle(
|
|
|
|
const ::com::sun::star::sdb::ParametersRequest& _rParamRequest,
|
|
|
|
const ::com::sun::star::uno::Sequence< ::com::sun::star::uno::Reference< ::com::sun::star::task::XInteractionContinuation > >& _rContinuations);
|
|
|
|
|
2004-08-02 15:23:27 +00:00
|
|
|
/// handle document save requests
|
|
|
|
void implHandle(
|
|
|
|
const ::com::sun::star::sdb::DocumentSaveRequest& _rParamRequest,
|
|
|
|
const ::com::sun::star::uno::Sequence< ::com::sun::star::uno::Reference< ::com::sun::star::task::XInteractionContinuation > >& _rContinuations);
|
|
|
|
|
2005-01-21 16:21:57 +00:00
|
|
|
/// handles requests which are not SDB-specific
|
|
|
|
bool implHandleUnknown(
|
|
|
|
const ::com::sun::star::uno::Reference< ::com::sun::star::task::XInteractionRequest >& _rxRequest );
|
|
|
|
|
2000-10-25 12:00:01 +00:00
|
|
|
/// known continuation types
|
|
|
|
enum Continuation
|
|
|
|
{
|
|
|
|
APPROVE,
|
|
|
|
DISAPPROVE,
|
|
|
|
RETRY,
|
|
|
|
ABORT,
|
2004-08-02 15:23:27 +00:00
|
|
|
SUPPLY_PARAMETERS,
|
|
|
|
SUPPLY_DOCUMENTSAVE
|
2000-10-25 12:00:01 +00:00
|
|
|
};
|
|
|
|
/** check if a given continuation sequence contains a given continuation type<p/>
|
2010-12-04 12:33:49 +09:00
|
|
|
@return the index within <arg>_rContinuations</arg> of the first occurrence of a continuation
|
2000-10-25 12:00:01 +00:00
|
|
|
of the requested type, -1 of no such continuation exists
|
|
|
|
*/
|
|
|
|
sal_Int32 getContinuation(
|
|
|
|
Continuation _eCont,
|
|
|
|
const ::com::sun::star::uno::Sequence< ::com::sun::star::uno::Reference< ::com::sun::star::task::XInteractionContinuation > >& _rContinuations);
|
|
|
|
};
|
|
|
|
|
2013-08-17 23:43:14 +02:00
|
|
|
// SQLExceptionInteractionHandler
|
autorecovery: more sophisticated configuration data for interaction handlers
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.
2010-02-01 21:32:33 +01:00
|
|
|
class SQLExceptionInteractionHandler : public BasicInteractionHandler
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
SQLExceptionInteractionHandler(
|
2012-12-06 14:15:55 +02:00
|
|
|
const ::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext >& rxContext
|
autorecovery: more sophisticated configuration data for interaction handlers
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.
2010-02-01 21:32:33 +01:00
|
|
|
)
|
2012-12-06 14:15:55 +02:00
|
|
|
:BasicInteractionHandler( rxContext, false )
|
autorecovery: more sophisticated configuration data for interaction handlers
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.
2010-02-01 21:32:33 +01:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
// XServiceInfo
|
|
|
|
DECLARE_SERVICE_INFO_STATIC();
|
|
|
|
};
|
|
|
|
|
2013-08-17 23:43:14 +02:00
|
|
|
// SQLExceptionInteractionHandler
|
autorecovery: more sophisticated configuration data for interaction handlers
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.
2010-02-01 21:32:33 +01:00
|
|
|
/** an implementation for the legacy css.sdb.InteractionHandler
|
|
|
|
|
|
|
|
css.sdb.InteractionHandler is deprecated, as it does not only handle database related interactions,
|
|
|
|
but also delegates all kind of unknown requests to a css.task.InteractionHandler.
|
|
|
|
|
|
|
|
In today's architecture, there's only one central css.task.InteractionHandler, which is to be used
|
|
|
|
for all requests. Depending on configuration information, it decides which handler implementation
|
|
|
|
to delegate a request to.
|
|
|
|
|
|
|
|
SQLExceptionInteractionHandler is the delegatee which handles only database related interactions.
|
|
|
|
LegacyInteractionHandler is the version which first checks for a database related interaction, and
|
|
|
|
forwards everything else to the css.task.InteractionHandler.
|
|
|
|
*/
|
|
|
|
class LegacyInteractionHandler : public BasicInteractionHandler
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
LegacyInteractionHandler(
|
2012-12-06 14:15:55 +02:00
|
|
|
const ::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext >& rxContext
|
autorecovery: more sophisticated configuration data for interaction handlers
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.
2010-02-01 21:32:33 +01:00
|
|
|
)
|
2012-12-06 14:15:55 +02:00
|
|
|
:BasicInteractionHandler( rxContext, true )
|
autorecovery: more sophisticated configuration data for interaction handlers
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.
2010-02-01 21:32:33 +01:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
// XServiceInfo
|
|
|
|
DECLARE_SERVICE_INFO_STATIC();
|
|
|
|
};
|
|
|
|
|
2000-10-25 12:00:01 +00:00
|
|
|
} // namespace dbaui
|
|
|
|
|
|
|
|
#endif // _DBAUI_INTERACTION_HXX_
|
|
|
|
|
2010-10-27 12:33:13 +01:00
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|