2004-11-16 11:11:27 +00:00
/*************************************************************************
*
2008-04-11 10:17:48 +00:00
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER .
2004-11-16 11:11:27 +00:00
*
2008-04-11 10:17:48 +00:00
* Copyright 2008 by Sun Microsystems , Inc .
2004-11-16 11:11:27 +00:00
*
2008-04-11 10:17:48 +00:00
* OpenOffice . org - a multi - platform office productivity suite
2004-11-16 11:11:27 +00:00
*
2008-04-11 10:17:48 +00:00
* $ RCSfile : propertyhandler . cxx , v $
2008-05-20 18:15:06 +00:00
* $ Revision : 1.13 $
2004-11-16 11:11:27 +00:00
*
2008-04-11 10:17:48 +00:00
* This file is part of OpenOffice . org .
2004-11-16 11:11:27 +00:00
*
2008-04-11 10:17:48 +00:00
* OpenOffice . org is free software : you can redistribute it and / or modify
* it under the terms of the GNU Lesser General Public License version 3
* only , as published by the Free Software Foundation .
2004-11-16 11:11:27 +00:00
*
2008-04-11 10:17:48 +00:00
* OpenOffice . org is distributed in the hope that it will be useful ,
* but WITHOUT ANY WARRANTY ; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE . See the
* GNU Lesser General Public License version 3 for more details
* ( a copy is included in the LICENSE file that accompanied this code ) .
2004-11-16 11:11:27 +00:00
*
2008-04-11 10:17:48 +00:00
* You should have received a copy of the GNU Lesser General Public License
* version 3 along with OpenOffice . org . If not , see
* < http : //www.openoffice.org/license.html>
* for a copy of the LGPLv3 License .
2004-11-16 11:11:27 +00:00
*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
2006-09-16 12:22:23 +00:00
// MARKER(update_precomp.py): autogen include statement, do not remove
# include "precompiled_extensions.hxx"
2004-11-16 11:11:27 +00:00
# include "propertyhandler.hxx"
# include "formmetadata.hxx"
# include "formbrowsertools.hxx"
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
# include "handlerhelper.hxx"
2004-11-16 11:11:27 +00:00
/** === begin UNO includes === **/
# include <com/sun/star/beans/PropertyAttribute.hpp>
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
# include <com/sun/star/lang/NullPointerException.hpp>
# include <com/sun/star/util/XModifiable.hpp>
2004-11-16 11:11:27 +00:00
/** === end UNO includes === **/
# include <tools/debug.hxx>
# include <algorithm>
//........................................................................
namespace pcr
{
//........................................................................
using namespace : : com : : sun : : star : : uno ;
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
using namespace : : com : : sun : : star : : awt ;
2004-11-16 11:11:27 +00:00
using namespace : : com : : sun : : star : : beans ;
using namespace : : com : : sun : : star : : script ;
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
using namespace : : com : : sun : : star : : lang ;
using namespace : : com : : sun : : star : : util ;
using namespace : : com : : sun : : star : : frame ;
using namespace : : com : : sun : : star : : inspection ;
using namespace : : comphelper ;
2004-11-16 11:11:27 +00:00
//====================================================================
//= PropertyHandler
//====================================================================
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
DBG_NAME ( PropertyHandler )
2004-11-16 11:11:27 +00:00
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
PropertyHandler : : PropertyHandler ( const Reference < XComponentContext > & _rxContext )
: PropertyHandler_Base ( m_aMutex )
2004-11-16 11:11:27 +00:00
, m_bSupportedPropertiesAreKnown ( false )
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
, m_aPropertyListeners ( m_aMutex )
2008-01-14 14:00:31 +00:00
, m_aContext ( _rxContext )
, m_pInfoService ( new OPropertyInfoService )
2004-11-16 11:11:27 +00:00
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
DBG_CTOR ( PropertyHandler , NULL ) ;
m_xTypeConverter = Reference < XTypeConverter > (
m_aContext . createComponent ( " com.sun.star.script.Converter " ) ,
UNO_QUERY_THROW
) ;
}
2004-11-16 11:11:27 +00:00
//--------------------------------------------------------------------
PropertyHandler : : ~ PropertyHandler ( )
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
DBG_DTOR ( PropertyHandler , NULL ) ;
}
//--------------------------------------------------------------------
void SAL_CALL PropertyHandler : : inspect ( const Reference < XInterface > & _rxIntrospectee ) throw ( RuntimeException , NullPointerException )
{
if ( ! _rxIntrospectee . is ( ) )
throw NullPointerException ( ) ;
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
Reference < XPropertySet > xNewComponent ( _rxIntrospectee , UNO_QUERY ) ;
if ( xNewComponent = = m_xComponent )
return ;
// remove all old property change listeners
: : std : : auto_ptr < : : cppu : : OInterfaceIteratorHelper > removeListener = m_aPropertyListeners . createIterator ( ) ;
: : std : : auto_ptr < : : cppu : : OInterfaceIteratorHelper > readdListener = m_aPropertyListeners . createIterator ( ) ; // will copy the container as needed
while ( removeListener - > hasMoreElements ( ) )
removePropertyChangeListener ( static_cast < XPropertyChangeListener * > ( removeListener - > next ( ) ) ) ;
OSL_ENSURE ( m_aPropertyListeners . empty ( ) , " PropertyHandler::inspect: derived classes are expected to forward the removePropertyChangeListener call to their base class (me)! " ) ;
// remember the new component, and give derived classes the chance to react on it
m_xComponent = xNewComponent ;
onNewComponent ( ) ;
// add the listeners, again
while ( readdListener - > hasMoreElements ( ) )
addPropertyChangeListener ( static_cast < XPropertyChangeListener * > ( readdListener - > next ( ) ) ) ;
2004-11-16 11:11:27 +00:00
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
void PropertyHandler : : onNewComponent ( )
2004-11-16 11:11:27 +00:00
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
if ( m_xComponent . is ( ) )
m_xComponentPropertyInfo = m_xComponent - > getPropertySetInfo ( ) ;
else
m_xComponentPropertyInfo . clear ( ) ;
m_bSupportedPropertiesAreKnown = false ;
m_aSupportedProperties . realloc ( 0 ) ;
2004-11-16 11:11:27 +00:00
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
Sequence < Property > SAL_CALL PropertyHandler : : getSupportedProperties ( ) throw ( RuntimeException )
2004-11-16 11:11:27 +00:00
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
2004-11-16 11:11:27 +00:00
if ( ! m_bSupportedPropertiesAreKnown )
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
m_aSupportedProperties = doDescribeSupportedProperties ( ) ;
2004-11-16 11:11:27 +00:00
m_bSupportedPropertiesAreKnown = true ;
}
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
return ( Sequence < Property > ) m_aSupportedProperties ;
2004-11-16 11:11:27 +00:00
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
Sequence < : : rtl : : OUString > SAL_CALL PropertyHandler : : getSupersededProperties ( ) throw ( RuntimeException )
2004-11-16 11:11:27 +00:00
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
return Sequence < : : rtl : : OUString > ( ) ;
2004-11-16 11:11:27 +00:00
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
Sequence < : : rtl : : OUString > SAL_CALL PropertyHandler : : getActuatingProperties ( ) throw ( RuntimeException )
2004-11-16 11:11:27 +00:00
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
return Sequence < : : rtl : : OUString > ( ) ;
2004-11-16 11:11:27 +00:00
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
Any SAL_CALL PropertyHandler : : convertToPropertyValue ( const : : rtl : : OUString & _rPropertyName , const Any & _rControlValue ) throw ( UnknownPropertyException , RuntimeException )
2004-11-16 11:11:27 +00:00
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
PropertyId nPropId = m_pInfoService - > getPropertyId ( _rPropertyName ) ;
Property aProperty ( impl_getPropertyFromName_throw ( _rPropertyName ) ) ;
Any aPropertyValue ;
if ( ! _rControlValue . hasValue ( ) )
// NULL is converted to NULL
return aPropertyValue ;
2004-11-16 11:11:27 +00:00
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
if ( ( m_pInfoService - > getPropertyUIFlags ( nPropId ) & PROP_FLAG_ENUM ) ! = 0 )
2004-11-16 11:11:27 +00:00
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
: : rtl : : OUString sControlValue ;
OSL_VERIFY ( _rControlValue > > = sControlValue ) ;
: : rtl : : Reference < IPropertyEnumRepresentation > aEnumConversion (
new DefaultEnumRepresentation ( * m_pInfoService , aProperty . Type , nPropId ) ) ;
// TODO/UNOize: cache those converters?
aEnumConversion - > getValueFromDescription ( sControlValue , aPropertyValue ) ;
2004-11-16 11:11:27 +00:00
}
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
else
aPropertyValue = PropertyHandlerHelper : : convertToPropertyValue (
2007-07-06 07:53:26 +00:00
m_aContext . getContext ( ) , m_xTypeConverter , aProperty , _rControlValue ) ;
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
return aPropertyValue ;
2004-11-16 11:11:27 +00:00
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
Any SAL_CALL PropertyHandler : : convertToControlValue ( const : : rtl : : OUString & _rPropertyName , const Any & _rPropertyValue , const Type & _rControlValueType ) throw ( UnknownPropertyException , RuntimeException )
2004-11-16 11:11:27 +00:00
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
PropertyId nPropId = m_pInfoService - > getPropertyId ( _rPropertyName ) ;
if ( ( m_pInfoService - > getPropertyUIFlags ( nPropId ) & PROP_FLAG_ENUM ) ! = 0 )
{
DBG_ASSERT ( _rControlValueType . getTypeClass ( ) = = TypeClass_STRING , " PropertyHandler::convertToControlValue: ENUM, but not STRING? " ) ;
2004-11-16 11:11:27 +00:00
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
: : rtl : : Reference < IPropertyEnumRepresentation > aEnumConversion (
new DefaultEnumRepresentation ( * m_pInfoService , _rPropertyValue . getValueType ( ) , nPropId ) ) ;
// TODO/UNOize: cache those converters?
return makeAny ( aEnumConversion - > getDescriptionForValue ( _rPropertyValue ) ) ;
}
return PropertyHandlerHelper : : convertToControlValue (
2007-07-06 07:53:26 +00:00
m_aContext . getContext ( ) , m_xTypeConverter , _rPropertyValue , _rControlValueType ) ;
2004-11-16 11:11:27 +00:00
}
//--------------------------------------------------------------------
2006-07-26 07:00:10 +00:00
PropertyState SAL_CALL PropertyHandler : : getPropertyState ( const : : rtl : : OUString & /*_rPropertyName*/ ) throw ( UnknownPropertyException , RuntimeException )
2004-11-16 11:11:27 +00:00
{
return PropertyState_DIRECT_VALUE ;
}
//--------------------------------------------------------------------
2006-07-26 07:00:10 +00:00
LineDescriptor SAL_CALL PropertyHandler : : describePropertyLine ( const : : rtl : : OUString & _rPropertyName ,
const Reference < XPropertyControlFactory > & _rxControlFactory )
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
throw ( UnknownPropertyException , NullPointerException , RuntimeException )
2004-11-16 11:11:27 +00:00
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
if ( ! _rxControlFactory . is ( ) )
throw NullPointerException ( ) ;
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
PropertyId nPropId ( impl_getPropertyId_throw ( _rPropertyName ) ) ;
const Property & rProperty ( impl_getPropertyFromId_throw ( nPropId ) ) ;
2006-07-26 07:00:10 +00:00
LineDescriptor aDescriptor ;
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
if ( ( m_pInfoService - > getPropertyUIFlags ( nPropId ) & PROP_FLAG_ENUM ) ! = 0 )
{
2006-07-26 07:00:10 +00:00
aDescriptor . Control = PropertyHandlerHelper : : createListBoxControl (
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
_rxControlFactory , m_pInfoService - > getPropertyEnumRepresentations ( nPropId ) ,
2006-12-13 15:58:47 +00:00
PropertyHandlerHelper : : requiresReadOnlyControl ( rProperty . Attributes ) , sal_False ) ;
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
}
else
2006-07-26 07:00:10 +00:00
PropertyHandlerHelper : : describePropertyLine ( rProperty , aDescriptor , _rxControlFactory ) ;
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
2006-07-26 07:00:10 +00:00
aDescriptor . HelpURL = HelpIdUrl : : getHelpURL ( m_pInfoService - > getPropertyHelpId ( nPropId ) ) ;
aDescriptor . DisplayName = m_pInfoService - > getPropertyTranslation ( nPropId ) ;
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
if ( ( m_pInfoService - > getPropertyUIFlags ( nPropId ) & PROP_FLAG_DATA_PROPERTY ) ! = 0 )
2006-07-26 07:00:10 +00:00
aDescriptor . Category = : : rtl : : OUString ( RTL_CONSTASCII_USTRINGPARAM ( " Data " ) ) ;
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
else
2006-07-26 07:00:10 +00:00
aDescriptor . Category = : : rtl : : OUString ( RTL_CONSTASCII_USTRINGPARAM ( " General " ) ) ;
return aDescriptor ;
2004-11-16 11:11:27 +00:00
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
: : sal_Bool SAL_CALL PropertyHandler : : isComposable ( const : : rtl : : OUString & _rPropertyName ) throw ( UnknownPropertyException , RuntimeException )
2004-11-16 11:11:27 +00:00
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
return m_pInfoService - > isComposeable ( _rPropertyName ) ;
2004-11-16 11:11:27 +00:00
}
//--------------------------------------------------------------------
2006-07-26 07:00:10 +00:00
InteractiveSelectionResult SAL_CALL PropertyHandler : : onInteractivePropertySelection ( const : : rtl : : OUString & /*_rPropertyName*/ , sal_Bool /*_bPrimary*/ , Any & /*_rData*/ , const Reference < XObjectInspectorUI > & /*_rxInspectorUI*/ ) throw ( UnknownPropertyException , NullPointerException , RuntimeException )
2004-11-16 11:11:27 +00:00
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
DBG_ERROR ( " PropertyHandler::onInteractivePropertySelection: not implemented! " ) ;
return InteractiveSelectionResult_Cancelled ;
2004-11-16 11:11:27 +00:00
}
//--------------------------------------------------------------------
2006-07-26 07:00:10 +00:00
void SAL_CALL PropertyHandler : : actuatingPropertyChanged ( const : : rtl : : OUString & /*_rActuatingPropertyName*/ , const Any & /*_rNewValue*/ , const Any & /*_rOldValue*/ , const Reference < XObjectInspectorUI > & /*_rxInspectorUI*/ , sal_Bool /*_bFirstTimeInit*/ ) throw ( NullPointerException , RuntimeException )
2004-11-16 11:11:27 +00:00
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
DBG_ERROR ( " PropertyHandler::actuatingPropertyChanged: not implemented! " ) ;
2004-11-16 11:11:27 +00:00
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
void SAL_CALL PropertyHandler : : addPropertyChangeListener ( const Reference < XPropertyChangeListener > & _rxListener ) throw ( RuntimeException )
2004-11-16 11:11:27 +00:00
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
if ( ! _rxListener . is ( ) )
throw NullPointerException ( ) ;
m_aPropertyListeners . addListener ( _rxListener ) ;
2004-11-16 11:11:27 +00:00
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
void SAL_CALL PropertyHandler : : removePropertyChangeListener ( const Reference < XPropertyChangeListener > & _rxListener ) throw ( RuntimeException )
2004-11-16 11:11:27 +00:00
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
m_aPropertyListeners . removeListener ( _rxListener ) ;
2004-11-16 11:11:27 +00:00
}
//--------------------------------------------------------------------
2006-07-26 07:00:10 +00:00
sal_Bool SAL_CALL PropertyHandler : : suspend ( sal_Bool /*_bSuspend*/ ) throw ( RuntimeException )
2004-11-16 11:11:27 +00:00
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
return sal_True ;
}
//--------------------------------------------------------------------
IMPLEMENT_FORWARD_XCOMPONENT ( PropertyHandler , PropertyHandler_Base )
//--------------------------------------------------------------------
void SAL_CALL PropertyHandler : : disposing ( )
{
m_xComponent . clear ( ) ;
m_aPropertyListeners . clear ( ) ;
m_xTypeConverter . clear ( ) ;
m_aSupportedProperties . realloc ( 0 ) ;
2004-11-16 11:11:27 +00:00
}
//--------------------------------------------------------------------
void PropertyHandler : : firePropertyChange ( const : : rtl : : OUString & _rPropName , PropertyId _nPropId , const Any & _rOldValue , const Any & _rNewValue ) SAL_THROW ( ( ) )
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
PropertyChangeEvent aEvent ;
aEvent . Source = m_xComponent ;
aEvent . PropertyHandle = _nPropId ;
aEvent . PropertyName = _rPropName ;
aEvent . OldValue = _rOldValue ;
aEvent . NewValue = _rNewValue ;
m_aPropertyListeners . notify ( aEvent , & XPropertyChangeListener : : propertyChange ) ;
2004-11-16 11:11:27 +00:00
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
const Property * PropertyHandler : : impl_getPropertyFromId_nothrow ( PropertyId _nPropId ) const
2004-11-16 11:11:27 +00:00
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
const_cast < PropertyHandler * > ( this ) - > getSupportedProperties ( ) ;
const Property * pFound = : : std : : find_if ( m_aSupportedProperties . begin ( ) , m_aSupportedProperties . end ( ) ,
2004-11-16 11:11:27 +00:00
FindPropertyByHandle ( _nPropId )
) ;
if ( pFound ! = m_aSupportedProperties . end ( ) )
2005-02-24 13:42:44 +00:00
return & ( * pFound ) ;
2004-11-16 11:11:27 +00:00
return NULL ;
}
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
//--------------------------------------------------------------------
const Property & PropertyHandler : : impl_getPropertyFromId_throw ( PropertyId _nPropId ) const
{
const Property * pProperty = impl_getPropertyFromId_nothrow ( _nPropId ) ;
if ( ! pProperty )
throw UnknownPropertyException ( ) ;
return * pProperty ;
}
//--------------------------------------------------------------------
const Property & PropertyHandler : : impl_getPropertyFromName_throw ( const : : rtl : : OUString & _rPropertyName ) const
{
const_cast < PropertyHandler * > ( this ) - > getSupportedProperties ( ) ;
StlSyntaxSequence < Property > : : const_iterator pFound = : : std : : find_if ( m_aSupportedProperties . begin ( ) , m_aSupportedProperties . end ( ) ,
FindPropertyByName ( _rPropertyName )
) ;
if ( pFound = = m_aSupportedProperties . end ( ) )
throw UnknownPropertyException ( ) ;
return * pFound ;
}
2004-11-16 11:11:27 +00:00
//--------------------------------------------------------------------
void PropertyHandler : : implAddPropertyDescription ( : : std : : vector < Property > & _rProperties , const : : rtl : : OUString & _rPropertyName , const Type & _rType , sal_Int16 _nAttribs ) const
{
_rProperties . push_back ( Property (
_rPropertyName ,
m_pInfoService - > getPropertyId ( _rPropertyName ) ,
_rType ,
_nAttribs
) ) ;
}
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
//------------------------------------------------------------------------
Window * PropertyHandler : : impl_getDefaultDialogParent_nothrow ( ) const
2004-11-16 11:11:27 +00:00
{
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
return PropertyHandlerHelper : : getDialogParentWindow ( m_aContext ) ;
2004-11-16 11:11:27 +00:00
}
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
//------------------------------------------------------------------------
PropertyId PropertyHandler : : impl_getPropertyId_throw ( const : : rtl : : OUString & _rPropertyName ) const
{
PropertyId nPropId = m_pInfoService - > getPropertyId ( _rPropertyName ) ;
if ( nPropId = = - 1 )
throw UnknownPropertyException ( ) ;
return nPropId ;
}
//------------------------------------------------------------------------
void PropertyHandler : : impl_setContextDocumentModified_nothrow ( ) const
{
Reference < XModifiable > xModifiable ( impl_getContextDocument_nothrow ( ) , UNO_QUERY ) ;
if ( xModifiable . is ( ) )
xModifiable - > setModified ( sal_True ) ;
}
//------------------------------------------------------------------------
bool PropertyHandler : : impl_componentHasProperty_throw ( const : : rtl : : OUString & _rPropName ) const
{
return m_xComponentPropertyInfo . is ( ) & & m_xComponentPropertyInfo - > hasPropertyByName ( _rPropName ) ;
}
//====================================================================
//= PropertyHandlerComponent
//====================================================================
//------------------------------------------------------------------------
PropertyHandlerComponent : : PropertyHandlerComponent ( const Reference < XComponentContext > & _rxContext )
: PropertyHandler ( _rxContext )
2004-11-16 11:11:27 +00:00
{
}
INTEGRATION: CWS pbrwuno (1.4.88); FILE MERGED
2006/03/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.4.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.4.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:06 fs 1.4.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:30:34 +00:00
//--------------------------------------------------------------------
IMPLEMENT_FORWARD_XINTERFACE2 ( PropertyHandlerComponent , PropertyHandler , PropertyHandlerComponent_Base )
IMPLEMENT_FORWARD_XTYPEPROVIDER2 ( PropertyHandlerComponent , PropertyHandler , PropertyHandlerComponent_Base )
//--------------------------------------------------------------------
: : sal_Bool SAL_CALL PropertyHandlerComponent : : supportsService ( const : : rtl : : OUString & ServiceName ) throw ( RuntimeException )
{
StlSyntaxSequence < : : rtl : : OUString > aAllServices ( getSupportedServiceNames ( ) ) ;
return : : std : : find ( aAllServices . begin ( ) , aAllServices . end ( ) , ServiceName ) ! = aAllServices . end ( ) ;
}
2004-11-16 11:11:27 +00:00
//........................................................................
} // namespace pcr
//........................................................................