mir/libreoffice
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
01198b0d6eed32d8609466ef5c1bffe57f5fc503
libreoffice/extensions/source/propctrlr/propertyhandler.hxx

460 lines
24 KiB
C++
Raw Normal View History

INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
/*************************************************************************
*
INTEGRATION: CWS changefileheader (1.7.314); FILE MERGED 2008/04/01 15:15:20 thb 1.7.314.3: #i85898# Stripping all external header guards 2008/04/01 12:29:52 thb 1.7.314.2: #i85898# Stripping all external header guards 2008/03/31 12:31:53 rt 1.7.314.1: #i87441# Change license header to LPGL v3.
2008-04-11 10:18:11 +00:00
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
*
INTEGRATION: CWS changefileheader (1.7.314); FILE MERGED 2008/04/01 15:15:20 thb 1.7.314.3: #i85898# Stripping all external header guards 2008/04/01 12:29:52 thb 1.7.314.2: #i85898# Stripping all external header guards 2008/03/31 12:31:53 rt 1.7.314.1: #i87441# Change license header to LPGL v3.
2008-04-11 10:18:11 +00:00
* Copyright 2008 by Sun Microsystems, Inc.
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
*
INTEGRATION: CWS changefileheader (1.7.314); FILE MERGED 2008/04/01 15:15:20 thb 1.7.314.3: #i85898# Stripping all external header guards 2008/04/01 12:29:52 thb 1.7.314.2: #i85898# Stripping all external header guards 2008/03/31 12:31:53 rt 1.7.314.1: #i87441# Change license header to LPGL v3.
2008-04-11 10:18:11 +00:00
* OpenOffice.org - a multi-platform office productivity suite
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
*
INTEGRATION: CWS changefileheader (1.7.314); FILE MERGED 2008/04/01 15:15:20 thb 1.7.314.3: #i85898# Stripping all external header guards 2008/04/01 12:29:52 thb 1.7.314.2: #i85898# Stripping all external header guards 2008/03/31 12:31:53 rt 1.7.314.1: #i87441# Change license header to LPGL v3.
2008-04-11 10:18:11 +00:00
* $RCSfile: propertyhandler.hxx,v $
* $Revision: 1.8 $
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
*
INTEGRATION: CWS changefileheader (1.7.314); FILE MERGED 2008/04/01 15:15:20 thb 1.7.314.3: #i85898# Stripping all external header guards 2008/04/01 12:29:52 thb 1.7.314.2: #i85898# Stripping all external header guards 2008/03/31 12:31:53 rt 1.7.314.1: #i87441# Change license header to LPGL v3.
2008-04-11 10:18:11 +00:00
* This file is part of OpenOffice.org.
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
*
INTEGRATION: CWS changefileheader (1.7.314); FILE MERGED 2008/04/01 15:15:20 thb 1.7.314.3: #i85898# Stripping all external header guards 2008/04/01 12:29:52 thb 1.7.314.2: #i85898# Stripping all external header guards 2008/03/31 12:31:53 rt 1.7.314.1: #i87441# Change license header to LPGL v3.
2008-04-11 10:18:11 +00:00
* OpenOffice.org is free software: you can redistribute it and/or modify
* it under the terms of the GNU Lesser General Public License version 3
* only, as published by the Free Software Foundation.
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
*
INTEGRATION: CWS changefileheader (1.7.314); FILE MERGED 2008/04/01 15:15:20 thb 1.7.314.3: #i85898# Stripping all external header guards 2008/04/01 12:29:52 thb 1.7.314.2: #i85898# Stripping all external header guards 2008/03/31 12:31:53 rt 1.7.314.1: #i87441# Change license header to LPGL v3.
2008-04-11 10:18:11 +00:00
* OpenOffice.org is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Lesser General Public License version 3 for more details
* (a copy is included in the LICENSE file that accompanied this code).
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
*
INTEGRATION: CWS changefileheader (1.7.314); FILE MERGED 2008/04/01 15:15:20 thb 1.7.314.3: #i85898# Stripping all external header guards 2008/04/01 12:29:52 thb 1.7.314.2: #i85898# Stripping all external header guards 2008/03/31 12:31:53 rt 1.7.314.1: #i87441# Change license header to LPGL v3.
2008-04-11 10:18:11 +00:00
* You should have received a copy of the GNU Lesser General Public License
* version 3 along with OpenOffice.org. If not, see
* <http://www.openoffice.org/license.html>
* for a copy of the LGPLv3 License.
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
*
************************************************************************/
#ifndef EXTENSIONS_SOURCE_PROPCTRLR_PROPERTYHANDLER_HXX
#define EXTENSIONS_SOURCE_PROPCTRLR_PROPERTYHANDLER_HXX
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
#include "pcrcomponentcontext.hxx"
#include "pcrcommon.hxx"
#ifndef _EXTENSIONS_PROPCTRLR_MODULEPCR_HXX_
#include "modulepcr.hxx"
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
#endif
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
/** === begin UNO includes === **/
#include <com/sun/star/uno/XComponentContext.hpp>
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
#include <com/sun/star/beans/PropertyState.hpp>
#include <com/sun/star/beans/XPropertySet.hpp>
#include <com/sun/star/beans/Property.hpp>
#include <com/sun/star/script/XTypeConverter.hpp>
#include <com/sun/star/frame/XModel.hpp>
#include <com/sun/star/uno/Sequence.hxx>
#include <com/sun/star/uno/Any.hxx>
INTEGRATION: CWS eforms4 (1.2.16); FILE MERGED 2004/12/23 14:31:14 dvo 1.2.16.3: #i38666# remove PropertyHandler::changeTypeOfSupportedProperty (This function was introduced to deal with XSD type properties that had different types for different objects. This has now been fixed, so that the function is no longer necessary.) 2004/12/23 14:23:47 dvo 1.2.16.2: #i38666# use new property names for XSD types 2004/12/10 10:41:03 fs 1.2.16.1: #i36359# updateDependentProperties renamed to actuatingPropertyChanged, plus added a parameter indicating whether it's a real property change
2005-03-23 10:58:11 +00:00
#include <com/sun/star/util/Date.hpp>
#include <com/sun/star/util/Time.hpp>
#include <com/sun/star/util/DateTime.hpp>
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
#include <com/sun/star/lang/XMultiServiceFactory.hpp>
#include <com/sun/star/inspection/XPropertyHandler.hpp>
#include <com/sun/star/lang/XServiceInfo.hpp>
/** === end UNO includes === **/
#include <osl/interlck.h>
#include <cppuhelper/compbase1.hxx>
#include <cppuhelper/implbase1.hxx>
#include <comphelper/uno3.hxx>
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
#include <memory>
#include <vector>
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
namespace com { namespace sun { namespace star {
namespace inspection {
struct LineDescriptor;
class XPropertyControlFactory;
}
} } }
class Window;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
//........................................................................
namespace pcr
{
//........................................................................
typedef sal_Int32 PropertyId;
//====================================================================
//= PropertyHandler
//====================================================================
class OPropertyInfoService;
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
typedef ::cppu::WeakComponentImplHelper1 < ::com::sun::star::inspection::XPropertyHandler
> PropertyHandler_Base;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
/** the base class for property handlers
*/
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
class PropertyHandler : public PropertyHandler_Base
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
{
private:
/// cache for getSupportedProperties
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
mutable StlSyntaxSequence< ::com::sun::star::beans::Property >
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
m_aSupportedProperties;
mutable bool m_bSupportedPropertiesAreKnown;
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
/// helper which ensures that we can access resources as long as the instance lives
PcrClient m_aEnsureResAccess;
private:
/// the property listener which has been registered
PropertyChangeListeners m_aPropertyListeners;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
protected:
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
mutable ::osl::Mutex m_aMutex;
/// the context in which the instance was created
ComponentContext m_aContext;
/// the component we're inspecting
::com::sun::star::uno::Reference< ::com::sun::star::beans::XPropertySet > m_xComponent;
/// info about our component's properties
::com::sun::star::uno::Reference< ::com::sun::star::beans::XPropertySetInfo > m_xComponentPropertyInfo;
/// type converter, needed on various occasions
::com::sun::star::uno::Reference< ::com::sun::star::script::XTypeConverter > m_xTypeConverter;
/// access to property meta data
::std::auto_ptr< OPropertyInfoService > m_pInfoService;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
protected:
PropertyHandler(
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
const ::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext >& _rxContext
);
PropertyHandler(
const ::com::sun::star::uno::Reference< ::com::sun::star::lang::XMultiServiceFactory >& _rxLegacyFactory
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
);
~PropertyHandler();
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
// default implementations for XPropertyHandler
virtual void SAL_CALL inspect( const ::com::sun::star::uno::Reference< ::com::sun::star::uno::XInterface >& _rxIntrospectee ) throw (::com::sun::star::uno::RuntimeException, ::com::sun::star::lang::NullPointerException);
virtual ::com::sun::star::uno::Sequence< ::com::sun::star::beans::Property > SAL_CALL getSupportedProperties() throw (::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::uno::Sequence< ::rtl::OUString > SAL_CALL getSupersededProperties( ) throw (::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::uno::Sequence< ::rtl::OUString > SAL_CALL getActuatingProperties( ) throw (::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::uno::Any SAL_CALL convertToPropertyValue( const ::rtl::OUString& _rPropertyName, const ::com::sun::star::uno::Any& _rControlValue ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::uno::Any SAL_CALL convertToControlValue( const ::rtl::OUString& _rPropertyName, const ::com::sun::star::uno::Any& _rPropertyValue, const ::com::sun::star::uno::Type& _rControlValueType ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::beans::PropertyState SAL_CALL getPropertyState( const ::rtl::OUString& _rPropertyName ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
INTEGRATION: CWS dba204b (1.6.68); FILE MERGED 2006/07/06 14:52:30 fs 1.6.68.1: #i65159# describePropertyLine now returning a LineDescriptor, instead of taking an out parameter / some less warnings
2006-07-26 07:00:10 +00:00
virtual ::com::sun::star::inspection::LineDescriptor SAL_CALL describePropertyLine( const ::rtl::OUString& _rPropertyName, const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControlFactory >& _rxControlFactory ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::lang::NullPointerException, ::com::sun::star::uno::RuntimeException);
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
virtual ::sal_Bool SAL_CALL isComposable( const ::rtl::OUString& _rPropertyName ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::inspection::InteractiveSelectionResult SAL_CALL onInteractivePropertySelection( const ::rtl::OUString& _rPropertyName, sal_Bool _bPrimary, ::com::sun::star::uno::Any& _rData, const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XObjectInspectorUI >& _rxInspectorUI ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::lang::NullPointerException, ::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL actuatingPropertyChanged( const ::rtl::OUString& _rActuatingPropertyName, const ::com::sun::star::uno::Any& _rNewValue, const ::com::sun::star::uno::Any& _rOldValue, const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XObjectInspectorUI >& _rxInspectorUI, sal_Bool _bFirstTimeInit ) throw (::com::sun::star::lang::NullPointerException, ::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL addPropertyChangeListener( const ::com::sun::star::uno::Reference< ::com::sun::star::beans::XPropertyChangeListener >& _rxListener ) throw (::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL removePropertyChangeListener( const ::com::sun::star::uno::Reference< ::com::sun::star::beans::XPropertyChangeListener >& _rxListener ) throw (::com::sun::star::uno::RuntimeException);
virtual sal_Bool SAL_CALL suspend( sal_Bool _bSuspend ) throw (::com::sun::star::uno::RuntimeException);
// XComponent
DECLARE_XCOMPONENT()
virtual void SAL_CALL disposing();
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
// own overridables
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
virtual ::com::sun::star::uno::Sequence< ::com::sun::star::beans::Property >
SAL_CALL doDescribeSupportedProperties() const = 0;
/// called when XPropertyHandler::inspect has been called, and we thus have a new component to inspect
virtual void onNewComponent();
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
protected:
/** fires the change in a property value to our listener (if any)
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
@see addPropertyChangeListener
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
*/
void firePropertyChange( const ::rtl::OUString& _rPropName, PropertyId _nPropId,
const ::com::sun::star::uno::Any& _rOldValue, const ::com::sun::star::uno::Any& _rNewValue ) SAL_THROW(());
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
/** retrieves a window which can be used as parent for dialogs
*/
Window* impl_getDefaultDialogParent_nothrow() const;
/** retrieves the property id for a given property name
@throw com::sun::star::beans::UnknownPropertyException
if the property name is not known to our ->m_pInfoService
*/
PropertyId impl_getPropertyId_throw( const ::rtl::OUString& _rPropertyName ) const;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
//-------------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
// helper for implementing doDescribeSupportedProperties
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
/** adds a description for the given string property to the given property vector
Most probably to be called from within getSupportedProperties
*/
inline void addStringPropertyDescription(
::std::vector< ::com::sun::star::beans::Property >& _rProperties,
const ::rtl::OUString& _rPropertyName,
sal_Int16 _nAttribs = 0
) const;
/** adds a description for the given int32 property to the given property vector
*/
inline void addInt32PropertyDescription(
::std::vector< ::com::sun::star::beans::Property >& _rProperties,
const ::rtl::OUString& _rPropertyName,
sal_Int16 _nAttribs = 0
) const;
/** adds a description for the given int16 property to the given property vector
*/
inline void addInt16PropertyDescription(
::std::vector< ::com::sun::star::beans::Property >& _rProperties,
const ::rtl::OUString& _rPropertyName,
sal_Int16 _nAttribs = 0
) const;
/** adds a description for the given double property to the given property vector
*/
inline void addDoublePropertyDescription(
::std::vector< ::com::sun::star::beans::Property >& _rProperties,
const ::rtl::OUString& _rPropertyName,
sal_Int16 _nAttribs = 0
) const;
INTEGRATION: CWS eforms4 (1.2.16); FILE MERGED 2004/12/23 14:31:14 dvo 1.2.16.3: #i38666# remove PropertyHandler::changeTypeOfSupportedProperty (This function was introduced to deal with XSD type properties that had different types for different objects. This has now been fixed, so that the function is no longer necessary.) 2004/12/23 14:23:47 dvo 1.2.16.2: #i38666# use new property names for XSD types 2004/12/10 10:41:03 fs 1.2.16.1: #i36359# updateDependentProperties renamed to actuatingPropertyChanged, plus added a parameter indicating whether it's a real property change
2005-03-23 10:58:11 +00:00
/** adds a description for the given date property to the given property vector
*/
inline void addDatePropertyDescription(
::std::vector< ::com::sun::star::beans::Property >& _rProperties,
const ::rtl::OUString& _rPropertyName,
sal_Int16 _nAttribs = 0
) const;
/** adds a description for the given time property to the given property vector
*/
inline void addTimePropertyDescription(
::std::vector< ::com::sun::star::beans::Property >& _rProperties,
const ::rtl::OUString& _rPropertyName,
sal_Int16 _nAttribs = 0
) const;
/** adds a description for the given DateTime property to the given property vector
*/
inline void addDateTimePropertyDescription(
::std::vector< ::com::sun::star::beans::Property >& _rProperties,
const ::rtl::OUString& _rPropertyName,
sal_Int16 _nAttribs = 0
) const;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
/// adds a Property, given by name only, to a given vector of Properties
void implAddPropertyDescription(
::std::vector< ::com::sun::star::beans::Property >& _rProperties,
const ::rtl::OUString& _rPropertyName,
const ::com::sun::star::uno::Type& _rType,
sal_Int16 _nAttribs = 0
) const;
//-------------------------------------------------------------------------------
// helper for accessing and maintaining meta data about our supported properties
/** retrieves a property given by handle
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
@return
a pointer to the descriptor for the given properties, if it is one of our
supported properties, <NULL/> else.
@see doDescribeSupportedProperties
@see impl_getPropertyFromId_throw
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
*/
const ::com::sun::star::beans::Property*
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
impl_getPropertyFromId_nothrow( PropertyId _nPropId ) const;
/** retrieves a property given by handle
@throws UnknownPropertyException
if the handler does not support a property with the given handle
@seealso doDescribeSupportedProperties
@see impl_getPropertyFromId_nothrow
*/
const ::com::sun::star::beans::Property&
impl_getPropertyFromId_throw( PropertyId _nPropId ) const;
/** determines whether a given property id is part of our supported properties
@see getSupportedProperties
@see doDescribeSupportedProperties
*/
inline bool impl_isSupportedProperty_nothrow( PropertyId _nPropId ) const
{
return impl_getPropertyFromId_nothrow( _nPropId ) != NULL;
}
/** retrieves a property given by name
@throws UnknownPropertyException
if the handler does not support a property with the given name
@seealso doDescribeSupportedProperties
*/
const ::com::sun::star::beans::Property&
impl_getPropertyFromName_throw( const ::rtl::OUString& _rPropertyName ) const;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
/** get the name of a property given by handle
*/
inline ::rtl::OUString
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
impl_getPropertyNameFromId_nothrow( PropertyId _nPropId ) const;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
/** returns the value of the ContextDocument property in the ComponentContext which was used to create
this handler.
*/
inline ::com::sun::star::uno::Reference< ::com::sun::star::frame::XModel >
impl_getContextDocument_nothrow() const
{
return ::com::sun::star::uno::Reference< ::com::sun::star::frame::XModel >(
m_aContext.getContextValueByAsciiName( "ContextDocument" ), ::com::sun::star::uno::UNO_QUERY );
}
/** marks the context document as modified
@see impl_getContextDocument_nothrow
*/
void impl_setContextDocumentModified_nothrow() const;
/// determines whether our component has a given property
bool impl_componentHasProperty_throw( const ::rtl::OUString& _rPropName ) const;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
private:
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
PropertyHandler(); // never implemented
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
PropertyHandler( const PropertyHandler& ); // never implemented
PropertyHandler& operator=( const PropertyHandler& ); // never implemented
};
//--------------------------------------------------------------------
inline void PropertyHandler::addStringPropertyDescription( ::std::vector< ::com::sun::star::beans::Property >& _rProperties, const ::rtl::OUString& _rPropertyName, sal_Int16 _nAttribs ) const
{
implAddPropertyDescription( _rProperties, _rPropertyName, ::getCppuType( static_cast< ::rtl::OUString* >( NULL ) ), _nAttribs );
}
inline void PropertyHandler::addInt32PropertyDescription( ::std::vector< ::com::sun::star::beans::Property >& _rProperties, const ::rtl::OUString& _rPropertyName, sal_Int16 _nAttribs ) const
{
implAddPropertyDescription( _rProperties, _rPropertyName, ::getCppuType( static_cast< sal_Int32* >( NULL ) ), _nAttribs );
}
inline void PropertyHandler::addInt16PropertyDescription( ::std::vector< ::com::sun::star::beans::Property >& _rProperties, const ::rtl::OUString& _rPropertyName, sal_Int16 _nAttribs ) const
{
implAddPropertyDescription( _rProperties, _rPropertyName, ::getCppuType( static_cast< sal_Int16* >( NULL ) ), _nAttribs );
}
inline void PropertyHandler::addDoublePropertyDescription( ::std::vector< ::com::sun::star::beans::Property >& _rProperties, const ::rtl::OUString& _rPropertyName, sal_Int16 _nAttribs ) const
{
implAddPropertyDescription( _rProperties, _rPropertyName, ::getCppuType( static_cast< double* >( NULL ) ), _nAttribs );
}
INTEGRATION: CWS eforms4 (1.2.16); FILE MERGED 2004/12/23 14:31:14 dvo 1.2.16.3: #i38666# remove PropertyHandler::changeTypeOfSupportedProperty (This function was introduced to deal with XSD type properties that had different types for different objects. This has now been fixed, so that the function is no longer necessary.) 2004/12/23 14:23:47 dvo 1.2.16.2: #i38666# use new property names for XSD types 2004/12/10 10:41:03 fs 1.2.16.1: #i36359# updateDependentProperties renamed to actuatingPropertyChanged, plus added a parameter indicating whether it's a real property change
2005-03-23 10:58:11 +00:00
inline void PropertyHandler::addDatePropertyDescription( ::std::vector< ::com::sun::star::beans::Property >& _rProperties, const ::rtl::OUString& _rPropertyName, sal_Int16 _nAttribs ) const
{
implAddPropertyDescription( _rProperties, _rPropertyName, ::getCppuType( static_cast< com::sun::star::util::Date* >( NULL ) ), _nAttribs );
}
inline void PropertyHandler::addTimePropertyDescription( ::std::vector< ::com::sun::star::beans::Property >& _rProperties, const ::rtl::OUString& _rPropertyName, sal_Int16 _nAttribs ) const
{
implAddPropertyDescription( _rProperties, _rPropertyName, ::getCppuType( static_cast< com::sun::star::util::Time* >( NULL ) ), _nAttribs );
}
inline void PropertyHandler::addDateTimePropertyDescription( ::std::vector< ::com::sun::star::beans::Property >& _rProperties, const ::rtl::OUString& _rPropertyName, sal_Int16 _nAttribs ) const
{
implAddPropertyDescription( _rProperties, _rPropertyName, ::getCppuType( static_cast< com::sun::star::util::DateTime* >( NULL ) ), _nAttribs );
}
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
inline ::rtl::OUString PropertyHandler::impl_getPropertyNameFromId_nothrow( PropertyId _nPropId ) const
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
const ::com::sun::star::beans::Property* pProp = impl_getPropertyFromId_nothrow( _nPropId );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
return pProp ? pProp->Name : ::rtl::OUString();
}
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
//====================================================================
//= PropertyHandlerComponent
//====================================================================
typedef ::cppu::ImplHelper1 < ::com::sun::star::lang::XServiceInfo
> PropertyHandlerComponent_Base;
/** PropertyHandler implementation which additionally supports XServiceInfo
*/
class PropertyHandlerComponent :public PropertyHandler
,public PropertyHandlerComponent_Base
{
protected:
PropertyHandlerComponent(
const ::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext >& _rxContext
);
DECLARE_XINTERFACE()
DECLARE_XTYPEPROVIDER()
// XServiceInfo
virtual ::rtl::OUString SAL_CALL getImplementationName( ) throw (::com::sun::star::uno::RuntimeException) = 0;
virtual ::sal_Bool SAL_CALL supportsService( const ::rtl::OUString& ServiceName ) throw (::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::uno::Sequence< ::rtl::OUString > SAL_CALL getSupportedServiceNames( ) throw (::com::sun::star::uno::RuntimeException) = 0;
};
//====================================================================
//= HandlerComponentBase
//====================================================================
/** a PropertyHandlerComponent implementation which routes XServiceInfo::getImplementationName and
XServiceInfo::getSupportedServiceNames to static versions of those methods, which are part of
the derived class.
Additionally, a method <member>Create</member> is provided which takes a component context, and returns a new
instance of the derived class. This <member>Create</member> is used to register the implementation
of the derived class at the <type>PcrModule</type>.
Well, every time we're talking about derived class, we in fact mean the template argument of
<type>HandlerComponentBase</type>. But usually this equals your derived class:
<pre>
class MyHandler;
typedef HandlerComponentBase< MyHandler > MyHandler_Base;
class MyHandler : MyHandler_Base
{
...
public:
static ::rtl::OUString SAL_CALL getImplementationName_static( ) throw (::com::sun::star::uno::RuntimeException);
static ::com::sun::star::uno::Sequence< ::rtl::OUString > SAL_CALL getSupportedServiceNames_static( ) throw (::com::sun::star::uno::RuntimeException);
};
</pre>
*/
template < class HANDLER >
class HandlerComponentBase : public PropertyHandlerComponent
{
protected:
HandlerComponentBase( const ::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext >& _rxContext )
:PropertyHandlerComponent( _rxContext )
{
}
protected:
// XServiceInfo
virtual ::rtl::OUString SAL_CALL getImplementationName( ) throw (::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::uno::Sequence< ::rtl::OUString > SAL_CALL getSupportedServiceNames( ) throw (::com::sun::star::uno::RuntimeException);
static ::com::sun::star::uno::Reference< ::com::sun::star::uno::XInterface > SAL_CALL Create( const ::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext >& _rxContext );
public:
/** registers the implementation of HANDLER at the <type>PcrModule</type>
*/
static void registerImplementation();
};
//--------------------------------------------------------------------
template < class HANDLER >
::rtl::OUString SAL_CALL HandlerComponentBase< HANDLER >::getImplementationName( ) throw (::com::sun::star::uno::RuntimeException)
{
return HANDLER::getImplementationName_static();
#i10000# solaris compiler is more nitpicking ...
2006-03-17 08:47:23 +00:00
}
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
//--------------------------------------------------------------------
template < class HANDLER >
::com::sun::star::uno::Sequence< ::rtl::OUString > SAL_CALL HandlerComponentBase< HANDLER >::getSupportedServiceNames( ) throw (::com::sun::star::uno::RuntimeException)
{
return HANDLER::getSupportedServiceNames_static();
#i10000# solaris compiler is more nitpicking ...
2006-03-17 08:47:23 +00:00
}
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications 2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications 2005/10/31 13:45:59 fs 1.3.88.16: some cleanup 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking 2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:47 fs 1.3.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:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:54 fs 1.3.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:35 fs 1.3.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:15 fs 1.3.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.3.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.3.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:45 +00:00
//--------------------------------------------------------------------
template < class HANDLER >
void HandlerComponentBase< HANDLER >::registerImplementation()
{
PcrModule::getInstance().registerImplementation(
HANDLER::getImplementationName_static(),
HANDLER::getSupportedServiceNames_static(),
HANDLER::Create
);
}
//--------------------------------------------------------------------
template < class HANDLER >
::com::sun::star::uno::Reference< ::com::sun::star::uno::XInterface > SAL_CALL HandlerComponentBase< HANDLER >::Create( const ::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext >& _rxContext )
{
return *( new HANDLER( _rxContext ) );
}
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/07/22 10:37:29 fs 1.1.2.7: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:46 fs 1.1.2.6: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/21 11:24:19 fs 1.1.2.5: #i31762# support for inspecting multiple objects 2004/07/15 07:42:00 fs 1.1.2.4: #114856# cache supported properties 2004/07/12 14:29:22 fs 1.1.2.3: #114856# parts (interface for access to the UI of the property browser) outsourced to propbrowserui.hxx 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:44:28 fs 1.1.2.1: interface/base class for abstract property handlers, which are responsible for the complete handling for one or more properties
2004-11-16 11:11:43 +00:00
//........................................................................
} // namespace pcr
//........................................................................
#endif // EXTENSIONS_SOURCE_PROPCTRLR_PROPERTYHANDLER_HXX
Reference in New Issue Copy Permalink