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

457 lines
23 KiB
C++
Raw Normal View History

add modelines to .hxx files as well
2010-10-27 12:45:03 +01:00
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
re-base on ALv2 code. Change-Id: I6c145e984c885c7e06caa1c27bfb354ea49ad9ce
2012-06-21 14:30:25 +01:00
/*
* This file is part of the LibreOffice project.
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*
* This file incorporates work covered by the following license notice:
*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed
* with this work for additional information regarding copyright
* ownership. The ASF licenses this file to you under the Apache
* License, Version 2.0 (the "License"); you may not use this file
* except in compliance with the License. You may obtain a copy of
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
*/
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
fixincludeguards.sh: extensions Change-Id: If652bce4cf7621795b084bcbc0aa4c46dd903878
2014-04-18 20:41:29 +02:00
#ifndef INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_PROPERTYHANDLER_HXX
#define INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_PROPERTYHANDLER_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
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 "pcrcommon.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
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/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>
#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;
}
} } }
fdo#82577: Handle Window Put the VCL Window class in the vcl namespace. Avoids clash with the X11 Window typedef. Change-Id: Ib1beb7ab4ad75562a42aeb252732a073d25eff1a
2014-09-23 11:20:40 +02:00
namespace vcl { class Window; }
Remove visual noise from extensions Change-Id: I0397d0d0e5343b7ed192a790664b068ac6955bd3 Reviewed-on: https://gerrit.libreoffice.org/8259 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-25 18:36:00 +01:00
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
{
Remove visual noise from extensions Change-Id: I0397d0d0e5343b7ed192a790664b068ac6955bd3 Reviewed-on: https://gerrit.libreoffice.org/8259 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-25 18:36:00 +01:00
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
typedef sal_Int32 PropertyId;
Remove visual noise from extensions Change-Id: I0397d0d0e5343b7ed192a790664b068ac6955bd3 Reviewed-on: https://gerrit.libreoffice.org/8259 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-25 18:36:00 +01:00
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
Remove visual noise from extensions Change-Id: I0397d0d0e5343b7ed192a790664b068ac6955bd3 Reviewed-on: https://gerrit.libreoffice.org/8259 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-25 18:36:00 +01:00
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
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
fdo#46808, Convert a copy of ComponentContext to XComponentContext Looks like this extensions had a modified copy of comphelper::ComponentContext in it. Change-Id: I7e29aea4e6480a619f3148530fe6d784efe260e1
2013-06-03 15:34:00 +02:00
::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext > m_xContext;
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
/// 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
extensions: std::auto_ptr -> std::unique_ptr Change-Id: I2d9d2e145584013d8e94f5aea2ec7732452b240c
2014-09-30 12:26:40 +02:00
::std::unique_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
);
Explicitly mark overriding destructors as "virtual" It appears that the C++ standard allows overriding destructors to be marked "override," but at least some MSVC versions complain about it, so at least make sure such destructors are explicitly marked "virtual." Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
2014-04-01 19:18:35 +02:00
virtual ~PropertyHandler();
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
// default implementations for XPropertyHandler
Second batch of adding SAL_OVERRIDE to overriding function declarations ...mostly done with a rewriting Clang plugin, with just some manual tweaking necessary to fix poor macro usage. Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
2014-03-27 18:12:18 +01:00
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, std::exception) SAL_OVERRIDE;
virtual ::com::sun::star::uno::Sequence< ::com::sun::star::beans::Property > SAL_CALL getSupportedProperties() throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
virtual ::com::sun::star::uno::Sequence< OUString > SAL_CALL getSupersededProperties( ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
virtual ::com::sun::star::uno::Sequence< OUString > SAL_CALL getActuatingProperties( ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
virtual ::com::sun::star::uno::Any SAL_CALL convertToPropertyValue( const OUString& _rPropertyName, const ::com::sun::star::uno::Any& _rControlValue ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
virtual ::com::sun::star::uno::Any SAL_CALL convertToControlValue( const 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, std::exception) SAL_OVERRIDE;
virtual ::com::sun::star::beans::PropertyState SAL_CALL getPropertyState( const OUString& _rPropertyName ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
virtual ::com::sun::star::inspection::LineDescriptor SAL_CALL describePropertyLine( const 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, std::exception) SAL_OVERRIDE;
remove unnecessary scope qualifier from sal_Bool uses i.e. convert "::sal_Bool" to "sal_Bool" Change-Id: Ie5943aee4fee617bf2670655558927ed25b7e067
2014-04-03 13:52:06 +02:00
virtual sal_Bool SAL_CALL isComposable( const OUString& _rPropertyName ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
Second batch of adding SAL_OVERRIDE to overriding function declarations ...mostly done with a rewriting Clang plugin, with just some manual tweaking necessary to fix poor macro usage. Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
2014-03-27 18:12:18 +01:00
virtual ::com::sun::star::inspection::InteractiveSelectionResult SAL_CALL onInteractivePropertySelection( const 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, std::exception) SAL_OVERRIDE;
virtual void SAL_CALL actuatingPropertyChanged( const 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, std::exception) SAL_OVERRIDE;
coverity#706518 Uncaught exception Change-Id: I2db2ba69d7aac319fa9b446766729813c09d344f
2014-04-05 12:49:47 +01:00
virtual void SAL_CALL addPropertyChangeListener( const ::com::sun::star::uno::Reference< ::com::sun::star::beans::XPropertyChangeListener >& _rxListener ) throw (::com::sun::star::lang::NullPointerException, ::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
Second batch of adding SAL_OVERRIDE to overriding function declarations ...mostly done with a rewriting Clang plugin, with just some manual tweaking necessary to fix poor macro usage. Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
2014-03-27 18:12:18 +01:00
virtual void SAL_CALL removePropertyChangeListener( const ::com::sun::star::uno::Reference< ::com::sun::star::beans::XPropertyChangeListener >& _rxListener ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
virtual sal_Bool SAL_CALL suspend( sal_Bool _bSuspend ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
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
// XComponent
DECLARE_XCOMPONENT()
Second batch of adding SAL_OVERRIDE to overriding function declarations ...mostly done with a rewriting Clang plugin, with just some manual tweaking necessary to fix poor macro usage. Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
2014-03-27 18:12:18 +01:00
virtual void SAL_CALL disposing() SAL_OVERRIDE;
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
*/
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
void firePropertyChange( const OUString& _rPropName, PropertyId _nPropId,
extensions: remove SAL_THROW macro Change-Id: I12b5b46d31d5189adb21804a818ce591f2c19cbf
2014-06-05 08:15:03 +02:00
const ::com::sun::star::uno::Any& _rOldValue, const ::com::sun::star::uno::Any& _rNewValue );
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
/** retrieves a window which can be used as parent for dialogs
*/
fdo#82577: Handle Window Put the VCL Window class in the vcl namespace. Avoids clash with the X11 Window typedef. Change-Id: Ib1beb7ab4ad75562a42aeb252732a073d25eff1a
2014-09-23 11:20:40 +02:00
vcl::Window* impl_getDefaultDialogParent_nothrow() const;
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 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
*/
coverity#706514 Uncaught exception also coverity#706515 coverity#706516 coverity#706517 coverity#706528 coverity#706529 Change-Id: I5beb753d5cc8ed976b3c11319cc36415adebd1e6
2014-06-13 13:19:14 +01:00
PropertyId impl_getPropertyId_throwUnknownProperty( const OUString& _rPropertyName ) const;
/** retrieves the property id for a given property name
@throw com::sun::star::uno::RuntimeException
if the property name is not known to our ->m_pInfoService
*/
PropertyId impl_getPropertyId_throwRuntime( const OUString& _rPropertyName ) const;
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
coverity#706523 Uncaught exception Change-Id: I20515693bed76163433421f7fd05b319ed472a54
2014-04-05 12:43:01 +01:00
/** retrieves the property id for a given property name
@returns -1
if the property name is not known to our ->m_pInfoService
*/
PropertyId impl_getPropertyId_nothrow( const OUString& _rPropertyName ) const;
Remove visual noise from extensions Change-Id: I0397d0d0e5343b7ed192a790664b068ac6955bd3 Reviewed-on: https://gerrit.libreoffice.org/8259 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-25 18:36:00 +01: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,
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
const OUString& _rPropertyName,
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
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,
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
const OUString& _rPropertyName,
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
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,
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
const OUString& _rPropertyName,
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
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,
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
const OUString& _rPropertyName,
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
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,
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
const OUString& _rPropertyName,
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
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,
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
const OUString& _rPropertyName,
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
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,
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
const OUString& _rPropertyName,
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
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,
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
const OUString& _rPropertyName,
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::uno::Type& _rType,
sal_Int16 _nAttribs = 0
) const;
Remove visual noise from extensions Change-Id: I0397d0d0e5343b7ed192a790664b068ac6955bd3 Reviewed-on: https://gerrit.libreoffice.org/8259 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-25 18:36:00 +01:00
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
// 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&
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
impl_getPropertyFromName_throw( const 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
*/
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
inline 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 >(
fdo#46808, Convert a copy of ComponentContext to XComponentContext Looks like this extensions had a modified copy of comphelper::ComponentContext in it. Change-Id: I7e29aea4e6480a619f3148530fe6d784efe260e1
2013-06-03 15:34:00 +02:00
m_xContext->getValueByName( "ContextDocument" ), ::com::sun::star::uno::UNO_QUERY );
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
}
/** marks the context document as modified
@see impl_getContextDocument_nothrow
*/
void impl_setContextDocumentModified_nothrow() const;
/// determines whether our component has a given property
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
bool impl_componentHasProperty_throw( const 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
CWS-TOOLING: integrate CWS dba32b 2009-06-03 14:58:08 +0200 fs r272581 : #i102439# 2009-05-29 13:56:18 +0200 fs r272456 : remove the sub form when the 'add subform' setting changes from <true/> to <false/>, not only its controls 2009-05-29 13:19:27 +0200 fs r272454 : display '(Default)' instead of an empty string when a control has the default font 2009-05-28 20:49:18 +0200 fs r272428 : #i98162# getFirstSelectedValue: do not return reference to a temporary 2009-05-27 15:30:22 +0200 msc r272353 : #102303# 2009-05-26 13:03:06 +0200 fs r272295 : spelling 2009-05-26 12:59:54 +0200 fs r272294 : merge m48 version to get latest cygwin related fixes 2009-05-25 14:02:06 +0200 fs r272239 : remove references to local files, needed for debugging sessions only 2009-05-25 14:01:16 +0200 fs r272238 : #i102021# ensure members such as bNumberFormat are initialized before actually returning them 2009-05-25 13:10:20 +0200 fs r272236 : #i10000# reset ENABLE_EVOAB2 2009-05-22 06:44:45 +0200 oj r272167 : #i99104# add import handler for calc-sett 2009-05-22 06:42:27 +0200 oj r272166 : #i99104# impl NullDate as member 2009-05-22 06:36:22 +0200 oj r272165 : #i99104# handle nulldate from parent model 2009-05-22 06:33:13 +0200 oj r272164 : #i99104# export and import calculation-settings and nulldate 2009-05-22 06:27:50 +0200 oj r272163 : #i99104# export and import calculation-settings and nulldate 2009-05-20 13:29:58 +0200 oj r272118 : #i99911# handle invalid name 2009-05-20 13:28:49 +0200 oj r272117 : #i101261# handle different rowsets 2009-05-20 11:29:55 +0200 msc r272111 : #i100000# 2009-05-20 11:28:27 +0200 msc r272110 : merge in change from dba32a 2009-05-20 11:27:38 +0200 msc r272109 : #102082# CTRL + C does not work 2009-05-20 09:43:36 +0200 oj r272106 : clean up includes 2009-05-20 09:32:15 +0200 oj r272105 : #i99060# merge error resovled now VERTICAL_ALIGN is in both stmt 2009-05-20 08:37:21 +0200 msc r272104 : add workaround for issue #102010# 2009-05-20 08:10:12 +0200 oj r272103 : #i99104# use numberformatkey 2009-05-20 08:07:02 +0200 oj r272102 : #i99104# use column info from rowset 2009-05-20 08:04:43 +0200 oj r272101 : #i102032# use a special column type where prec and scale are the values currently set at the column 2009-05-20 08:03:04 +0200 oj r272100 : #i102032# correct type info, we have to use SQL defined type names 2009-05-19 10:27:02 +0200 oj r272061 : #i99104# export null-date 2009-05-19 08:26:53 +0200 oj r272056 : #i99104# export null-date 2009-05-18 13:15:10 +0200 msc r272014 : add issue #102019# 2009-05-18 11:33:07 +0200 msc r272005 : add issue #102019# 2009-05-18 08:59:45 +0200 msc r271996 : add workaroud for issue #102010# 2009-05-15 10:21:24 +0200 msc r271929 : #101944# 2009-05-11 21:18:30 +0200 fs r271792 : #i99914# 2009-05-08 13:52:06 +0200 oj r271715 : #i96423# remember column span 2009-05-08 11:26:19 +0200 oj r271708 : #i98605# impl new scale mode 2009-05-08 10:33:35 +0200 fs r271706 : SendUserCall: only call into the shape notification routine for UserCall types where this is necessary (performance issue) 2009-05-07 20:52:44 +0200 fs r271698 : outsource ShapeProperty from shapepropertynotifier.hxx 2009-05-07 20:43:33 +0200 fs r271697 : #i99056# use notifyShapePropertyChange, instead of getShapePropertyChangeNotifier - the latter throws if no shape exists, yet 2009-05-07 20:33:58 +0200 fs r271696 : #i99056# +notifyShapePropertyChange: allow notifying chages without checking whether there actually already exists an SvxShape 2009-05-07 16:22:15 +0200 fs r271679 : #i10000# cygwin needs quotes around the classpath 2009-05-07 16:21:37 +0200 fs r271678 : #i10000# cygwin needs quotes around the classpath 2009-05-07 16:01:11 +0200 oj r271677 : #i99914# notify parent handler 2009-05-07 15:54:54 +0200 fs r271676 : #i10000# cygwin needs some quoting 2009-05-07 14:49:48 +0200 oj r271672 : #i99277# quote alias name 2009-05-07 14:48:12 +0200 oj r271671 : #i92538# add ~ in front of type 2009-05-07 14:37:13 +0200 oj r271667 : #i99118# change type from char to varchar 2009-05-07 14:36:23 +0200 oj r271666 : #i99118# clear dest columns when changing to create new table 2009-05-07 13:35:32 +0200 oj r271657 : #i94467# handle type 0 as double as well 2009-05-07 13:20:49 +0200 oj r271655 : i99743# setNull when varchar is no text 2009-05-07 12:58:06 +0200 fs r271651 : initialize the SdrObject's property change notifier after the ctor, if necessary 2009-05-07 11:47:18 +0200 fs r271647 : #i10000# 2009-05-07 10:57:16 +0200 fs r271639 : OPropertyBrowserController::propertyChange: care for the current property state, too, and properly forward it to the UI 2009-05-07 10:18:14 +0200 fs r271636 : onNewComponent: do not ask the map for grid columns, it will throw 2009-05-07 10:09:55 +0200 fs r271634 : #i101623# 2009-05-07 09:53:44 +0200 fs r271631 : #i101622# 2009-05-06 21:55:53 +0200 fs r271615 : #i10000# 2009-05-06 21:10:42 +0200 fs r271611 : #i10000# 2009-05-06 13:11:48 +0200 fs r271583 : #i10000# 2009-05-05 22:29:31 +0200 fs r271559 : proper assertion message 2009-05-05 22:29:03 +0200 fs r271558 : diagnostics 2009-05-05 22:16:16 +0200 fs r271557 : #i10000# 2009-05-05 13:50:32 +0200 fs r271513 : #i10000# 2009-05-05 10:21:50 +0200 fs r271503 : #i10000# 2009-05-05 09:30:26 +0200 fs r271501 : why did those survive the rebase -C step? 2009-05-05 09:18:12 +0200 fs r271500 : #i10000# 2009-05-04 17:08:17 +0200 fs r271475 : CWS-TOOLING: rebase CWS dba32b to trunk@271427 (milestone: DEV300:m47) 2009-05-04 14:51:26 +0200 fs r271456 : line ends 2009-04-30 15:55:27 +0200 fs r271418 : NewURL -> PublicConnectionURL 2009-04-22 21:18:34 +0200 fs r271141 : #i100944# 2009-04-22 09:12:26 +0200 oj r271071 : #i101261# little code change 2009-04-22 09:11:43 +0200 oj r271070 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:11:25 +0200 oj r271069 : #i101261# new grabage container for nodes 2009-04-22 09:11:02 +0200 oj r271068 : #i101261# new grabage container for nodes 2009-04-22 09:10:44 +0200 oj r271067 : #i101261# new grabage container for nodes 2009-04-22 09:10:21 +0200 oj r271066 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:08:24 +0200 oj r271065 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:07:25 +0200 oj r271064 : #i101261# only ask for parameters which aren't set before 2009-04-22 08:49:07 +0200 oj r271062 : #i77501# preview only when needed 2009-04-22 08:45:44 +0200 oj r271061 : #i101261# new prop max rows 2009-04-22 08:44:18 +0200 oj r271060 : #i101261# create dataprovider earlier to avoid the wrong legend in chart 2009-04-22 08:42:48 +0200 oj r271059 : #i101261# handle parameter 2009-04-17 21:00:23 +0200 fs r270954 : #i98350# 2009-04-17 13:54:19 +0200 fs r270942 : #i99565# 2009-04-17 13:51:34 +0200 fs r270940 : #i101153# only localize the (potentially) localizable properties when there really is support at the control model 2009-04-17 11:43:14 +0200 fs r270932 : removed superfluous include 2009-04-17 10:10:15 +0200 fs r270926 : #i10000# 2009-04-17 10:02:36 +0200 fs r270925 : #i10000# 2009-04-17 09:15:13 +0200 fs r270918 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 09:14:56 +0200 fs r270917 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 09:13:25 +0200 fs r270915 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 08:30:34 +0200 fs r270914 : removed unotools/servicehelper.hxx in favour of the (duplicated) comphelper/servicehelper.hxx 2009-04-16 21:05:25 +0200 fs r270903 : #i10000# 2009-04-16 20:43:43 +0200 fs r270902 : #i99056# shape notification outsourced to the SdrObject, this is what all other shape implementations (which only aggregate an SvxShape) have access to, too 2009-04-16 15:57:36 +0200 fs r270891 : #i99056# make SetUnoControlModel virtual 2009-04-16 15:44:02 +0200 fs r270890 : #i99056# let the ScShapeObj notify changes in its Anchor property 2009-04-16 15:36:47 +0200 fs r270889 : #i99056# enable the sheet anchor type property, too 2009-04-16 15:33:45 +0200 fs r270887 : #i99056# shape notification outsourced to the SdrObject, this is what all other shape implementations (which only aggregate an SvxShape) have access to, too 2009-04-15 14:53:13 +0200 fs r270844 : #i10000# 2009-04-15 13:08:29 +0200 fs r270836 : #i10000# 2009-04-15 12:28:14 +0200 fs r270832 : #i10000# 2009-04-15 10:59:14 +0200 fs r270827 : #i10000# 2009-04-15 09:41:08 +0200 oj r270823 : fix issues found with findbugs and pmd 2009-04-14 21:08:04 +0200 fs r270808 : #i99056# implement SheetAnchorType - now the only thing missing to enable it is the proper notification when it is modified 2009-04-14 17:09:00 +0200 fs r270799 : #i99056# implement XServiceInfo for the ScShapeObj 2009-04-14 17:07:55 +0200 fs r270798 : #i99056# implement TextAnchorType, partially implement SheetAnchorType 2009-04-14 15:54:05 +0200 fs r270786 : #i99056# SwXShape: notify changes of the AnchorType property 2009-04-14 15:47:32 +0200 fs r270785 : #i99056# deliver shapepropertynotifier.hxx 2009-04-14 15:46:54 +0200 fs r270784 : diagnostics 2009-04-14 15:08:28 +0200 fs r270781 : #i99056# outsourced the SvxShape's property change notification code into a dedicated class 2009-04-14 14:41:09 +0200 fs r270773 : #i99056# outsourced the SvxShape's property change notification code into a dedicated class 2009-04-14 14:37:23 +0200 fs r270772 : in dtor, remove the properties from the temporary component context 2009-04-14 14:36:34 +0200 fs r270771 : getWeakUnoShape made const 2009-04-14 12:23:08 +0200 oj r270757 : #i101064# add missing braces 2009-04-14 12:21:25 +0200 oj r270756 : #i101065# add braces for gcc 4.3.2 2009-04-14 12:17:45 +0200 oj r270755 : #i101059# add dep for manifest 2009-04-09 12:06:58 +0200 oj r270686 : #i93100# use OptimalSize from control to get height 2009-04-08 09:56:55 +0200 oj r270619 : #i92537# handle calculations in the select columns as well 2009-04-08 09:30:39 +0200 oj r270615 : #i96657# throw error message when the key doesn't have any columns 2009-04-07 12:08:26 +0200 oj r270592 : #i77501# impl preview of the executed report 2009-04-07 12:01:56 +0200 oj r270591 : #i77501# impl preview of the executed report 2009-04-07 11:41:03 +0200 oj r270590 : #i77501# impl preview of the executed report 2009-04-07 11:39:32 +0200 oj r270589 : #i77501# impl preview of the executed report 2009-04-07 11:29:25 +0200 oj r270588 : #i77501# convert dos to unix lineends 2009-04-07 11:28:23 +0200 oj r270587 : #i77501# impl preview of the executed report 2009-04-07 11:16:50 +0200 oj r270586 : #i77501# impl preview of the executed report 2009-04-07 11:16:00 +0200 oj r270585 : #i77501# impl preview of the executed report 2009-04-07 11:15:44 +0200 oj r270584 : #i77501# impl preview of the executed report 2009-04-07 11:15:28 +0200 oj r270583 : #i77501# impl preview of the executed report 2009-04-07 11:15:04 +0200 oj r270582 : #i77501# impl preview of the executed report 2009-04-06 15:38:54 +0200 fs r270559 : merge changes from CWS dba32a herein 2009-04-03 15:56:16 +0200 fs r270494 : ImpSvMEdit::Resize: do multiple iterations, if necessary 2009-04-03 14:35:49 +0200 fs r270487 : #i10000# 2009-04-03 13:17:16 +0200 fs r270476 : #i99056# display geometry information for controls, too 2009-04-03 13:16:37 +0200 fs r270475 : #i99056# better ordering of the geometry properties 2009-04-03 13:16:07 +0200 fs r270473 : #i99056# now that SvxShape supports property change listeners, forward add/remove requests to it 2009-04-03 13:13:18 +0200 fs r270472 : #i99056# at SvxShape, allow for PropertyChangeListeners for Size/Position 2009-04-03 09:29:27 +0200 oj r270456 : #i94571# use correct prop name 2009-04-03 09:14:54 +0200 fs r270451 : merge changes from CWS dba32a herein 2009-04-02 17:00:51 +0200 fs r270424 : better diagnostics 2009-04-02 16:35:19 +0200 fs r270421 : diagnostics 2009-04-02 16:34:50 +0200 fs r270420 : #i99056# mxUnoShape not accessible anymore, use impl_setUnoShape instead 2009-04-02 16:32:48 +0200 fs r270419 : #i99056# make getUnoShape cheaper: keep the pointer to the SvxShape all the time, so there's no need to ask for it in getUnoShape. As a consequence, we will later be able to use the pointer in scenarious where performance (potentially) matters 2009-04-02 16:31:13 +0200 fs r270417 : merge changes from CWS dba32a herein 2009-04-02 16:23:16 +0200 fs r270414 : merge changes from CWS dba32a herein 2009-04-02 14:10:35 +0200 fs r270405 : #i10000# 2009-04-02 14:06:26 +0200 fs r270404 : merge changes from CWS dba32a herein 2009-04-02 14:03:03 +0200 fs r270401 : #i10000# 2009-04-02 13:58:13 +0200 fs r270400 : #i10000# 2009-04-02 12:59:44 +0200 fs r270397 : merge changes from CWS dba32a herein 2009-04-02 12:46:30 +0200 fs r270396 : #i99056# let the form page maintain a mapping between control models and control shapes 2009-04-02 12:44:07 +0200 fs r270395 : merge changes from CWS dba32a herein 2009-04-02 12:42:06 +0200 fs r270394 : merge changes from CWS dba32a herein 2009-04-02 12:35:20 +0200 fs r270393 : #i10000# precompiled header 2009-04-02 12:05:31 +0200 fs r270392 : merge changes from CWS dba32a herein 2009-04-02 12:00:42 +0200 fs r270391 : merge changes from CWS dba32a herein 2009-04-02 11:47:26 +0200 fs r270390 : merge changes from CWS dba32a herein 2009-04-02 11:39:15 +0200 oj r270389 : #i94467# foxpro impl several new types 2009-04-02 11:35:58 +0200 fs r270387 : merge changes from CWS dba32a herein 2009-04-01 14:10:51 +0200 fs r270329 : merge changes from CWS dba32a herein 2009-03-31 17:29:50 +0200 fs r270290 : merge changes from CWS dba32a herein 2009-03-30 14:53:56 +0200 fs r270233 : #i100417# don't set grid column widths to 0, but to <void/> 2009-03-30 12:31:03 +0200 oj r270213 : #i100552# wrong orb used 2009-03-30 12:19:20 +0200 oj r270212 : #i98303# convertlike corrected to sal_Unicode 2009-03-30 11:58:25 +0200 fs r270210 : merge changes from CWS dba32a herein 2009-03-30 11:38:16 +0200 oj r270205 : remove duplicate code from merge 2009-03-30 11:02:27 +0200 fs r270202 : merge changes from CWS dba32a herein 2009-03-30 11:02:19 +0200 fs r270201 : merge changes from CWS dba32a herein 2009-03-30 10:31:26 +0200 oj r270200 : #i100665# only throw exception and do not drop table 2009-03-30 09:36:24 +0200 fs r270195 : assertion text 2009-03-28 20:21:58 +0100 fs r270187 : #ii10000# 2009-03-28 20:19:54 +0100 fs r270186 : removed unused help ids 2009-03-28 20:19:40 +0100 fs r270185 : removed unused help ids 2009-03-28 20:19:10 +0100 fs r270184 : #i100237# +DefaultState/XReset 2009-03-28 00:29:29 +0100 fs r270177 : CWS-TOOLING: rebase CWS dba32b to trunk@270033 (milestone: DEV300:m45) 2009-03-27 22:56:46 +0100 fs r270173 : #i100237# DEFAULT_CHECKED -> DEFAULT_STATE 2009-03-27 22:55:52 +0100 fs r270172 : #i100237# DefaultState property for buttons, enabled only when Toggle=Yes 2009-03-27 22:54:15 +0100 fs r270171 : #i100237# DEFAULT_CHECKED -> DEFAULT_STATE 2009-03-27 22:53:54 +0100 fs r270170 : #i100237# introduce a DefaultState property for buttons, which implies buttongs supporting XReset, which needed some refactoring 2009-03-27 13:31:41 +0100 fs r270152 : ignore output paths 2009-03-27 11:23:44 +0100 fs r270139 : tuned behavior with respect to invalid keys/values 2009-03-27 09:57:14 +0100 fs r270136 : don't allow Double.NaN 2009-03-27 09:56:16 +0100 fs r270135 : talk about Double.NaN 2009-03-26 12:14:30 +0100 fs r270067 : removed unused parameter 2009-03-26 12:14:02 +0100 fs r270066 : removed widening conversion when checking keys 2009-03-26 09:17:34 +0100 fs r270053 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-26 09:17:11 +0100 fs r270052 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-26 09:16:49 +0100 fs r270051 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-25 21:55:20 +0100 fs r270044 : #i100541# properly calculat bNeedScrollBox 2009-03-25 12:56:17 +0100 fs r270019 : renamed the previously introduced error condition 2009-03-25 12:11:48 +0100 fs r270015 : #i100095# when the error messages contain non-trivial details (SQLState/ErrorCode), then always display the 'Details' button 2009-03-25 12:10:05 +0100 fs r270012 : renamed the previously introduced error condition 2009-03-25 12:01:04 +0100 fs r270011 : #i100095# when no address book (or respective profile) can be found, then use a dedicated ErrorCondition 2009-03-25 10:29:07 +0100 fs r270003 : add missing localization 2009-03-25 10:23:12 +0100 fs r270001 : in preparation of #i1000095#: rework the error handling, allow using css.sdb.ErrorCondition values, plus allow propagating the nsresult 2009-03-25 10:21:55 +0100 fs r270000 : in preparation of #i1000095#: rework the error handling, allow using css.sdb.ErrorCondition values, plus allow propagating the nsresult 2009-03-20 23:05:38 +0100 fs r269829 : XMap::getSize removed 2009-03-20 23:05:19 +0100 fs r269828 : changes as suggested by sb 2009-03-20 23:04:56 +0100 fs r269827 : enhanced documentation 2009-03-20 15:31:40 +0100 fs r269815 : changes as suggested by sb 2009-03-20 13:23:52 +0100 oj r269804 : #i92538# correct the zorder that fixedtext is infront of control 2009-03-20 12:59:38 +0100 oj r269801 : #i94571# paraadjust now supports BLOCK 2009-03-20 12:58:11 +0100 oj r269800 : #i94571# export style with data style 2009-03-20 12:57:05 +0100 oj r269799 : #i94571# text align is now paraadjust 2009-03-20 12:37:02 +0100 fs r269797 : enum keys only accepted if they have the exact type, not if they have *any* enum type 2009-03-20 12:28:31 +0100 fs r269794 : some changes requested by sb 2009-03-20 08:52:47 +0100 fs r269780 : doc 2009-03-20 07:37:31 +0100 oj r269779 : #i99913# only notifiy when values are different 2009-03-20 07:36:58 +0100 oj r269778 : #i99913# add undoenv as listener at the dataprovider 2009-03-19 22:52:52 +0100 fs r269771 : added comment 2009-03-19 22:40:06 +0100 fs r269770 : +testEnumeration 2009-03-19 22:39:41 +0100 fs r269769 : implemented enumeration, getKeySet, and getValues. Should be finished now. 2009-03-19 14:01:01 +0100 oj r269743 : #i99913# reset the modified state when selecting an object 2009-03-19 12:19:54 +0100 lla r269739 : #i72390# cleanups 2009-03-19 09:25:27 +0100 fs r269727 : #i10000# 2009-03-18 23:37:02 +0100 fs r269708 : extended checks for value type acceptance 2009-03-18 23:36:41 +0100 fs r269707 : fixed value type checks 2009-03-18 14:59:56 +0100 fs r269678 : initial complex test case for the new css.container.Map implementation 2009-03-18 14:59:24 +0100 fs r269677 : verifyExpectedException moved to base class (in complexlib), and renamed to assureException for consistency 2009-03-18 14:58:35 +0100 fs r269676 : removed unused imports 2009-03-18 14:58:03 +0100 fs r269675 : first implementation of the new css.container.Map service (not completed, yet) 2009-03-18 14:57:17 +0100 fs r269674 : base class for UNO components, freeing you from some repeating work 2009-03-18 14:55:53 +0100 fs r269672 : +assureException: call a given method with given parameters on a given object, ensure that a given exception is thrown by the method implementation 2009-03-18 14:54:58 +0100 fs r269671 : +getComponentContext 2009-03-18 14:54:00 +0100 fs r269670 : isEmpty returns a boolean, not a long 2009-03-18 14:14:43 +0100 oj r269663 : #i99743# now text also supports null 2009-03-18 13:54:14 +0100 oj r269660 : #i99223# remove check for 2 params 2009-03-18 13:33:35 +0100 oj r269659 : #i99060# replace text::ParagraphVertAlign with style::VerticalAlignment 2009-03-18 13:32:18 +0100 oj r269658 : #i99060# don't set void property when void isn't allowed 2009-03-18 13:31:11 +0100 oj r269657 : #i99060# handle vertical alignment 2009-03-18 13:28:28 +0100 oj r269656 : #i99060# remove unused elements from sytle 2009-03-18 09:35:42 +0100 lla r269639 : #i72390# cleanups 2009-03-18 09:31:20 +0100 lla r269638 : #i72390# add ButtonList 2009-03-18 09:30:46 +0100 lla r269637 : #i72390# renamed interface 2009-03-18 09:30:15 +0100 lla r269636 : #i72390# use ButtonList instead of ImageList 2009-03-18 09:29:05 +0100 lla r269635 : #i72390# new ButtonList, cleanups 2009-03-18 09:26:34 +0100 lla r269634 : #i72390# cleanups 2009-03-17 12:21:20 +0100 oj r269590 : #i99222# remove assertion 2009-03-17 12:17:22 +0100 oj r269589 : #i98605# impl scale mode 2009-03-17 12:10:42 +0100 oj r269588 : #i98605# impl scale mode 2009-03-17 11:40:15 +0100 oj r269584 : #i96944# doesn't create equation for shapes 2009-03-17 11:33:16 +0100 oj r269583 : #i96423# switch calc from float to long 2009-03-16 15:19:18 +0100 fs r269550 : #i41930# enable zoom for embedded/outplace documents 2009-03-16 14:25:54 +0100 oj r269542 : #i93734# remove ContextSensitive 2009-03-16 14:21:58 +0100 oj r269541 : #i99274# page header before group header 2009-03-16 14:18:23 +0100 oj r269539 : #i99110# fix value type 2009-03-16 14:14:16 +0100 fs r269537 : line ends 2009-03-16 14:11:06 +0100 fs r269535 : line ends 2009-03-16 14:08:34 +0100 fs r269534 : #i100087# (provided my np): allow for polymorphic types with more than one parameter 2009-03-16 12:30:31 +0100 oj r269521 : compile error 2009-03-16 12:19:12 +0100 oj r269519 : compile error 2009-03-16 10:39:28 +0100 oj r269511 : compile error under linux with swap 2009-03-13 10:33:04 +0100 oj r269462 : CWS-TOOLING: rebase CWS dba32b to trunk@269297 (milestone: DEV300:m43) 2009-03-12 14:37:25 +0100 fs r269416 : interface SequenceOutputStreamTest is unneeded, and pollutes the namespace here :) 2009-03-12 14:35:07 +0100 fs r269414 : not needed 2009-03-12 14:34:15 +0100 fs r269413 : preparation for multiple tests in this module 2009-03-12 14:33:02 +0100 fs r269412 : ShowTargets was moved from module integration.forms to module complexlib 2009-03-12 14:32:48 +0100 fs r269411 : helper class for projects containing multiple complex test cases (and following a certain structure) 2009-03-12 14:00:14 +0100 fs r269407 : proper module after the move 2009-03-12 13:59:10 +0100 fs r269406 : superseded by ../makefile.mk 2009-03-12 13:47:38 +0100 fs r269403 : not needed anymore 2009-03-12 13:45:46 +0100 fs r269402 : moved, in preparation of adding more test cases here, with a common infrastructure 2009-03-12 13:45:07 +0100 fs r269401 : moved from ../ 2009-03-12 13:43:59 +0100 fs r269400 : moved to ./comphelper, in preparation of adding more test cases here, with a common infrastructure 2009-03-12 13:29:47 +0100 oj r269396 : #i99914# set parent on dataprovider 2009-03-12 13:10:35 +0100 oj r269393 : #i99832# check thrown exception and show error 2009-03-12 13:08:10 +0100 fs r269392 : reorganizing tests 2009-03-12 12:52:55 +0100 oj r269390 : #i99118# convert formatkey in numberformat 2009-03-12 12:34:53 +0100 fs r269388 : new API tests 2009-03-12 12:29:05 +0100 fs r269386 : Map not yet committed 2009-03-12 12:28:36 +0100 fs r269385 : oops, forgot the SequenceInputStream during the previous refactoring 2009-03-12 12:12:39 +0100 oj r269384 : #i99104# set HasCategories prop 2009-03-12 12:12:08 +0100 oj r269383 : #i99104# check HasCategories even for internal dataprovider 2009-03-12 12:10:40 +0100 oj r269382 : #i99104# set HasCategories prop 2009-03-12 10:51:49 +0100 fs r269373 : #i10000# exception specifications 2009-03-12 10:49:18 +0100 fs r269372 : #i10000# exception specifications 2009-03-12 10:44:02 +0100 fs r269371 : #i10000# exception specifications 2009-03-12 10:30:55 +0100 fs r269368 : refactored the UNO service registration in this module, using the helper classes provided by comphelper itself, so you have less effort when extending the list of to-be-registered components 2009-03-12 10:30:37 +0100 fs r269367 : module-local includes 2009-03-12 07:05:54 +0100 oj r269357 : #i99104# database dataprovider doesn't need dataranges and diagramdata 2009-03-11 10:58:28 +0100 oj r269306 : #i99911# check if name of the report is a valid file name 2009-03-11 10:03:23 +0100 oj r269299 : #i99666# the report is new when the HierarchicalDocumentName is empty 2009-03-10 11:32:45 +0100 oj r269258 : #i99221# use fallback for language 2009-03-10 10:48:40 +0100 oj r269255 : #i99433# now use OStringBuffer 2009-03-10 10:36:21 +0100 fs r269252 : initial version of (X)Map 2009-03-10 09:52:23 +0100 oj r269246 : #i99433# now use OStringBuffer 2009-03-10 08:56:13 +0100 oj r269240 : #i99655# patch applied 2009-03-09 07:35:33 +0100 lla r269058 : #i10000# wrong variable assignment fixed 2009-03-06 17:20:40 +0100 fs r269030 : some explicit defaults 2009-03-06 17:20:30 +0100 fs r269029 : #i98600# 2009-03-06 14:40:34 +0100 fs r269009 : #i87692# during reload, prevent the document being modified just because of some control content changes ... 2009-03-06 12:52:20 +0100 lla r268997 : #i10000# ambigous problem with FontWeight fixed 2009-03-06 11:39:32 +0100 fs r268989 : #i10000# (approved by pl): use --without-t1-library configure option 2009-03-06 10:55:43 +0100 fs r268986 : #i99953# depends on xmlscript module now 2009-03-06 10:54:04 +0100 fs r268985 : #i99953# also adjust the event names found in dialogs embedded in the forms 2009-03-06 09:53:41 +0100 fs r268977 : #i10000# 2009-03-06 09:30:41 +0100 lla r268973 : #i10000# merge problems 2009-03-05 17:52:34 +0100 fs r268932 : #i98593# for sub components which are actually controlled by a DocumentDefinition (aka XComponentSupplier aka XCommandProcessor), close them by executing the 'close' command, not by suspending/closing the controller (which cannot be intercepted) 2009-03-05 11:41:56 +0100 fs r268889 : default the drop down line count for list/combo boxes to 20 2009-03-05 11:39:10 +0100 fs r268887 : do not display empty error messages 2009-03-02 10:13:57 +0100 lla r268639 : #i91541# CWS rebase m41 to m42 2009-03-02 09:06:27 +0100 lla r268635 : #i10000# add ';' to strings 2009-02-26 11:18:00 +0100 fs r268492 : reportdesign depends on REPORTBUILDER, not REPORTDESIGN 2009-02-26 10:11:38 +0100 lla r268489 : CWS-TOOLING: rebase CWS dba32b to trunk@268395 (milestone: DEV300:m42) 2009-02-26 09:04:11 +0100 lla r268488 : CWS-TOOLING: rebase CWS dba32b to trunk@268395 (milestone: DEV300:m42) 2009-02-24 12:09:13 +0100 lla r268392 : #i91541# #i91542# cleanups 2009-02-24 08:08:06 +0100 lla r268382 : merge all dba32a changes into dba32b 2009-02-24 07:14:55 +0100 lla r268381 : merge all dba32a changes into dba32b 2009-02-23 21:44:28 +0100 fs r268377 : oops ... don't tamper with m_aListSourceValues at the end of loadData 2009-02-23 20:57:05 +0100 fs r268376 : #i98162# don't hold the values as strings, but as ORowSetValue, this way preserving their type, and being agnostic to different result/rowset implementations doing different to-string-conversations 2009-02-23 20:55:44 +0100 fs r268375 : getObject: throwFunctionNotSupportedException, instead of silently returning NULL 2009-02-23 20:55:20 +0100 fs r268374 : #i98162# some more supported types 2009-02-23 20:54:43 +0100 fs r268373 : #i98162# +operator != 2009-02-20 09:35:39 +0100 fs r268306 : #i99422# for a font, display the font name, the style, and the size 2009-02-20 09:33:45 +0100 fs r268305 : #i99422# in the property browser, FONT supersedes CHARFONTNAME: the aggregated FormComponentHandler displays them more nicely now 2009-02-19 16:12:06 +0100 fs r268293 : #i99372# recognize DataType::FLOAT as numeric 2009-02-19 15:43:12 +0100 fs r268291 : #i99415# 2009-02-19 15:40:15 +0100 fs r268290 : #i99242# lcl_firstFocussableControl: take disabled controls into account 2009-02-19 15:34:36 +0100 fs r268289 : #i99396# properly decode the base name of the URL when using it as title 2009-02-19 15:19:05 +0100 fs r268287 : #i98247#
2009-06-05 09:47:55 +00:00
/** determines the default measure unit for the document in which our component lives
*/
sal_Int16 impl_getDocumentMeasurementUnit_throw() 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:
loplugin:deletedspecial Change-Id: I55b827c4f20c57fcb18f8d6b54e3fdc168baed3f
2015-02-07 12:13:54 +01:00
PropertyHandler( const PropertyHandler& ) SAL_DELETED_FUNCTION;
PropertyHandler& operator=( const PropertyHandler& ) SAL_DELETED_FUNCTION;
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
};
Remove visual noise from extensions Change-Id: I0397d0d0e5343b7ed192a790664b068ac6955bd3 Reviewed-on: https://gerrit.libreoffice.org/8259 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-25 18:36:00 +01:00
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
inline void PropertyHandler::addStringPropertyDescription( ::std::vector< ::com::sun::star::beans::Property >& _rProperties, const OUString& _rPropertyName, sal_Int16 _nAttribs ) 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
{
Prefer cppu::UnoType<T>::get() to ::getCppuType((T*)0) part10 Change-Id: I67acda35fa127547dcea0cd18c9dc16db7c00294
2014-05-11 10:09:04 +02:00
implAddPropertyDescription( _rProperties, _rPropertyName, ::cppu::UnoType<OUString>::get(), _nAttribs );
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
}
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
inline void PropertyHandler::addInt32PropertyDescription( ::std::vector< ::com::sun::star::beans::Property >& _rProperties, const OUString& _rPropertyName, sal_Int16 _nAttribs ) 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
{
Prefer cppu::UnoType<T>::get() to ::getCppuType((T*)0) part10 Change-Id: I67acda35fa127547dcea0cd18c9dc16db7c00294
2014-05-11 10:09:04 +02:00
implAddPropertyDescription( _rProperties, _rPropertyName, ::cppu::UnoType<sal_Int32>::get(), _nAttribs );
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
}
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
inline void PropertyHandler::addInt16PropertyDescription( ::std::vector< ::com::sun::star::beans::Property >& _rProperties, const OUString& _rPropertyName, sal_Int16 _nAttribs ) 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
{
Prefer cppu::UnoType<T>::get() to ::getCppuType((T*)0) part10 Change-Id: I67acda35fa127547dcea0cd18c9dc16db7c00294
2014-05-11 10:09:04 +02:00
implAddPropertyDescription( _rProperties, _rPropertyName, ::cppu::UnoType<sal_Int16>::get(), _nAttribs );
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
}
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
inline void PropertyHandler::addDoublePropertyDescription( ::std::vector< ::com::sun::star::beans::Property >& _rProperties, const OUString& _rPropertyName, sal_Int16 _nAttribs ) 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
{
Prefer cppu::UnoType<T>::get() to ::getCppuType((T*)0) part10 Change-Id: I67acda35fa127547dcea0cd18c9dc16db7c00294
2014-05-11 10:09:04 +02:00
implAddPropertyDescription( _rProperties, _rPropertyName, ::cppu::UnoType<double>::get(), _nAttribs );
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
}
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
inline void PropertyHandler::addDatePropertyDescription( ::std::vector< ::com::sun::star::beans::Property >& _rProperties, const OUString& _rPropertyName, sal_Int16 _nAttribs ) 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
{
Prefer cppu::UnoType<T>::get() to ::getCppuType((T*)0) part10 Change-Id: I67acda35fa127547dcea0cd18c9dc16db7c00294
2014-05-11 10:09:04 +02:00
implAddPropertyDescription( _rProperties, _rPropertyName, ::cppu::UnoType<com::sun::star::util::Date>::get(), _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
}
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
inline void PropertyHandler::addTimePropertyDescription( ::std::vector< ::com::sun::star::beans::Property >& _rProperties, const OUString& _rPropertyName, sal_Int16 _nAttribs ) 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
{
Prefer cppu::UnoType<T>::get() to ::getCppuType((T*)0) part10 Change-Id: I67acda35fa127547dcea0cd18c9dc16db7c00294
2014-05-11 10:09:04 +02:00
implAddPropertyDescription( _rProperties, _rPropertyName, ::cppu::UnoType<com::sun::star::util::Time>::get(), _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
}
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
inline void PropertyHandler::addDateTimePropertyDescription( ::std::vector< ::com::sun::star::beans::Property >& _rProperties, const OUString& _rPropertyName, sal_Int16 _nAttribs ) 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
{
Prefer cppu::UnoType<T>::get() to ::getCppuType((T*)0) part10 Change-Id: I67acda35fa127547dcea0cd18c9dc16db7c00294
2014-05-11 10:09:04 +02:00
implAddPropertyDescription( _rProperties, _rPropertyName, ::cppu::UnoType<com::sun::star::util::DateTime>::get(), _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
}
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
inline 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 );
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
return pProp ? pProp->Name : OUString();
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
}
Remove visual noise from extensions Change-Id: I0397d0d0e5343b7ed192a790664b068ac6955bd3 Reviewed-on: https://gerrit.libreoffice.org/8259 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-25 18:36:00 +01: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
//= PropertyHandlerComponent
Remove visual noise from extensions Change-Id: I0397d0d0e5343b7ed192a790664b068ac6955bd3 Reviewed-on: https://gerrit.libreoffice.org/8259 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-25 18:36:00 +01: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
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
Second batch of adding SAL_OVERRIDE to overriding function declarations ...mostly done with a rewriting Clang plugin, with just some manual tweaking necessary to fix poor macro usage. Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
2014-03-27 18:12:18 +01:00
virtual OUString SAL_CALL getImplementationName( ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE = 0;
remove unnecessary scope qualifier from sal_Bool uses i.e. convert "::sal_Bool" to "sal_Bool" Change-Id: Ie5943aee4fee617bf2670655558927ed25b7e067
2014-04-03 13:52:06 +02:00
virtual sal_Bool SAL_CALL supportsService( const OUString& ServiceName ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
Second batch of adding SAL_OVERRIDE to overriding function declarations ...mostly done with a rewriting Clang plugin, with just some manual tweaking necessary to fix poor macro usage. Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
2014-03-27 18:12:18 +01:00
virtual ::com::sun::star::uno::Sequence< OUString > SAL_CALL getSupportedServiceNames( ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE = 0;
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
};
Remove visual noise from extensions Change-Id: I0397d0d0e5343b7ed192a790664b068ac6955bd3 Reviewed-on: https://gerrit.libreoffice.org/8259 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-25 18:36:00 +01: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
//= HandlerComponentBase
Remove visual noise from extensions Change-Id: I0397d0d0e5343b7ed192a790664b068ac6955bd3 Reviewed-on: https://gerrit.libreoffice.org/8259 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-25 18:36:00 +01: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
/** 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:
mass removal of rtl:: prefixes for O(U)String* Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk have kept them, in order not to break external API (the automatic using declaration is LO-internal). Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
2013-04-07 12:06:47 +02:00
static OUString SAL_CALL getImplementationName_static( ) throw (::com::sun::star::uno::RuntimeException);
static ::com::sun::star::uno::Sequence< OUString > SAL_CALL getSupportedServiceNames_static( ) throw (::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
};
</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
Second batch of adding SAL_OVERRIDE to overriding function declarations ...mostly done with a rewriting Clang plugin, with just some manual tweaking necessary to fix poor macro usage. Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
2014-03-27 18:12:18 +01:00
virtual OUString SAL_CALL getImplementationName( ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
virtual ::com::sun::star::uno::Sequence< OUString > SAL_CALL getSupportedServiceNames( ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
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
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();
};
Remove visual noise from extensions Change-Id: I0397d0d0e5343b7ed192a790664b068ac6955bd3 Reviewed-on: https://gerrit.libreoffice.org/8259 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-25 18:36:00 +01: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 >
cppuhelper: retrofit std::exception into overriding exception specs Change-Id: I56e32131b7991ee9948ce46765632eb823d463b3
2014-02-25 21:31:58 +01:00
OUString SAL_CALL HandlerComponentBase< HANDLER >::getImplementationName( ) throw (::com::sun::star::uno::RuntimeException, std::exception)
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 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
Remove visual noise from extensions Change-Id: I0397d0d0e5343b7ed192a790664b068ac6955bd3 Reviewed-on: https://gerrit.libreoffice.org/8259 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-25 18:36:00 +01: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 >
cppuhelper: retrofit std::exception into overriding exception specs Change-Id: I56e32131b7991ee9948ce46765632eb823d463b3
2014-02-25 21:31:58 +01:00
::com::sun::star::uno::Sequence< OUString > SAL_CALL HandlerComponentBase< HANDLER >::getSupportedServiceNames( ) throw (::com::sun::star::uno::RuntimeException, std::exception)
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 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
Remove visual noise from extensions Change-Id: I0397d0d0e5343b7ed192a790664b068ac6955bd3 Reviewed-on: https://gerrit.libreoffice.org/8259 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-25 18:36:00 +01: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
);
}
Remove visual noise from extensions Change-Id: I0397d0d0e5343b7ed192a790664b068ac6955bd3 Reviewed-on: https://gerrit.libreoffice.org/8259 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-25 18:36:00 +01: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::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 ) );
}
Remove visual noise from extensions Change-Id: I0397d0d0e5343b7ed192a790664b068ac6955bd3 Reviewed-on: https://gerrit.libreoffice.org/8259 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-25 18:36:00 +01:00
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
Remove visual noise from extensions Change-Id: I0397d0d0e5343b7ed192a790664b068ac6955bd3 Reviewed-on: https://gerrit.libreoffice.org/8259 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2014-02-25 18:36:00 +01:00
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
fixincludeguards.sh: extensions Change-Id: If652bce4cf7621795b084bcbc0aa4c46dd903878
2014-04-18 20:41:29 +02:00
#endif // INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_PROPERTYHANDLER_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
add modelines to .hxx files as well
2010-10-27 12:45:03 +01:00
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
Reference in New Issue Copy Permalink