Files
libreoffice/extensions/source/propctrlr/cellbindinghandler.hxx

125 lines
6.4 KiB
C++
Raw Normal View History

/*************************************************************************
*
* OpenOffice.org - a multi-platform office productivity suite
*
* $RCSfile: cellbindinghandler.hxx,v $
*
INTEGRATION: CWS pbrwuno (1.2.158); FILE MERGED 2005/11/02 11:43:37 fs 1.2.158.11: #i10000# exception specifications 2005/10/25 12:13:05 fs 1.2.158.10: #i53095# cache the enum converter 2005/10/24 08:41:39 fs 1.2.158.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/13 13:00:58 fs 1.2.158.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:28:54 fs 1.2.158.7: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:51:30 fs 1.2.158.6: RESYNC: (1.2-1.3); FILE MERGED 2005/08/18 12:44:26 fs 1.2.158.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:38:57 fs 1.2.158.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:08 fs 1.2.158.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/10 15:41:43 fs 1.2.158.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:56 fs 1.2.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:19:12 +00:00
* $Revision: 1.4 $
*
INTEGRATION: CWS pbrwuno (1.2.158); FILE MERGED 2005/11/02 11:43:37 fs 1.2.158.11: #i10000# exception specifications 2005/10/25 12:13:05 fs 1.2.158.10: #i53095# cache the enum converter 2005/10/24 08:41:39 fs 1.2.158.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/13 13:00:58 fs 1.2.158.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:28:54 fs 1.2.158.7: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:51:30 fs 1.2.158.6: RESYNC: (1.2-1.3); FILE MERGED 2005/08/18 12:44:26 fs 1.2.158.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:38:57 fs 1.2.158.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:08 fs 1.2.158.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/10 15:41:43 fs 1.2.158.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:56 fs 1.2.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:19:12 +00:00
* last change: $Author: vg $ $Date: 2006-03-14 11:19:12 $
*
* The Contents of this file are made available subject to
* the terms of GNU Lesser General Public License Version 2.1.
*
*
* GNU Lesser General Public License Version 2.1
* =============================================
* Copyright 2005 by Sun Microsystems, Inc.
* 901 San Antonio Road, Palo Alto, CA 94303, USA
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License version 2.1, as published by the Free Software Foundation.
*
* This library 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 for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*
************************************************************************/
#ifndef EXTENSIONS_SOURCE_PROPCTRLR_CELLBINDINGHANDLER_HXX
#define EXTENSIONS_SOURCE_PROPCTRLR_CELLBINDINGHANDLER_HXX
#ifndef EXTENSIONS_SOURCE_PROPCTRLR_PROPERTYHANDLER_HXX
#include "propertyhandler.hxx"
#endif
/** === begin UNO includes === **/
#ifndef _COM_SUN_STAR_LANG_XMULTISERVICEFACTORY_HPP_
#include <com/sun/star/lang/XMultiServiceFactory.hpp>
#endif
/** === end UNO includes === **/
INTEGRATION: CWS pbrwuno (1.2.158); FILE MERGED 2005/11/02 11:43:37 fs 1.2.158.11: #i10000# exception specifications 2005/10/25 12:13:05 fs 1.2.158.10: #i53095# cache the enum converter 2005/10/24 08:41:39 fs 1.2.158.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/13 13:00:58 fs 1.2.158.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:28:54 fs 1.2.158.7: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:51:30 fs 1.2.158.6: RESYNC: (1.2-1.3); FILE MERGED 2005/08/18 12:44:26 fs 1.2.158.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:38:57 fs 1.2.158.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:08 fs 1.2.158.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/10 15:41:43 fs 1.2.158.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:56 fs 1.2.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:19:12 +00:00
#ifndef _RTL_REF_HXX_
#include <rtl/ref.hxx>
#endif
#include <memory>
//........................................................................
namespace pcr
{
//........................................................................
class CellBindingHelper;
INTEGRATION: CWS pbrwuno (1.2.158); FILE MERGED 2005/11/02 11:43:37 fs 1.2.158.11: #i10000# exception specifications 2005/10/25 12:13:05 fs 1.2.158.10: #i53095# cache the enum converter 2005/10/24 08:41:39 fs 1.2.158.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/13 13:00:58 fs 1.2.158.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:28:54 fs 1.2.158.7: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:51:30 fs 1.2.158.6: RESYNC: (1.2-1.3); FILE MERGED 2005/08/18 12:44:26 fs 1.2.158.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:38:57 fs 1.2.158.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:08 fs 1.2.158.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/10 15:41:43 fs 1.2.158.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:56 fs 1.2.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:19:12 +00:00
class IPropertyEnumRepresentation;
//====================================================================
//= CellBindingPropertyHandler
//====================================================================
INTEGRATION: CWS pbrwuno (1.2.158); FILE MERGED 2005/11/02 11:43:37 fs 1.2.158.11: #i10000# exception specifications 2005/10/25 12:13:05 fs 1.2.158.10: #i53095# cache the enum converter 2005/10/24 08:41:39 fs 1.2.158.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/13 13:00:58 fs 1.2.158.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:28:54 fs 1.2.158.7: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:51:30 fs 1.2.158.6: RESYNC: (1.2-1.3); FILE MERGED 2005/08/18 12:44:26 fs 1.2.158.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:38:57 fs 1.2.158.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:08 fs 1.2.158.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/10 15:41:43 fs 1.2.158.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:56 fs 1.2.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:19:12 +00:00
class CellBindingPropertyHandler;
typedef HandlerComponentBase< CellBindingPropertyHandler > CellBindingPropertyHandler_Base;
class CellBindingPropertyHandler : public CellBindingPropertyHandler_Base
{
private:
INTEGRATION: CWS pbrwuno (1.2.158); FILE MERGED 2005/11/02 11:43:37 fs 1.2.158.11: #i10000# exception specifications 2005/10/25 12:13:05 fs 1.2.158.10: #i53095# cache the enum converter 2005/10/24 08:41:39 fs 1.2.158.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/13 13:00:58 fs 1.2.158.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:28:54 fs 1.2.158.7: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:51:30 fs 1.2.158.6: RESYNC: (1.2-1.3); FILE MERGED 2005/08/18 12:44:26 fs 1.2.158.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:38:57 fs 1.2.158.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:08 fs 1.2.158.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/10 15:41:43 fs 1.2.158.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:56 fs 1.2.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:19:12 +00:00
::std::auto_ptr< CellBindingHelper > m_pHelper;
::rtl::Reference< IPropertyEnumRepresentation > m_pCellExchangeConverter;
public:
CellBindingPropertyHandler(
INTEGRATION: CWS pbrwuno (1.2.158); FILE MERGED 2005/11/02 11:43:37 fs 1.2.158.11: #i10000# exception specifications 2005/10/25 12:13:05 fs 1.2.158.10: #i53095# cache the enum converter 2005/10/24 08:41:39 fs 1.2.158.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/13 13:00:58 fs 1.2.158.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:28:54 fs 1.2.158.7: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:51:30 fs 1.2.158.6: RESYNC: (1.2-1.3); FILE MERGED 2005/08/18 12:44:26 fs 1.2.158.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:38:57 fs 1.2.158.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:08 fs 1.2.158.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/10 15:41:43 fs 1.2.158.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:56 fs 1.2.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:19:12 +00:00
const ::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext >& _rxContext
);
INTEGRATION: CWS pbrwuno (1.2.158); FILE MERGED 2005/11/02 11:43:37 fs 1.2.158.11: #i10000# exception specifications 2005/10/25 12:13:05 fs 1.2.158.10: #i53095# cache the enum converter 2005/10/24 08:41:39 fs 1.2.158.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/13 13:00:58 fs 1.2.158.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:28:54 fs 1.2.158.7: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:51:30 fs 1.2.158.6: RESYNC: (1.2-1.3); FILE MERGED 2005/08/18 12:44:26 fs 1.2.158.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:38:57 fs 1.2.158.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:08 fs 1.2.158.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/10 15:41:43 fs 1.2.158.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:56 fs 1.2.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:19:12 +00:00
static ::rtl::OUString SAL_CALL getImplementationName_static( ) throw (::com::sun::star::uno::RuntimeException);
static ::com::sun::star::uno::Sequence< ::rtl::OUString > SAL_CALL getSupportedServiceNames_static( ) throw (::com::sun::star::uno::RuntimeException);
protected:
~CellBindingPropertyHandler();
protected:
INTEGRATION: CWS pbrwuno (1.2.158); FILE MERGED 2005/11/02 11:43:37 fs 1.2.158.11: #i10000# exception specifications 2005/10/25 12:13:05 fs 1.2.158.10: #i53095# cache the enum converter 2005/10/24 08:41:39 fs 1.2.158.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/13 13:00:58 fs 1.2.158.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:28:54 fs 1.2.158.7: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:51:30 fs 1.2.158.6: RESYNC: (1.2-1.3); FILE MERGED 2005/08/18 12:44:26 fs 1.2.158.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:38:57 fs 1.2.158.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:08 fs 1.2.158.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/10 15:41:43 fs 1.2.158.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:56 fs 1.2.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:19:12 +00:00
// XPropertyHandler overriables
virtual ::com::sun::star::uno::Any SAL_CALL getPropertyValue( const ::rtl::OUString& _rPropertyName ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL setPropertyValue( const ::rtl::OUString& _rPropertyName, const ::com::sun::star::uno::Any& _rValue ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::uno::Any SAL_CALL convertToPropertyValue( const ::rtl::OUString& _rPropertyName, const ::com::sun::star::uno::Any& _rControlValue ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::uno::Any SAL_CALL convertToControlValue( const ::rtl::OUString& _rPropertyName, const ::com::sun::star::uno::Any& _rPropertyValue, const ::com::sun::star::uno::Type& _rControlValueType ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::uno::Sequence< ::rtl::OUString >
SAL_CALL getActuatingProperties( ) throw (::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL actuatingPropertyChanged( const ::rtl::OUString& _rActuatingPropertyName, const ::com::sun::star::uno::Any& _rNewValue, const ::com::sun::star::uno::Any& _rOldValue, const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XObjectInspectorUI >& _rxInspectorUI, sal_Bool _bFirstTimeInit ) throw (::com::sun::star::lang::NullPointerException, ::com::sun::star::uno::RuntimeException);
// PropertyHandler overridables
INTEGRATION: CWS pbrwuno (1.2.158); FILE MERGED 2005/11/02 11:43:37 fs 1.2.158.11: #i10000# exception specifications 2005/10/25 12:13:05 fs 1.2.158.10: #i53095# cache the enum converter 2005/10/24 08:41:39 fs 1.2.158.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/13 13:00:58 fs 1.2.158.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:28:54 fs 1.2.158.7: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:51:30 fs 1.2.158.6: RESYNC: (1.2-1.3); FILE MERGED 2005/08/18 12:44:26 fs 1.2.158.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:38:57 fs 1.2.158.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:08 fs 1.2.158.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/10 15:41:43 fs 1.2.158.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:56 fs 1.2.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:19:12 +00:00
virtual ::com::sun::star::uno::Sequence< ::com::sun::star::beans::Property >
SAL_CALL doDescribeSupportedProperties() const;
virtual void onNewComponent();
private:
/** updates a property (UI) whose state depends on more than one other property
->actuatingPropertyChanged is called for certain properties in whose changes
we expressed interes (->getActuatingProperty). Now such a property change can
result in simple UI updates, for instance another property being enabled or disabled.
However, it can also result in a more complex change: The current (UI) state might
depend on the value of more than one other property. Those dependent properties (their
UI, more precisly) are updated in this method.
@param _nPropid
the ->PropertyId of the dependent property whose UI state is to be updated
@param _rxInspectorUI
provides access to the property browser UI. Must not be <NULL/>.
*/
void impl_updateDependentProperty_nothrow( PropertyId _nPropId, const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XObjectInspectorUI >& _rxInspectorUI ) const;
};
//........................................................................
} // namespace pcr
//........................................................................
#endif // EXTENSIONS_SOURCE_PROPCTRLR_CELLBINDINGHANDLER_HXX