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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

147 lines
8.0 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 pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
fixincludeguards.sh: extensions Change-Id: If652bce4cf7621795b084bcbc0aa4c46dd903878
2014-04-18 20:41:29 +02:00
#ifndef INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_GENERICPROPERTYHANDLER_HXX
#define INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_GENERICPROPERTYHANDLER_HXX
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
#include "propertyhandler.hxx"
#include "pcrcommontypes.hxx"
#include "pcrcommon.hxx"
#include <com/sun/star/beans/XPropertyState.hpp>
#include <com/sun/star/lang/XServiceInfo.hpp>
#include <com/sun/star/beans/XIntrospectionAccess.hpp>
tdf#88206 replace cppu::WeakImplHelper* etc. with the variadic variants in extensions. Change-Id: I45e9dc5769150181df88791b3f748002ca713c02 Reviewed-on: https://gerrit.libreoffice.org/17517 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
2015-08-04 17:52:31 +09:00
#include <cppuhelper/compbase.hxx>
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
#include <cppuhelper/interfacecontainer.hxx>
#include <rtl/ref.hxx>
#include <map>
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.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +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 pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
C++11 remove std::binary_function bases from functors std::binary_function is deprecated since C++11 and removed in C++17 90% done with regexp magic. removed obsolete <functional> includes. The std::binary_function base class was used by deprecated std::bind2nd, this was solved in individual commits. The members first_argument_type and second_argument_type were used in chart2/source/controller/dialogs/DataBrowserModel.cxx: DataBrowserModel::implColumnLess and are inlined in this commit. Change-Id: I60ded60a8d4afd59e15ac15a58e18d2498c9be5a Reviewed-on: https://gerrit.libreoffice.org/39659 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-07-02 17:10:53 +02:00
struct TypeLess
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
{
com::sun::star->css in extensions/ Change-Id: I64af9f5ae444e1f7bc6c0e8c29df383a9531dba9
2015-09-30 11:48:44 +02:00
bool operator()( const css::uno::Type& _rLHS, const css::uno::Type& _rRHS ) const
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
{
return _rLHS.getTypeName() < _rRHS.getTypeName();
}
};
class IPropertyEnumRepresentation;
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.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
//= GenericPropertyHandler
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
com::sun::star->css in extensions/ Change-Id: I64af9f5ae444e1f7bc6c0e8c29df383a9531dba9
2015-09-30 11:48:44 +02:00
typedef ::cppu::WeakComponentImplHelper < css::inspection::XPropertyHandler
, css::lang::XServiceInfo
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
> GenericPropertyHandler_Base;
loplugin:finalclasses in filter,extensions Change-Id: I2822b8c5a91feaf47466356c01728d32a85bbae9 Reviewed-on: https://gerrit.libreoffice.org/44190 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-11-02 09:42:24 +02:00
class GenericPropertyHandler final : public GenericPropertyHandler_Base
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
{
mutable ::osl::Mutex m_aMutex;
/// the service factory for creating services
com::sun::star->css in extensions/ Change-Id: I64af9f5ae444e1f7bc6c0e8c29df383a9531dba9
2015-09-30 11:48:44 +02:00
css::uno::Reference< css::uno::XComponentContext > m_xContext;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
/// need this to keep alive as long as m_xComponent lives
com::sun::star->css in extensions/ Change-Id: I64af9f5ae444e1f7bc6c0e8c29df383a9531dba9
2015-09-30 11:48:44 +02:00
css::uno::Reference< css::beans::XIntrospectionAccess > m_xComponentIntrospectionAccess;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
/// the properties of the object we're handling
com::sun::star->css in extensions/ Change-Id: I64af9f5ae444e1f7bc6c0e8c29df383a9531dba9
2015-09-30 11:48:44 +02:00
css::uno::Reference< css::beans::XPropertySet > m_xComponent;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
/// cached interface of ->m_xComponent
com::sun::star->css in extensions/ Change-Id: I64af9f5ae444e1f7bc6c0e8c29df383a9531dba9
2015-09-30 11:48:44 +02:00
css::uno::Reference< css::beans::XPropertyState > m_xPropertyState;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
/// type converter, needed on various occasions
com::sun::star->css in extensions/ Change-Id: I64af9f5ae444e1f7bc6c0e8c29df383a9531dba9
2015-09-30 11:48:44 +02:00
css::uno::Reference< css::script::XTypeConverter > m_xTypeConverter;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
/// cache of our supported properties
PropertyMap m_aProperties;
/// property change listeners
InterfaceContainer2 with vector instead of Sequence create an InterfaceContainer2 class to replace InterfaceContainer. It uses a std::vector instead of a Sequence for the mutable listener list, which provides far better performance. Switch all our internal use-sites to the new class. Change-Id: I6b56cfa511ded2395faa22e68fab3b2f16c3cb88
2016-01-19 19:45:45 +02:00
::comphelper::OInterfaceContainerHelper2 m_aPropertyListeners;
Drop :: prefix from std in [de]*/ Change-Id: I3247894fe022dce7f0aa351bd85fefcd7c545dd4 Reviewed-on: https://gerrit.libreoffice.org/34377 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com>
2017-02-17 19:06:24 +02:00
std::map< css::uno::Type, ::rtl::Reference< IPropertyEnumRepresentation >, TypeLess >
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
m_aEnumConverters;
/// has ->m_aProperties been initialized?
bool m_bPropertyMapInitialized : 1;
public:
// XServiceInfo - static versions
New loplugin:dynexcspec: Add @throws documentation, extensions Change-Id: Ia44f7b0a162d269bf38133575f986efd62eb6d52
2017-01-19 17:57:50 +01:00
/// @throws css::uno::RuntimeException
No need to keep these whitelisted functions decorated with SAL_CALL The only effect SAL_CALL effectively has on LO-internal code is to change non- static member functions from __thiscall to __cdecl in MSVC (where all other functions are __cdecl by default, anyway). (For 3rd-party code, it could be argued that SAL_CALL is useful on function declarations in the URE stable interface other than non-static member functions, too, in case 3rd-party code uses a compiler switch to change the default calling convention to something other than __cdecl. But loplugin:salcall exempts the URE stable interface, anyway.) One could argue that SAL_CALL, even if today it effectively only affects non- static member functions in MSVC, could be extended in the future to affect more functions on more platforms. However, the current code would already not support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c "loplugin:salcall fix functions" changed FrameControl_createInstance in UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even though its address (in ctl_component_getFacrory, in the same file) is passed to cppuhelper::createSingleFactory as an argument of type cppu::ComponentInstantiation, which is a pointer to SAL_CALL function. Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6 Reviewed-on: https://gerrit.libreoffice.org/46436 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-14 08:45:02 +01:00
static OUString getImplementationName_static( );
New loplugin:dynexcspec: Add @throws documentation, extensions Change-Id: Ia44f7b0a162d269bf38133575f986efd62eb6d52
2017-01-19 17:57:50 +01:00
/// @throws css::uno::RuntimeException
No need to keep these whitelisted functions decorated with SAL_CALL The only effect SAL_CALL effectively has on LO-internal code is to change non- static member functions from __thiscall to __cdecl in MSVC (where all other functions are __cdecl by default, anyway). (For 3rd-party code, it could be argued that SAL_CALL is useful on function declarations in the URE stable interface other than non-static member functions, too, in case 3rd-party code uses a compiler switch to change the default calling convention to something other than __cdecl. But loplugin:salcall exempts the URE stable interface, anyway.) One could argue that SAL_CALL, even if today it effectively only affects non- static member functions in MSVC, could be extended in the future to affect more functions on more platforms. However, the current code would already not support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c "loplugin:salcall fix functions" changed FrameControl_createInstance in UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even though its address (in ctl_component_getFacrory, in the same file) is passed to cppuhelper::createSingleFactory as an argument of type cppu::ComponentInstantiation, which is a pointer to SAL_CALL function. Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6 Reviewed-on: https://gerrit.libreoffice.org/46436 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-14 08:45:02 +01:00
static css::uno::Sequence< OUString > getSupportedServiceNames_static( );
static css::uno::Reference< css::uno::XInterface > Create( const css::uno::Reference< css::uno::XComponentContext >& _rxContext );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
loplugin:finalclasses in filter,extensions Change-Id: I2822b8c5a91feaf47466356c01728d32a85bbae9 Reviewed-on: https://gerrit.libreoffice.org/44190 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-11-02 09:42:24 +02:00
private:
cppcheck:noExplicitConstructor Change-Id: I2b68ba9e8caf7971efbba094ef060e72541bdccf Reviewed-on: https://gerrit.libreoffice.org/19426 Reviewed-by: Noel Grandin <noelgrandin@gmail.com> Tested-by: Noel Grandin <noelgrandin@gmail.com>
2015-10-18 07:53:51 +02:00
explicit GenericPropertyHandler(
com::sun::star->css in extensions/ Change-Id: I64af9f5ae444e1f7bc6c0e8c29df383a9531dba9
2015-09-30 11:48:44 +02:00
const css::uno::Reference< css::uno::XComponentContext >& _rxContext
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
);
loplugin:override: No more need for the "MSVC dtor override" workaround The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark overriding destructors as 'virtual'" appears to no longer be a problem with MSVC 2013. (The little change in the rewriting code of compilerplugins/clang/override.cxx was necessary to prevent an endless loop when adding "override" to OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager(); in chart2/source/inc/LifeTime.hxx, getting stuck in the leading OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.) Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
2016-09-13 13:09:01 +02:00
virtual ~GenericPropertyHandler() override;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
// XPropertyHandler overridables
Remove dynamic exception specifications ...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html> "Dynamic Exception Specifications" for details. Most changes have been done automatically by the rewriting loplugin:dynexcspec (after enabling the rewriting mode, to be committed shortly). The way it only removes exception specs from declarations if it also sees a definition, it identified some dead declarations-w/o-definitions (that have been removed manually) and some cases where a definition appeared in multiple include files (which have also been cleaned up manually). There's also been cases of macro paramters (that were used to abstract over exception specs) that have become unused now (and been removed). Furthermore, some code needed to be cleaned up manually (avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no configurations available that would actually build that code. Missing @throws documentation has not been applied in such manual clean-up. Change-Id: I3408691256c9b0c12bc5332de976743626e13960 Reviewed-on: https://gerrit.libreoffice.org/33574 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-01-26 12:28:58 +01:00
virtual void SAL_CALL inspect( const css::uno::Reference< css::uno::XInterface >& _rxIntrospectee ) override;
virtual css::uno::Any SAL_CALL getPropertyValue( const OUString& _rPropertyName ) override;
virtual void SAL_CALL setPropertyValue( const OUString& _rPropertyName, const css::uno::Any& _rValue ) override;
virtual css::uno::Any SAL_CALL convertToPropertyValue( const OUString& _rPropertyName, const css::uno::Any& _rControlValue ) override;
virtual css::uno::Any SAL_CALL convertToControlValue( const OUString& _rPropertyName, const css::uno::Any& _rPropertyValue, const css::uno::Type& _rControlValueType ) override;
virtual css::beans::PropertyState SAL_CALL getPropertyState( const OUString& _rPropertyName ) override;
virtual void SAL_CALL addPropertyChangeListener( const css::uno::Reference< css::beans::XPropertyChangeListener >& _rxListener ) override;
virtual void SAL_CALL removePropertyChangeListener( const css::uno::Reference< css::beans::XPropertyChangeListener >& _rxListener ) override;
com::sun::star->css in extensions/ Change-Id: I64af9f5ae444e1f7bc6c0e8c29df383a9531dba9
2015-09-30 11:48:44 +02:00
virtual css::uno::Sequence< css::beans::Property >
Remove dynamic exception specifications ...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html> "Dynamic Exception Specifications" for details. Most changes have been done automatically by the rewriting loplugin:dynexcspec (after enabling the rewriting mode, to be committed shortly). The way it only removes exception specs from declarations if it also sees a definition, it identified some dead declarations-w/o-definitions (that have been removed manually) and some cases where a definition appeared in multiple include files (which have also been cleaned up manually). There's also been cases of macro paramters (that were used to abstract over exception specs) that have become unused now (and been removed). Furthermore, some code needed to be cleaned up manually (avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no configurations available that would actually build that code. Missing @throws documentation has not been applied in such manual clean-up. Change-Id: I3408691256c9b0c12bc5332de976743626e13960 Reviewed-on: https://gerrit.libreoffice.org/33574 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-01-26 12:28:58 +01:00
SAL_CALL getSupportedProperties() override;
com::sun::star->css in extensions/ Change-Id: I64af9f5ae444e1f7bc6c0e8c29df383a9531dba9
2015-09-30 11:48:44 +02:00
virtual css::uno::Sequence< OUString >
Remove dynamic exception specifications ...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html> "Dynamic Exception Specifications" for details. Most changes have been done automatically by the rewriting loplugin:dynexcspec (after enabling the rewriting mode, to be committed shortly). The way it only removes exception specs from declarations if it also sees a definition, it identified some dead declarations-w/o-definitions (that have been removed manually) and some cases where a definition appeared in multiple include files (which have also been cleaned up manually). There's also been cases of macro paramters (that were used to abstract over exception specs) that have become unused now (and been removed). Furthermore, some code needed to be cleaned up manually (avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no configurations available that would actually build that code. Missing @throws documentation has not been applied in such manual clean-up. Change-Id: I3408691256c9b0c12bc5332de976743626e13960 Reviewed-on: https://gerrit.libreoffice.org/33574 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-01-26 12:28:58 +01:00
SAL_CALL getSupersededProperties() override;
virtual css::uno::Sequence< OUString > SAL_CALL getActuatingProperties() override;
virtual css::inspection::LineDescriptor SAL_CALL describePropertyLine( const OUString& _rPropertyName, const css::uno::Reference< css::inspection::XPropertyControlFactory >& _rxControlFactory ) override;
virtual sal_Bool SAL_CALL isComposable( const OUString& _rPropertyName ) override;
com::sun::star->css in extensions/ Change-Id: I64af9f5ae444e1f7bc6c0e8c29df383a9531dba9
2015-09-30 11:48:44 +02:00
virtual css::inspection::InteractiveSelectionResult
Remove dynamic exception specifications ...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html> "Dynamic Exception Specifications" for details. Most changes have been done automatically by the rewriting loplugin:dynexcspec (after enabling the rewriting mode, to be committed shortly). The way it only removes exception specs from declarations if it also sees a definition, it identified some dead declarations-w/o-definitions (that have been removed manually) and some cases where a definition appeared in multiple include files (which have also been cleaned up manually). There's also been cases of macro paramters (that were used to abstract over exception specs) that have become unused now (and been removed). Furthermore, some code needed to be cleaned up manually (avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no configurations available that would actually build that code. Missing @throws documentation has not been applied in such manual clean-up. Change-Id: I3408691256c9b0c12bc5332de976743626e13960 Reviewed-on: https://gerrit.libreoffice.org/33574 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-01-26 12:28:58 +01:00
SAL_CALL onInteractivePropertySelection( const OUString& _rPropertyName, sal_Bool _bPrimary, css::uno::Any& _rData, const css::uno::Reference< css::inspection::XObjectInspectorUI >& _rxInspectorUI ) override;
virtual void SAL_CALL actuatingPropertyChanged( const OUString& _rActuatingPropertyName, const css::uno::Any& _rNewValue, const css::uno::Any& _rOldValue, const css::uno::Reference< css::inspection::XObjectInspectorUI >& _rxInspectorUI, sal_Bool _bFirstTimeInit ) override;
virtual sal_Bool SAL_CALL suspend( sal_Bool _bSuspend ) override;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
// XComponent
INTEGRATION: CWS wae4extensions (1.3.230); FILE MERGED 2007/09/27 07:18:25 fs 1.3.230.1: #i81612# warning-free code
2008-01-14 13:59:13 +00:00
DECLARE_XCOMPONENT()
Replace "SAL_OVERRIDE" with "override" in LIBO_INTERNAL_ONLY code Change-Id: I2ea407acd763ef2d7dae2d3b8f32525523ac8274
2015-10-12 16:04:04 +02:00
virtual void SAL_CALL disposing() override;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
// XServiceInfo
Remove dynamic exception specifications ...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html> "Dynamic Exception Specifications" for details. Most changes have been done automatically by the rewriting loplugin:dynexcspec (after enabling the rewriting mode, to be committed shortly). The way it only removes exception specs from declarations if it also sees a definition, it identified some dead declarations-w/o-definitions (that have been removed manually) and some cases where a definition appeared in multiple include files (which have also been cleaned up manually). There's also been cases of macro paramters (that were used to abstract over exception specs) that have become unused now (and been removed). Furthermore, some code needed to be cleaned up manually (avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no configurations available that would actually build that code. Missing @throws documentation has not been applied in such manual clean-up. Change-Id: I3408691256c9b0c12bc5332de976743626e13960 Reviewed-on: https://gerrit.libreoffice.org/33574 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-01-26 12:28:58 +01:00
virtual OUString SAL_CALL getImplementationName( ) override;
virtual sal_Bool SAL_CALL supportsService( const OUString& ServiceName ) override;
virtual css::uno::Sequence< OUString > SAL_CALL getSupportedServiceNames( ) override;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
/** ensures that ->m_aProperties is initialized
@precond
our mutex is locked
*/
void impl_ensurePropertyMap();
/** retrieves the enum converter for the given ENUM type
*/
::rtl::Reference< IPropertyEnumRepresentation >
com::sun::star->css in extensions/ Change-Id: I64af9f5ae444e1f7bc6c0e8c29df383a9531dba9
2015-09-30 11:48:44 +02:00
impl_getEnumConverter( const css::uno::Type& _rEnumType );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
Replace "SAL_DELETED_FUNCTION" with "= delete" in LIBO_INTERNAL_ONLY code Change-Id: I328ac7a95ccc87732efae48b567a0556865928f3
2015-10-12 15:25:41 +02:00
GenericPropertyHandler( const GenericPropertyHandler& ) = delete;
GenericPropertyHandler& operator=( const GenericPropertyHandler& ) = delete;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +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.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +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 pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +00:00
fixincludeguards.sh: extensions Change-Id: If652bce4cf7621795b084bcbc0aa4c46dd903878
2014-04-18 20:41:29 +02:00
#endif // INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_GENERICPROPERTYHANDLER_HXX
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs 2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:22 fs 1.1.2.6: #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/09/05 07:41:51 fs 1.1.2.5: #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:31 fs 1.1.2.4: #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/12 16:30:12 fs 1.1.2.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:46 fs 1.1.2.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:02 fs 1.1.2.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:25:17 +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