Files
libreoffice/extensions/source/propctrlr/propertyhandler.cxx

401 lines
18 KiB
C++
Raw Normal View History

/*************************************************************************
*
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* Copyright 2008 by Sun Microsystems, Inc.
*
* OpenOffice.org - a multi-platform office productivity suite
*
* $RCSfile: propertyhandler.cxx,v $
* $Revision: 1.13 $
*
* This file is part of OpenOffice.org.
*
* 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.
*
* 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).
*
* 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.
*
************************************************************************/
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
// MARKER(update_precomp.py): autogen include statement, do not remove
#include "precompiled_extensions.hxx"
#include "propertyhandler.hxx"
#include "formmetadata.hxx"
#include "formbrowsertools.hxx"
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
#include "handlerhelper.hxx"
/** === begin UNO includes === **/
#include <com/sun/star/beans/PropertyAttribute.hpp>
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
#include <com/sun/star/lang/NullPointerException.hpp>
#include <com/sun/star/util/XModifiable.hpp>
/** === end UNO includes === **/
#include <tools/debug.hxx>
#include <algorithm>
//........................................................................
namespace pcr
{
//........................................................................
using namespace ::com::sun::star::uno;
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
using namespace ::com::sun::star::awt;
using namespace ::com::sun::star::beans;
using namespace ::com::sun::star::script;
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
using namespace ::com::sun::star::lang;
using namespace ::com::sun::star::util;
using namespace ::com::sun::star::frame;
using namespace ::com::sun::star::inspection;
using namespace ::comphelper;
//====================================================================
//= PropertyHandler
//====================================================================
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
DBG_NAME( PropertyHandler )
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
PropertyHandler::PropertyHandler( const Reference< XComponentContext >& _rxContext )
:PropertyHandler_Base( m_aMutex )
,m_bSupportedPropertiesAreKnown( false )
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
,m_aPropertyListeners( m_aMutex )
,m_aContext( _rxContext )
,m_pInfoService ( new OPropertyInfoService )
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
DBG_CTOR( PropertyHandler, NULL );
m_xTypeConverter = Reference< XTypeConverter >(
m_aContext.createComponent( "com.sun.star.script.Converter" ),
UNO_QUERY_THROW
);
}
//--------------------------------------------------------------------
PropertyHandler::~PropertyHandler()
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
DBG_DTOR( PropertyHandler, NULL );
}
//--------------------------------------------------------------------
void SAL_CALL PropertyHandler::inspect( const Reference< XInterface >& _rxIntrospectee ) throw (RuntimeException, NullPointerException)
{
if ( !_rxIntrospectee.is() )
throw NullPointerException();
::osl::MutexGuard aGuard( m_aMutex );
Reference< XPropertySet > xNewComponent( _rxIntrospectee, UNO_QUERY );
if ( xNewComponent == m_xComponent )
return;
// remove all old property change listeners
::std::auto_ptr< ::cppu::OInterfaceIteratorHelper > removeListener = m_aPropertyListeners.createIterator();
::std::auto_ptr< ::cppu::OInterfaceIteratorHelper > readdListener = m_aPropertyListeners.createIterator(); // will copy the container as needed
while ( removeListener->hasMoreElements() )
removePropertyChangeListener( static_cast< XPropertyChangeListener* >( removeListener->next() ) );
OSL_ENSURE( m_aPropertyListeners.empty(), "PropertyHandler::inspect: derived classes are expected to forward the removePropertyChangeListener call to their base class (me)!" );
// remember the new component, and give derived classes the chance to react on it
m_xComponent = xNewComponent;
onNewComponent();
// add the listeners, again
while ( readdListener->hasMoreElements() )
addPropertyChangeListener( static_cast< XPropertyChangeListener* >( readdListener->next() ) );
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
void PropertyHandler::onNewComponent()
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
if ( m_xComponent.is() )
m_xComponentPropertyInfo = m_xComponent->getPropertySetInfo();
else
m_xComponentPropertyInfo.clear();
m_bSupportedPropertiesAreKnown = false;
m_aSupportedProperties.realloc( 0 );
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
Sequence< Property > SAL_CALL PropertyHandler::getSupportedProperties() throw (RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
::osl::MutexGuard aGuard( m_aMutex );
if ( !m_bSupportedPropertiesAreKnown )
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
m_aSupportedProperties = doDescribeSupportedProperties();
m_bSupportedPropertiesAreKnown = true;
}
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
return (Sequence< Property >)m_aSupportedProperties;
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
Sequence< ::rtl::OUString > SAL_CALL PropertyHandler::getSupersededProperties( ) throw (RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
return Sequence< ::rtl::OUString >();
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
Sequence< ::rtl::OUString > SAL_CALL PropertyHandler::getActuatingProperties( ) throw (RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
return Sequence< ::rtl::OUString >();
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
Any SAL_CALL PropertyHandler::convertToPropertyValue( const ::rtl::OUString& _rPropertyName, const Any& _rControlValue ) throw (UnknownPropertyException, RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
::osl::MutexGuard aGuard( m_aMutex );
PropertyId nPropId = m_pInfoService->getPropertyId( _rPropertyName );
Property aProperty( impl_getPropertyFromName_throw( _rPropertyName ) );
Any aPropertyValue;
if ( !_rControlValue.hasValue() )
// NULL is converted to NULL
return aPropertyValue;
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
if ( ( m_pInfoService->getPropertyUIFlags( nPropId ) & PROP_FLAG_ENUM ) != 0 )
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
::rtl::OUString sControlValue;
OSL_VERIFY( _rControlValue >>= sControlValue );
::rtl::Reference< IPropertyEnumRepresentation > aEnumConversion(
new DefaultEnumRepresentation( *m_pInfoService, aProperty.Type, nPropId ) );
// TODO/UNOize: cache those converters?
aEnumConversion->getValueFromDescription( sControlValue, aPropertyValue );
}
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
else
aPropertyValue = PropertyHandlerHelper::convertToPropertyValue(
m_aContext.getContext(),m_xTypeConverter, aProperty, _rControlValue );
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
return aPropertyValue;
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
Any SAL_CALL PropertyHandler::convertToControlValue( const ::rtl::OUString& _rPropertyName, const Any& _rPropertyValue, const Type& _rControlValueType ) throw (UnknownPropertyException, RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
::osl::MutexGuard aGuard( m_aMutex );
PropertyId nPropId = m_pInfoService->getPropertyId( _rPropertyName );
if ( ( m_pInfoService->getPropertyUIFlags( nPropId ) & PROP_FLAG_ENUM ) != 0 )
{
DBG_ASSERT( _rControlValueType.getTypeClass() == TypeClass_STRING, "PropertyHandler::convertToControlValue: ENUM, but not STRING?" );
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
::rtl::Reference< IPropertyEnumRepresentation > aEnumConversion(
new DefaultEnumRepresentation( *m_pInfoService, _rPropertyValue.getValueType(), nPropId ) );
// TODO/UNOize: cache those converters?
return makeAny( aEnumConversion->getDescriptionForValue( _rPropertyValue ) );
}
return PropertyHandlerHelper::convertToControlValue(
m_aContext.getContext(),m_xTypeConverter, _rPropertyValue, _rControlValueType );
}
//--------------------------------------------------------------------
PropertyState SAL_CALL PropertyHandler::getPropertyState( const ::rtl::OUString& /*_rPropertyName*/ ) throw (UnknownPropertyException, RuntimeException)
{
return PropertyState_DIRECT_VALUE;
}
//--------------------------------------------------------------------
LineDescriptor SAL_CALL PropertyHandler::describePropertyLine( const ::rtl::OUString& _rPropertyName,
const Reference< XPropertyControlFactory >& _rxControlFactory )
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
throw (UnknownPropertyException, NullPointerException, RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
if ( !_rxControlFactory.is() )
throw NullPointerException();
::osl::MutexGuard aGuard( m_aMutex );
PropertyId nPropId( impl_getPropertyId_throw( _rPropertyName ) );
const Property& rProperty( impl_getPropertyFromId_throw( nPropId ) );
LineDescriptor aDescriptor;
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
if ( ( m_pInfoService->getPropertyUIFlags( nPropId ) & PROP_FLAG_ENUM ) != 0 )
{
aDescriptor.Control = PropertyHandlerHelper::createListBoxControl(
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
_rxControlFactory, m_pInfoService->getPropertyEnumRepresentations( nPropId ),
PropertyHandlerHelper::requiresReadOnlyControl( rProperty.Attributes ), sal_False );
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
}
else
PropertyHandlerHelper::describePropertyLine( rProperty, aDescriptor, _rxControlFactory );
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
aDescriptor.HelpURL = HelpIdUrl::getHelpURL( m_pInfoService->getPropertyHelpId( nPropId ) );
aDescriptor.DisplayName = m_pInfoService->getPropertyTranslation( nPropId );
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
if ( ( m_pInfoService->getPropertyUIFlags( nPropId ) & PROP_FLAG_DATA_PROPERTY ) != 0 )
aDescriptor.Category = ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "Data" ) );
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
else
aDescriptor.Category = ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "General" ) );
return aDescriptor;
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
::sal_Bool SAL_CALL PropertyHandler::isComposable( const ::rtl::OUString& _rPropertyName ) throw (UnknownPropertyException, RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
::osl::MutexGuard aGuard( m_aMutex );
return m_pInfoService->isComposeable( _rPropertyName );
}
//--------------------------------------------------------------------
InteractiveSelectionResult SAL_CALL PropertyHandler::onInteractivePropertySelection( const ::rtl::OUString& /*_rPropertyName*/, sal_Bool /*_bPrimary*/, Any& /*_rData*/, const Reference< XObjectInspectorUI >& /*_rxInspectorUI*/ ) throw (UnknownPropertyException, NullPointerException, RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
DBG_ERROR( "PropertyHandler::onInteractivePropertySelection: not implemented!" );
return InteractiveSelectionResult_Cancelled;
}
//--------------------------------------------------------------------
void SAL_CALL PropertyHandler::actuatingPropertyChanged( const ::rtl::OUString& /*_rActuatingPropertyName*/, const Any& /*_rNewValue*/, const Any& /*_rOldValue*/, const Reference< XObjectInspectorUI >& /*_rxInspectorUI*/, sal_Bool /*_bFirstTimeInit*/ ) throw (NullPointerException, RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
DBG_ERROR( "PropertyHandler::actuatingPropertyChanged: not implemented!" );
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
void SAL_CALL PropertyHandler::addPropertyChangeListener( const Reference< XPropertyChangeListener >& _rxListener ) throw (RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
::osl::MutexGuard aGuard( m_aMutex );
if ( !_rxListener.is() )
throw NullPointerException();
m_aPropertyListeners.addListener( _rxListener );
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
void SAL_CALL PropertyHandler::removePropertyChangeListener( const Reference< XPropertyChangeListener >& _rxListener ) throw (RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
::osl::MutexGuard aGuard( m_aMutex );
m_aPropertyListeners.removeListener( _rxListener );
}
//--------------------------------------------------------------------
sal_Bool SAL_CALL PropertyHandler::suspend( sal_Bool /*_bSuspend*/ ) throw (RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
return sal_True;
}
//--------------------------------------------------------------------
IMPLEMENT_FORWARD_XCOMPONENT( PropertyHandler, PropertyHandler_Base )
//--------------------------------------------------------------------
void SAL_CALL PropertyHandler::disposing()
{
m_xComponent.clear();
m_aPropertyListeners.clear();
m_xTypeConverter.clear();
m_aSupportedProperties.realloc( 0 );
}
//--------------------------------------------------------------------
void PropertyHandler::firePropertyChange( const ::rtl::OUString& _rPropName, PropertyId _nPropId, const Any& _rOldValue, const Any& _rNewValue ) SAL_THROW(())
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
PropertyChangeEvent aEvent;
aEvent.Source = m_xComponent;
aEvent.PropertyHandle = _nPropId;
aEvent.PropertyName = _rPropName;
aEvent.OldValue = _rOldValue;
aEvent.NewValue = _rNewValue;
m_aPropertyListeners.notify( aEvent, &XPropertyChangeListener::propertyChange );
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
const Property* PropertyHandler::impl_getPropertyFromId_nothrow( PropertyId _nPropId ) const
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
const_cast< PropertyHandler* >( this )->getSupportedProperties();
const Property* pFound = ::std::find_if( m_aSupportedProperties.begin(), m_aSupportedProperties.end(),
FindPropertyByHandle( _nPropId )
);
if ( pFound != m_aSupportedProperties.end() )
return &(*pFound);
return NULL;
}
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
//--------------------------------------------------------------------
const Property& PropertyHandler::impl_getPropertyFromId_throw( PropertyId _nPropId ) const
{
const Property* pProperty = impl_getPropertyFromId_nothrow( _nPropId );
if ( !pProperty )
throw UnknownPropertyException();
return *pProperty;
}
//--------------------------------------------------------------------
const Property& PropertyHandler::impl_getPropertyFromName_throw( const ::rtl::OUString& _rPropertyName ) const
{
const_cast< PropertyHandler* >( this )->getSupportedProperties();
StlSyntaxSequence< Property >::const_iterator pFound = ::std::find_if( m_aSupportedProperties.begin(), m_aSupportedProperties.end(),
FindPropertyByName( _rPropertyName )
);
if ( pFound == m_aSupportedProperties.end() )
throw UnknownPropertyException();
return *pFound;
}
//--------------------------------------------------------------------
void PropertyHandler::implAddPropertyDescription( ::std::vector< Property >& _rProperties, const ::rtl::OUString& _rPropertyName, const Type& _rType, sal_Int16 _nAttribs ) const
{
_rProperties.push_back( Property(
_rPropertyName,
m_pInfoService->getPropertyId( _rPropertyName ),
_rType,
_nAttribs
) );
}
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
//------------------------------------------------------------------------
Window* PropertyHandler::impl_getDefaultDialogParent_nothrow() const
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
return PropertyHandlerHelper::getDialogParentWindow( m_aContext );
}
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
//------------------------------------------------------------------------
PropertyId PropertyHandler::impl_getPropertyId_throw( const ::rtl::OUString& _rPropertyName ) const
{
PropertyId nPropId = m_pInfoService->getPropertyId( _rPropertyName );
if ( nPropId == -1 )
throw UnknownPropertyException();
return nPropId;
}
//------------------------------------------------------------------------
void PropertyHandler::impl_setContextDocumentModified_nothrow() const
{
Reference< XModifiable > xModifiable( impl_getContextDocument_nothrow(), UNO_QUERY );
if ( xModifiable.is() )
xModifiable->setModified( sal_True );
}
//------------------------------------------------------------------------
bool PropertyHandler::impl_componentHasProperty_throw( const ::rtl::OUString& _rPropName ) const
{
return m_xComponentPropertyInfo.is() && m_xComponentPropertyInfo->hasPropertyByName( _rPropName );
}
//====================================================================
//= PropertyHandlerComponent
//====================================================================
//------------------------------------------------------------------------
PropertyHandlerComponent::PropertyHandlerComponent( const Reference< XComponentContext >& _rxContext )
:PropertyHandler( _rxContext )
{
}
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED 2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id 2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications 2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.4.88.18: some cleanup 2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends 2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:44 fs 1.4.88.8: #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 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED 2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:34 fs 1.4.88.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:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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 14:00:06 fs 1.4.88.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:30:34 +00:00
//--------------------------------------------------------------------
IMPLEMENT_FORWARD_XINTERFACE2( PropertyHandlerComponent, PropertyHandler, PropertyHandlerComponent_Base )
IMPLEMENT_FORWARD_XTYPEPROVIDER2( PropertyHandlerComponent, PropertyHandler, PropertyHandlerComponent_Base )
//--------------------------------------------------------------------
::sal_Bool SAL_CALL PropertyHandlerComponent::supportsService( const ::rtl::OUString& ServiceName ) throw (RuntimeException)
{
StlSyntaxSequence< ::rtl::OUString > aAllServices( getSupportedServiceNames() );
return ::std::find( aAllServices.begin(), aAllServices.end(), ServiceName ) != aAllServices.end();
}
//........................................................................
} // namespace pcr
//........................................................................