2010-10-12 15:59:03 +02:00
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
2000-10-25 12:00:01 +00:00
/*************************************************************************
*
2008-04-10 15:53:58 +00:00
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER .
2000-10-25 12:00:01 +00:00
*
2010-02-12 15:01:35 +01:00
* Copyright 2000 , 2010 Oracle and / or its affiliates .
2000-10-25 12:00:01 +00:00
*
2008-04-10 15:53:58 +00:00
* OpenOffice . org - a multi - platform office productivity suite
2000-10-25 12:00:01 +00:00
*
2008-04-10 15:53:58 +00:00
* This file is part of OpenOffice . org .
2000-10-25 12:00:01 +00:00
*
2008-04-10 15:53:58 +00:00
* 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 .
2000-10-25 12:00:01 +00:00
*
2008-04-10 15:53:58 +00:00
* 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 ) .
2000-10-25 12:00:01 +00:00
*
2008-04-10 15:53:58 +00:00
* You should have received a copy of the GNU Lesser General Public License
* version 3 along with OpenOffice . org . If not , see
* < http : //www.openoffice.org/license.html>
* for a copy of the LGPLv3 License .
2000-10-25 12:00:01 +00:00
*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2006-09-17 06:34:07 +00:00
// MARKER(update_precomp.py): autogen include statement, do not remove
# include "precompiled_dbaccess.hxx"
2000-10-25 12:00:01 +00:00
# include "dbinteraction.hxx"
2000-12-15 14:54:12 +00:00
# include "dbu_reghelper.hxx"
2000-10-25 12:00:01 +00:00
# include <tools/debug.hxx>
2008-03-06 17:30:56 +00:00
# include <tools/diagnose_ex.h>
2000-10-25 12:00:01 +00:00
# include <vcl/msgbox.hxx>
# include <connectivity/dbexception.hxx>
# include "sqlmessage.hxx"
# include <com/sun/star/task/XInteractionApprove.hpp>
# include <com/sun/star/task/XInteractionDisapprove.hpp>
# include <com/sun/star/task/XInteractionRetry.hpp>
# include <com/sun/star/task/XInteractionAbort.hpp>
2000-10-26 17:08:16 +00:00
# include <com/sun/star/sdb/XInteractionSupplyParameters.hpp>
2004-08-02 15:23:14 +00:00
# include <com/sun/star/sdb/XInteractionDocumentSave.hpp>
2004-11-17 13:54:05 +00:00
# include <sfx2/QuerySaveDocument.hxx>
2002-08-19 07:01:32 +00:00
# include "dbu_uno.hrc"
2000-10-26 17:08:16 +00:00
# include "paramdialog.hxx"
2001-05-17 08:09:44 +00:00
# include <vcl/svapp.hxx>
# include <vos/mutex.hxx>
2004-08-02 15:23:14 +00:00
# include "CollectionView.hxx"
2005-03-10 15:55:44 +00:00
# include "UITools.hxx"
2000-10-25 12:00:01 +00:00
//==========================================================================
extern " C " void SAL_CALL createRegistryInfo_OInteractionHandler ( )
{
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
static : : dbaui : : OMultiInstanceAutoRegistration < : : dbaui : : SQLExceptionInteractionHandler > aSQLExceptionInteractionHandler_AutoRegistration ;
static : : dbaui : : OMultiInstanceAutoRegistration < : : dbaui : : LegacyInteractionHandler > aLegacyInteractionHandler_AutoRegistration ;
2000-10-25 12:00:01 +00:00
}
//.........................................................................
namespace dbaui
{
//.........................................................................
using namespace : : com : : sun : : star : : uno ;
using namespace : : com : : sun : : star : : ucb ;
2000-10-26 17:08:16 +00:00
using namespace : : com : : sun : : star : : sdb ;
2000-10-25 12:00:01 +00:00
using namespace : : com : : sun : : star : : lang ;
using namespace : : com : : sun : : star : : task ;
2000-10-26 17:08:16 +00:00
using namespace : : com : : sun : : star : : beans ;
2000-10-25 12:00:01 +00:00
using namespace : : dbtools ;
//=========================================================================
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
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
BasicInteractionHandler : : BasicInteractionHandler ( const Reference < XMultiServiceFactory > & _rxORB , const bool i_bFallbackToGeneric )
: m_xORB ( _rxORB )
, m_bFallbackToGeneric ( i_bFallbackToGeneric )
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
OSL_ENSURE ( ! m_bFallbackToGeneric ,
" BasicInteractionHandler::BasicInteractionHandler: enabling legacy behavior, there should be no clients of this anymore! " ) ;
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
: : sal_Bool SAL_CALL BasicInteractionHandler : : handleInteractionRequest ( const Reference < XInteractionRequest > & i_rRequest ) throw ( RuntimeException )
{
return impl_handle_throw ( i_rRequest ) ;
}
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
void SAL_CALL BasicInteractionHandler : : handle ( const Reference < XInteractionRequest > & i_rRequest ) throw ( 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
impl_handle_throw ( i_rRequest ) ;
}
//-------------------------------------------------------------------------
sal_Bool BasicInteractionHandler : : impl_handle_throw ( const Reference < XInteractionRequest > & i_Request )
{
Any aRequest ( i_Request - > getRequest ( ) ) ;
DBG_ASSERT ( aRequest . hasValue ( ) , " BasicInteractionHandler::handle: invalid request! " ) ;
if ( ! aRequest . hasValue ( ) )
2000-10-25 12:00:01 +00:00
// no request -> no handling
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
return sal_False ;
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
Sequence < Reference < XInteractionContinuation > > aContinuations ( i_Request - > getContinuations ( ) ) ;
2000-10-25 12:00:01 +00:00
// try to extract an SQLException (or one of it's derived members
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
SQLExceptionInfo aInfo ( aRequest ) ;
if ( aInfo . isValid ( ) )
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
implHandle ( aInfo , aContinuations ) ;
return sal_True ;
2000-10-25 12:00:01 +00:00
}
2000-10-26 17:08:16 +00:00
ParametersRequest aParamRequest ;
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
if ( aRequest > > = aParamRequest )
{
implHandle ( aParamRequest , aContinuations ) ;
return sal_True ;
2000-10-26 17:08:16 +00:00
}
2004-08-02 15:23:14 +00:00
DocumentSaveRequest aDocuRequest ;
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
if ( aRequest > > = aDocuRequest )
{
implHandle ( aDocuRequest , aContinuations ) ;
return sal_True ;
2004-08-02 15:23:14 +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
if ( m_bFallbackToGeneric )
return implHandleUnknown ( i_Request ) ;
return sal_False ;
2000-10-25 12:00:01 +00:00
}
2000-10-26 17:08:16 +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
void BasicInteractionHandler : : implHandle ( const ParametersRequest & _rParamRequest , const Sequence < Reference < XInteractionContinuation > > & _rContinuations )
2000-10-26 17:08:16 +00:00
{
2010-10-13 01:38:41 -05:00
SolarMutexGuard aGuard ;
2001-05-17 08:09:44 +00:00
// want to open a dialog ....
2000-10-26 17:08:16 +00:00
sal_Int32 nAbortPos = getContinuation ( ABORT , _rContinuations ) ;
sal_Int32 nParamPos = getContinuation ( SUPPLY_PARAMETERS , _rContinuations ) ;
Reference < XInteractionSupplyParameters > xParamCallback ;
if ( - 1 ! = nParamPos )
xParamCallback = Reference < XInteractionSupplyParameters > ( _rContinuations [ nParamPos ] , UNO_QUERY ) ;
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
DBG_ASSERT ( xParamCallback . is ( ) , " BasicInteractionHandler::implHandle(ParametersRequest): can't set the parameters without an appropriate interaction handler!s " ) ;
2000-10-26 17:08:16 +00:00
// determine the style of the dialog, dependent on the present continuation types
WinBits nDialogStyle = WB_OK | WB_DEF_OK ;
if ( - 1 ! = nAbortPos )
nDialogStyle = WB_OK_CANCEL ;
OParameterDialog aDlg ( NULL , _rParamRequest . Parameters , _rParamRequest . Connection , m_xORB ) ;
sal_Int16 nResult = aDlg . Execute ( ) ;
try
{
switch ( nResult )
{
case RET_OK :
if ( xParamCallback . is ( ) )
{
xParamCallback - > setParameters ( aDlg . getValues ( ) ) ;
xParamCallback - > select ( ) ;
}
break ;
default :
if ( - 1 ! = nAbortPos )
_rContinuations [ nAbortPos ] - > select ( ) ;
break ;
}
}
2008-05-05 15:10:42 +00:00
catch ( const Exception & )
2000-10-26 17:08:16 +00:00
{
2008-05-05 15:10:42 +00:00
DBG_UNHANDLED_EXCEPTION ( ) ;
2000-10-26 17:08:16 +00:00
}
}
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
void BasicInteractionHandler : : implHandle ( const SQLExceptionInfo & _rSqlInfo , const Sequence < Reference < XInteractionContinuation > > & _rContinuations )
2000-10-25 12:00:01 +00:00
{
2010-10-13 01:38:41 -05:00
SolarMutexGuard aGuard ;
2001-05-17 08:09:44 +00:00
// want to open a dialog ....
2000-10-25 12:00:01 +00:00
sal_Int32 nApprovePos = getContinuation ( APPROVE , _rContinuations ) ;
2008-01-30 07:56:49 +00:00
sal_Int32 nDisapprovePos = getContinuation ( DISAPPROVE , _rContinuations ) ;
2000-10-25 12:00:01 +00:00
sal_Int32 nAbortPos = getContinuation ( ABORT , _rContinuations ) ;
sal_Int32 nRetryPos = getContinuation ( RETRY , _rContinuations ) ;
2008-01-30 07:56:49 +00:00
2000-10-26 17:08:16 +00:00
// determine the style of the dialog, dependent on the present continuation types
2008-01-30 07:56:49 +00:00
WinBits nDialogStyle = 0 ;
bool bHaveCancel = nAbortPos ! = - 1 ;
// "approve" means "Yes", "disapprove" means "No"
// VCL only supports having both (which makes sense ...)
if ( ( nApprovePos ! = - 1 ) | | ( nDisapprovePos ! = - 1 ) )
nDialogStyle = ( bHaveCancel ? WB_YES_NO_CANCEL : WB_YES_NO ) | WB_DEF_YES ;
else
{
// if there's no yes/no, then use a default OK button
nDialogStyle = ( bHaveCancel ? WB_OK_CANCEL : WB_OK ) | WB_DEF_OK ;
}
// If there's a "Retry" continuation, have a "Retry" button
if ( nRetryPos ! = - 1 )
{
nDialogStyle = WB_RETRY_CANCEL | WB_DEF_RETRY ;
}
2000-10-25 12:00:01 +00:00
// excute the dialog
OSQLMessageBox aDialog ( NULL , _rSqlInfo , nDialogStyle ) ;
// TODO: need a way to specify the parent window
sal_Int16 nResult = aDialog . Execute ( ) ;
try
{
switch ( nResult )
{
2008-01-30 07:56:49 +00:00
case RET_YES :
2000-10-25 12:00:01 +00:00
case RET_OK :
2008-01-30 07:56:49 +00:00
if ( nApprovePos ! = - 1 )
_rContinuations [ nApprovePos ] - > select ( ) ;
else
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
OSL_ENSURE ( nResult ! = RET_YES , " BasicInteractionHandler::implHandle: no handler for YES! " ) ;
2008-01-30 07:56:49 +00:00
break ;
case RET_NO :
if ( nDisapprovePos ! = - 1 )
_rContinuations [ nDisapprovePos ] - > select ( ) ;
else
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
OSL_ENSURE ( false , " BasicInteractionHandler::implHandle: no handler for NO! " ) ;
2000-10-25 12:00:01 +00:00
break ;
2008-01-30 07:56:49 +00:00
2000-10-25 12:00:01 +00:00
case RET_CANCEL :
2008-01-30 07:56:49 +00:00
if ( nAbortPos ! = - 1 )
_rContinuations [ nAbortPos ] - > select ( ) ;
else if ( nDisapprovePos ! = - 1 )
_rContinuations [ nDisapprovePos ] - > select ( ) ;
else
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
OSL_ENSURE ( false , " BasicInteractionHandler::implHandle: no handler for CANCEL! " ) ;
2000-10-25 12:00:01 +00:00
break ;
case RET_RETRY :
2008-01-30 07:56:49 +00:00
if ( nRetryPos ! = - 1 )
_rContinuations [ nRetryPos ] - > select ( ) ;
else
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
OSL_ENSURE ( false , " BasicInteractionHandler::implHandle: where does the RETRY come from? " ) ;
2000-10-25 12:00:01 +00:00
break ;
}
}
2008-03-06 17:30:56 +00:00
catch ( const Exception & )
2000-10-25 12:00:01 +00:00
{
2008-03-06 17:30:56 +00:00
DBG_UNHANDLED_EXCEPTION ( ) ;
2000-10-25 12:00:01 +00:00
}
}
2004-08-02 15:23:14 +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
void BasicInteractionHandler : : implHandle ( const DocumentSaveRequest & _rDocuRequest , const Sequence < Reference < XInteractionContinuation > > & _rContinuations )
2004-08-02 15:23:14 +00:00
{
2010-10-13 01:38:41 -05:00
SolarMutexGuard aGuard ;
2004-08-02 15:23:14 +00:00
// want to open a dialog ....
sal_Int32 nApprovePos = getContinuation ( APPROVE , _rContinuations ) ;
sal_Int32 nDisApprovePos = getContinuation ( DISAPPROVE , _rContinuations ) ;
sal_Int32 nAbortPos = getContinuation ( ABORT , _rContinuations ) ;
short nRet = RET_YES ;
if ( - 1 ! = nApprovePos )
{
// fragen, ob gespeichert werden soll
2004-11-17 13:54:05 +00:00
nRet = ExecuteQuerySaveDocument ( NULL , _rDocuRequest . Name ) ;
2004-08-02 15:23:14 +00:00
}
if ( RET_CANCEL = = nRet )
{
if ( - 1 ! = nAbortPos )
_rContinuations [ nAbortPos ] - > select ( ) ;
return ;
}
else if ( RET_YES = = nRet )
{
sal_Int32 nDocuPos = getContinuation ( SUPPLY_DOCUMENTSAVE , _rContinuations ) ;
if ( - 1 ! = nDocuPos )
{
Reference < XInteractionDocumentSave > xCallback ( _rContinuations [ nDocuPos ] , UNO_QUERY ) ;
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
DBG_ASSERT ( xCallback . is ( ) , " BasicInteractionHandler::implHandle(DocumentSaveRequest): can't save document without an appropriate interaction handler!s " ) ;
2004-08-02 15:23:14 +00:00
// determine the style of the dialog, dependent on the present continuation types
WinBits nDialogStyle = WB_OK | WB_DEF_OK ;
if ( - 1 ! = nAbortPos )
nDialogStyle = WB_OK_CANCEL ;
OCollectionView aDlg ( NULL , _rDocuRequest . Content , _rDocuRequest . Name , m_xORB ) ;
sal_Int16 nResult = aDlg . Execute ( ) ;
try
{
switch ( nResult )
{
case RET_OK :
if ( xCallback . is ( ) )
{
xCallback - > setName ( aDlg . getName ( ) , aDlg . getSelectedFolder ( ) ) ;
xCallback - > select ( ) ;
}
break ;
default :
if ( - 1 ! = nAbortPos )
_rContinuations [ nAbortPos ] - > select ( ) ;
break ;
}
}
2008-05-05 15:10:42 +00:00
catch ( const Exception & )
2004-08-02 15:23:14 +00:00
{
2008-05-05 15:10:42 +00:00
DBG_UNHANDLED_EXCEPTION ( ) ;
2004-08-02 15:23:14 +00:00
}
}
else if ( - 1 ! = nApprovePos )
_rContinuations [ nApprovePos ] - > select ( ) ;
}
else if ( - 1 ! = nDisApprovePos )
_rContinuations [ nDisApprovePos ] - > select ( ) ;
}
2000-10-25 12:00:01 +00:00
2005-01-21 16:21:42 +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
bool BasicInteractionHandler : : implHandleUnknown ( const Reference < XInteractionRequest > & _rxRequest )
2005-01-21 16:21:42 +00:00
{
Reference < XInteractionHandler > xFallbackHandler ;
if ( m_xORB . is ( ) )
xFallbackHandler = xFallbackHandler . query ( m_xORB - > createInstance ( : : rtl : : OUString ( RTL_CONSTASCII_USTRINGPARAM ( " com.sun.star.task.InteractionHandler " ) ) ) ) ;
if ( xFallbackHandler . is ( ) )
{
xFallbackHandler - > handle ( _rxRequest ) ;
return true ;
}
return false ;
}
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
sal_Int32 BasicInteractionHandler : : getContinuation ( Continuation _eCont , const Sequence < Reference < XInteractionContinuation > > & _rContinuations )
2000-10-25 12:00:01 +00:00
{
const Reference < XInteractionContinuation > * pContinuations = _rContinuations . getConstArray ( ) ;
for ( sal_Int32 i = 0 ; i < _rContinuations . getLength ( ) ; + + i , + + pContinuations )
{
switch ( _eCont )
{
case APPROVE :
if ( Reference < XInteractionApprove > ( * pContinuations , UNO_QUERY ) . is ( ) )
return i ;
break ;
case DISAPPROVE :
if ( Reference < XInteractionDisapprove > ( * pContinuations , UNO_QUERY ) . is ( ) )
return i ;
break ;
case RETRY :
if ( Reference < XInteractionRetry > ( * pContinuations , UNO_QUERY ) . is ( ) )
return i ;
break ;
case ABORT :
if ( Reference < XInteractionAbort > ( * pContinuations , UNO_QUERY ) . is ( ) )
return i ;
break ;
2000-10-26 17:08:16 +00:00
case SUPPLY_PARAMETERS :
if ( Reference < XInteractionSupplyParameters > ( * pContinuations , UNO_QUERY ) . is ( ) )
return i ;
break ;
2004-08-02 15:23:14 +00:00
case SUPPLY_DOCUMENTSAVE :
if ( Reference < XInteractionDocumentSave > ( * pContinuations , UNO_QUERY ) . is ( ) )
return i ;
break ;
2000-10-25 12:00:01 +00:00
}
}
return - 1 ;
}
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
//==========================================================================
//= SQLExceptionInteractionHandler
//==========================================================================
IMPLEMENT_SERVICE_INFO1_STATIC ( SQLExceptionInteractionHandler , " com.sun.star.comp.dbaccess.DatabaseInteractionHandler " , " com.sun.star.sdb.DatabaseInteractionHandler " ) ;
//==========================================================================
//= LegacyInteractionHandler
//==========================================================================
IMPLEMENT_SERVICE_INFO1_STATIC ( LegacyInteractionHandler , " com.sun.star.comp.dbaccess.LegacyInteractionHandler " , " com.sun.star.sdb.InteractionHandler " ) ;
2000-10-25 12:00:01 +00:00
//.........................................................................
} // namespace dbaui
//.........................................................................
2010-10-12 15:59:03 +02:00
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */