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
|
|
|
|
2013-11-05 02:18:53 +01:00
|
|
|
#ifndef INCLUDED_DBACCESS_SOURCE_UI_UNO_DBINTERACTION_HXX
|
|
|
|
#define INCLUDED_DBACCESS_SOURCE_UI_UNO_DBINTERACTION_HXX
|
2000-10-25 12:00:01 +00:00
|
|
|
|
2015-07-17 11:59:26 +09:00
|
|
|
#include <cppuhelper/implbase.hxx>
|
2000-10-25 12:00:01 +00:00
|
|
|
|
2017-10-23 22:42:52 +02:00
|
|
|
#include <apitools.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
|
|
|
|
2018-08-14 02:28:54 +03:00
|
|
|
#include <com/sun/star/awt/XWindow.hpp>
|
|
|
|
#include <com/sun/star/lang/XInitialization.hpp>
|
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
|
|
|
|
2013-12-17 16:15:48 +01:00
|
|
|
namespace com { namespace sun { namespace star { namespace uno {
|
|
|
|
class XComponentContext;
|
|
|
|
} } } }
|
|
|
|
|
2000-10-25 12:00:01 +00:00
|
|
|
namespace dbtools
|
|
|
|
{
|
|
|
|
class SQLExceptionInfo;
|
|
|
|
}
|
|
|
|
|
|
|
|
namespace dbaui
|
|
|
|
{
|
|
|
|
|
2013-08-17 23:43:14 +02:00
|
|
|
// BasicInteractionHandler
|
2015-08-03 09:14:58 +02:00
|
|
|
typedef ::cppu::WeakImplHelper< css::lang::XServiceInfo
|
2018-08-14 02:28:54 +03:00
|
|
|
, css::lang::XInitialization
|
2015-08-03 09:14:58 +02:00
|
|
|
, css::task::XInteractionHandler2
|
2015-07-17 11:59:26 +09:00
|
|
|
> 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
|
|
|
{
|
2018-08-14 02:28:54 +03:00
|
|
|
css::uno::Reference< css::awt::XWindow > m_xParentWindow;
|
2015-08-03 09:14:58 +02:00
|
|
|
const css::uno::Reference< css::uno::XComponentContext >
|
2012-12-06 14:15:55 +02:00
|
|
|
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(
|
2015-08-03 09:14:58 +02:00
|
|
|
const css::uno::Reference< css::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
|
|
|
|
2018-08-14 02:28:54 +03:00
|
|
|
// XInitialization
|
|
|
|
virtual void SAL_CALL initialize( const css::uno::Sequence< css::uno::Any >& rArgs ) override;
|
|
|
|
|
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
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual sal_Bool SAL_CALL handleInteractionRequest( const css::uno::Reference< css::task::XInteractionRequest >& Request ) override;
|
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
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual void SAL_CALL handle( const css::uno::Reference< css::task::XInteractionRequest >& Request ) override;
|
2000-10-25 12:00:01 +00:00
|
|
|
|
|
|
|
protected:
|
2014-04-17 11:16:55 +02:00
|
|
|
bool
|
2015-08-03 09:14:58 +02:00
|
|
|
impl_handle_throw( const css::uno::Reference< css::task::XInteractionRequest >& i_Request );
|
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
|
|
|
|
2000-10-25 12:00:01 +00:00
|
|
|
/// handle SQLExceptions (and derived classes)
|
2015-04-24 15:29:31 +02:00
|
|
|
static void implHandle(
|
2000-10-25 12:00:01 +00:00
|
|
|
const ::dbtools::SQLExceptionInfo& _rSqlInfo,
|
2015-08-03 09:14:58 +02:00
|
|
|
const css::uno::Sequence< css::uno::Reference< css::task::XInteractionContinuation > >& _rContinuations);
|
2000-10-25 12:00:01 +00:00
|
|
|
|
2000-10-26 17:08:16 +00:00
|
|
|
/// handle parameter requests
|
|
|
|
void implHandle(
|
2015-08-03 09:14:58 +02:00
|
|
|
const css::sdb::ParametersRequest& _rParamRequest,
|
|
|
|
const css::uno::Sequence< css::uno::Reference< css::task::XInteractionContinuation > >& _rContinuations);
|
2000-10-26 17:08:16 +00:00
|
|
|
|
2004-08-02 15:23:27 +00:00
|
|
|
/// handle document save requests
|
|
|
|
void implHandle(
|
2015-08-03 09:14:58 +02:00
|
|
|
const css::sdb::DocumentSaveRequest& _rParamRequest,
|
|
|
|
const css::uno::Sequence< css::uno::Reference< css::task::XInteractionContinuation > >& _rContinuations);
|
2004-08-02 15:23:27 +00:00
|
|
|
|
2005-01-21 16:21:57 +00:00
|
|
|
/// handles requests which are not SDB-specific
|
|
|
|
bool implHandleUnknown(
|
2015-08-03 09:14:58 +02:00
|
|
|
const css::uno::Reference< css::task::XInteractionRequest >& _rxRequest );
|
2005-01-21 16:21:57 +00:00
|
|
|
|
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
|
|
|
|
*/
|
2015-04-24 15:29:31 +02:00
|
|
|
static sal_Int32 getContinuation(
|
2000-10-25 12:00:01 +00:00
|
|
|
Continuation _eCont,
|
2015-08-03 09:14:58 +02:00
|
|
|
const css::uno::Sequence< css::uno::Reference< css::task::XInteractionContinuation > >& _rContinuations);
|
2000-10-25 12:00:01 +00:00
|
|
|
};
|
|
|
|
|
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:
|
2015-09-07 09:33:18 +01:00
|
|
|
explicit SQLExceptionInteractionHandler(
|
2015-08-03 09:14:58 +02:00
|
|
|
const css::uno::Reference< css::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
|
2017-01-19 17:58:58 +01:00
|
|
|
DECLARE_SERVICE_INFO();
|
|
|
|
/// @throws css::uno::RuntimeException
|
No need to keep these whitelisted functions decorated with SAL_CALL
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-14 08:45:02 +01:00
|
|
|
static OUString getImplementationName_Static( );
|
2017-01-19 17:58:58 +01:00
|
|
|
/// @throws css::uno::RuntimeException
|
No need to keep these whitelisted functions decorated with SAL_CALL
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-14 08:45:02 +01:00
|
|
|
static css::uno::Sequence< OUString > getSupportedServiceNames_Static( );
|
2017-01-19 17:58:58 +01:00
|
|
|
static css::uno::Reference< css::uno::XInterface >
|
No need to keep these whitelisted functions decorated with SAL_CALL
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-14 08:45:02 +01:00
|
|
|
Create(const css::uno::Reference< css::lang::XMultiServiceFactory >&);
|
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
|
|
|
};
|
|
|
|
|
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:
|
2015-09-07 09:33:18 +01:00
|
|
|
explicit LegacyInteractionHandler(
|
2015-08-03 09:14:58 +02:00
|
|
|
const css::uno::Reference< css::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
|
2017-01-19 17:58:58 +01:00
|
|
|
DECLARE_SERVICE_INFO();
|
|
|
|
/// @throws css::uno::RuntimeException
|
No need to keep these whitelisted functions decorated with SAL_CALL
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-14 08:45:02 +01:00
|
|
|
static OUString getImplementationName_Static( );
|
2017-01-19 17:58:58 +01:00
|
|
|
/// @throws css::uno::RuntimeException
|
No need to keep these whitelisted functions decorated with SAL_CALL
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-14 08:45:02 +01:00
|
|
|
static css::uno::Sequence< OUString > getSupportedServiceNames_Static( );
|
2017-01-19 17:58:58 +01:00
|
|
|
static css::uno::Reference< css::uno::XInterface >
|
No need to keep these whitelisted functions decorated with SAL_CALL
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-14 08:45:02 +01:00
|
|
|
Create(const css::uno::Reference< css::lang::XMultiServiceFactory >&);
|
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
|
|
|
};
|
|
|
|
|
2000-10-25 12:00:01 +00:00
|
|
|
} // namespace dbaui
|
|
|
|
|
2013-11-05 02:18:53 +01:00
|
|
|
#endif // INCLUDED_DBACCESS_SOURCE_UI_UNO_DBINTERACTION_HXX
|
2000-10-25 12:00:01 +00:00
|
|
|
|
2010-10-27 12:33:13 +01:00
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|