2010-10-27 12:45:03 +01:00
|
|
|
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
|
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 .
|
|
|
|
*/
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2014-04-18 20:41:29 +02:00
|
|
|
#ifndef INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_PCRCOMMON_HXX
|
|
|
|
#define INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_PCRCOMMON_HXX
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2014-03-01 03:13:28 +01:00
|
|
|
#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>
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2007-07-06 07:51:14 +00:00
|
|
|
#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>
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
namespace pcr
|
|
|
|
{
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2004-11-16 11:09:14 +00:00
|
|
|
#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
|
|
|
|
|
2014-02-25 18:36:00 +01: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
|
|
|
//= types
|
2014-02-25 18:36:00 +01: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
|
|
|
typedef ::comphelper::OSimpleListenerContainer < ::com::sun::star::beans::XPropertyChangeListener
|
|
|
|
, ::com::sun::star::beans::PropertyChangeEvent
|
|
|
|
> PropertyChangeListeners;
|
|
|
|
|
2014-02-25 18:36:00 +01: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
|
|
|
//= helper
|
2014-02-25 18:36:00 +01: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
|
|
|
// 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 );
|
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01: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
|
|
|
//= HelpIdUrl
|
2014-02-25 18:36:00 +01: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
|
|
|
/// small helper to translate help ids into help urls
|
|
|
|
class HelpIdUrl
|
|
|
|
{
|
|
|
|
public:
|
2013-04-07 12:06:47 +02:00
|
|
|
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
|
|
|
};
|
|
|
|
|
2014-02-25 18:36:00 +01: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
|
2014-02-25 18:36:00 +01: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
|
|
|
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 );
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2014-02-25 18:36:00 +01: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
|
|
|
//= UNO helpers
|
2014-02-25 18:36:00 +01: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
|
|
|
#define DECLARE_XCOMPONENT() \
|
2014-03-27 18:12:18 +01:00
|
|
|
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;
|
2004-11-16 11:09:14 +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
|
|
|
#define IMPLEMENT_FORWARD_XCOMPONENT( classname, baseclass ) \
|
2014-02-25 21:31:58 +01:00
|
|
|
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(); \
|
|
|
|
} \
|
2014-02-25 21:31:58 +01:00
|
|
|
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 ); \
|
|
|
|
} \
|
2014-02-25 21:31:58 +01:00
|
|
|
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 ); \
|
|
|
|
} \
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
} // namespace pcr
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2014-04-18 20:41:29 +02:00
|
|
|
#endif // INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_PCRCOMMON_HXX
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2010-10-27 12:45:03 +01:00
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|