2010-10-27 12:45:03 +01:00
|
|
|
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
|
2012-06-21 14:30:25 +01:00
|
|
|
/*
|
|
|
|
|
* This file is part of the LibreOffice project.
|
|
|
|
|
*
|
|
|
|
|
* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
|
*
|
|
|
|
|
* This file incorporates work covered by the following license notice:
|
|
|
|
|
*
|
|
|
|
|
* Licensed to the Apache Software Foundation (ASF) under one or more
|
|
|
|
|
* contributor license agreements. See the NOTICE file distributed
|
|
|
|
|
* with this work for additional information regarding copyright
|
|
|
|
|
* ownership. The ASF licenses this file to you under the Apache
|
|
|
|
|
* License, Version 2.0 (the "License"); you may not use this file
|
|
|
|
|
* except in compliance with the License. You may obtain a copy of
|
|
|
|
|
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
|
|
|
|
|
*/
|
2004-11-16 11:02:56 +00:00
|
|
|
|
2014-04-18 20:41:29 +02:00
|
|
|
#ifndef INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_CELLBINDINGHANDLER_HXX
|
|
|
|
|
#define INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_CELLBINDINGHANDLER_HXX
|
2004-11-16 11:02:56 +00:00
|
|
|
|
|
|
|
|
#include "propertyhandler.hxx"
|
|
|
|
|
|
|
|
|
|
#include <com/sun/star/lang/XMultiServiceFactory.hpp>
|
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
|
|
|
#include <rtl/ref.hxx>
|
|
|
|
|
|
2004-11-16 11:02:56 +00:00
|
|
|
#include <memory>
|
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2004-11-16 11:02:56 +00:00
|
|
|
namespace pcr
|
|
|
|
|
{
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2004-11-16 11:02:56 +00:00
|
|
|
|
|
|
|
|
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;
|
2014-02-25 18:36:00 +01:00
|
|
|
|
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
|
2004-11-16 11:02:56 +00:00
|
|
|
{
|
|
|
|
|
private:
|
2017-02-17 19:06:24 +02:00
|
|
|
std::unique_ptr< CellBindingHelper > m_pHelper;
|
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
|
|
|
::rtl::Reference< IPropertyEnumRepresentation > m_pCellExchangeConverter;
|
2004-11-16 11:02:56 +00:00
|
|
|
|
|
|
|
|
public:
|
2015-10-18 07:53:51 +02:00
|
|
|
explicit CellBindingPropertyHandler(
|
2015-09-30 11:48:44 +02:00
|
|
|
const css::uno::Reference< css::uno::XComponentContext >& _rxContext
|
2004-11-16 11:02:56 +00:00
|
|
|
);
|
|
|
|
|
|
2017-01-19 17:57:50 +01:00
|
|
|
/// @throws css::uno::RuntimeException
|
No need to keep these whitelisted functions decorated with SAL_CALL
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-14 08:45:02 +01:00
|
|
|
static OUString getImplementationName_static( );
|
2017-01-19 17:57:50 +01:00
|
|
|
/// @throws css::uno::RuntimeException
|
No need to keep these whitelisted functions decorated with SAL_CALL
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-14 08:45:02 +01:00
|
|
|
static css::uno::Sequence< OUString > getSupportedServiceNames_static( );
|
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
|
|
|
|
|
|
|
|
protected:
|
2016-09-13 13:09:01 +02:00
|
|
|
virtual ~CellBindingPropertyHandler() override;
|
2004-11-16 11:02:56 +00:00
|
|
|
|
|
|
|
|
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
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual css::uno::Any SAL_CALL getPropertyValue( const OUString& _rPropertyName ) override;
|
|
|
|
|
virtual void SAL_CALL setPropertyValue( const OUString& _rPropertyName, const css::uno::Any& _rValue ) override;
|
|
|
|
|
virtual css::uno::Any SAL_CALL convertToPropertyValue( const OUString& _rPropertyName, const css::uno::Any& _rControlValue ) override;
|
|
|
|
|
virtual css::uno::Any SAL_CALL convertToControlValue( const OUString& _rPropertyName, const css::uno::Any& _rPropertyValue, const css::uno::Type& _rControlValueType ) override;
|
|
|
|
|
virtual css::uno::Sequence< OUString > SAL_CALL getActuatingProperties( ) override;
|
|
|
|
|
virtual void SAL_CALL actuatingPropertyChanged( const OUString& _rActuatingPropertyName, const css::uno::Any& _rNewValue, const css::uno::Any& _rOldValue, const css::uno::Reference< css::inspection::XObjectInspectorUI >& _rxInspectorUI, sal_Bool _bFirstTimeInit ) override;
|
2004-11-16 11:02:56 +00:00
|
|
|
|
|
|
|
|
// PropertyHandler overridables
|
2015-09-30 11:48:44 +02:00
|
|
|
virtual css::uno::Sequence< css::beans::Property >
|
2017-12-05 10:11:39 +02:00
|
|
|
doDescribeSupportedProperties() const override;
|
2015-10-12 16:04:04 +02:00
|
|
|
virtual void onNewComponent() override;
|
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
|
|
|
|
|
|
|
|
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
|
2014-04-29 19:05:05 +00:00
|
|
|
UI, more precisely) are updated in this method.
|
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
|
|
|
|
|
|
|
|
@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/>.
|
|
|
|
|
*/
|
2015-09-30 11:48:44 +02:00
|
|
|
void impl_updateDependentProperty_nothrow( PropertyId _nPropId, const css::uno::Reference< css::inspection::XObjectInspectorUI >& _rxInspectorUI ) const;
|
2004-11-16 11:02:56 +00:00
|
|
|
};
|
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2004-11-16 11:02:56 +00:00
|
|
|
} // namespace pcr
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2004-11-16 11:02:56 +00:00
|
|
|
|
2014-04-18 20:41:29 +02:00
|
|
|
#endif // INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_CELLBINDINGHANDLER_HXX
|
2004-11-16 11:02:56 +00:00
|
|
|
|
2010-10-27 12:45:03 +01:00
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|