Files
libreoffice/extensions/source/propctrlr/pcrcommon.hxx

144 lines
5.6 KiB
C++
Raw Normal View History

2010-10-27 12:45:03 +01:00
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
/*
* 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 .
*/
#ifndef INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_PCRCOMMON_HXX
#define INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_PCRCOMMON_HXX
#define EDITOR_LIST_APPEND (SAL_MAX_UINT16)
#define EDITOR_LIST_REPLACE_EXISTING (SAL_MAX_UINT16)
#define EDITOR_LIST_ENTRY_NOTFOUND (SAL_MAX_UINT16)
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
#include <com/sun/star/uno/Sequence.hxx>
#include <com/sun/star/beans/XPropertyChangeListener.hpp>
#include <com/sun/star/beans/PropertyChangeEvent.hpp>
#include <toolkit/helper/vclunohelper.hxx>
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
#include <comphelper/listenernotification.hxx>
namespace pcr
{
#define OWN_PROPERTY_ID_INTROSPECTEDOBJECT 0x0010
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
#define OWN_PROPERTY_ID_CURRENTPAGE 0x0011
#define OWN_PROPERTY_ID_CONTROLCONTEXT 0x0012
#define OWN_PROPERTY_ID_TABBINGMODEL 0x0013
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
//= types
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
typedef ::comphelper::OSimpleListenerContainer < ::com::sun::star::beans::XPropertyChangeListener
, ::com::sun::star::beans::PropertyChangeEvent
> PropertyChangeListeners;
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
//= helper
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
// small helper to make the "swap" call on an STL container a single-line call, which
// in it's canonic form "aFoo.swap( Container() )" doesn't compile with GCC
template< class CONTAINER >
void clearContainer( CONTAINER& _rContainer )
{
CONTAINER aEmpty;
_rContainer.swap( aEmpty );
}
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
//= HelpIdUrl
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
/// small helper to translate help ids into help urls
class HelpIdUrl
{
public:
static OString getHelpId( const OUString& _rHelpURL );
static OUString getHelpURL( const OString& );
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
};
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
//= StlSyntaxSequence
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
template< class ELEMENT >
class StlSyntaxSequence : public ::com::sun::star::uno::Sequence< ELEMENT >
{
private:
typedef ::com::sun::star::uno::Sequence< ELEMENT > UnoBase;
public:
inline StlSyntaxSequence() : UnoBase() { }
inline StlSyntaxSequence( const UnoBase& rSeq ) : UnoBase( rSeq ) { }
inline StlSyntaxSequence( const ELEMENT* pElements, sal_Int32 len ) : UnoBase( pElements, len ) { }
inline StlSyntaxSequence( sal_Int32 len ) : UnoBase( len ) { }
operator const UnoBase&() const { return *this; }
operator UnoBase&() { return *this; }
typedef const ELEMENT* const_iterator;
typedef ELEMENT* iterator;
inline const_iterator begin() const { return UnoBase::getConstArray(); }
inline const_iterator end() const { return UnoBase::getConstArray() + UnoBase::getLength(); }
inline iterator begin() { return UnoBase::getArray(); }
inline iterator end() { return UnoBase::getArray() + UnoBase::getLength(); }
inline sal_Int32 size() const { return UnoBase::getLength(); }
inline bool empty() const { return UnoBase::getLength() == 0; }
inline void resize( size_t _newSize ) { UnoBase::realloc( _newSize ); }
inline iterator erase( iterator _pos )
{
iterator loop = end();
while ( --loop != _pos )
*( loop - 1 ) = *loop;
resize( size() - 1 );
}
};
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
//= UNO helpers
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
#define DECLARE_XCOMPONENT() \
virtual void SAL_CALL dispose( ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE; \
virtual void SAL_CALL addEventListener( const ::com::sun::star::uno::Reference< ::com::sun::star::lang::XEventListener >& xListener ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE; \
virtual void SAL_CALL removeEventListener( const ::com::sun::star::uno::Reference< ::com::sun::star::lang::XEventListener >& aListener ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
#define IMPLEMENT_FORWARD_XCOMPONENT( classname, baseclass ) \
void SAL_CALL classname::dispose( ) throw (::com::sun::star::uno::RuntimeException, std::exception) \
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
{ \
baseclass::WeakComponentImplHelperBase::dispose(); \
} \
void SAL_CALL classname::addEventListener( const ::com::sun::star::uno::Reference< ::com::sun::star::lang::XEventListener >& _Listener ) throw (::com::sun::star::uno::RuntimeException, std::exception) \
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
{ \
baseclass::WeakComponentImplHelperBase::addEventListener( _Listener ); \
} \
void SAL_CALL classname::removeEventListener( const ::com::sun::star::uno::Reference< ::com::sun::star::lang::XEventListener >& _Listener ) throw (::com::sun::star::uno::RuntimeException, std::exception) \
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED 2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications 2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double 2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit 2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:52 fs 1.3.158.3: #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/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/18 12:44:32 fs 1.3.158.1: #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)
2006-03-14 10:27:40 +00:00
{ \
baseclass::WeakComponentImplHelperBase::removeEventListener( _Listener ); \
} \
} // namespace pcr
#endif // INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_PCRCOMMON_HXX
2010-10-27 12:45:03 +01:00
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */