2004-11-16 11:14:38 +00:00
|
|
|
/*************************************************************************
|
|
|
|
*
|
2008-04-11 10:28:25 +00:00
|
|
|
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
|
2004-11-16 11:14:38 +00:00
|
|
|
*
|
2008-04-11 10:28:25 +00:00
|
|
|
* Copyright 2008 by Sun Microsystems, Inc.
|
2004-11-16 11:14:38 +00:00
|
|
|
*
|
2008-04-11 10:28:25 +00:00
|
|
|
* OpenOffice.org - a multi-platform office productivity suite
|
2004-11-16 11:14:38 +00:00
|
|
|
*
|
2008-04-11 10:28:25 +00:00
|
|
|
* $RCSfile: xsdvalidationpropertyhandler.cxx,v $
|
|
|
|
* $Revision: 1.12 $
|
2004-11-16 11:14:38 +00:00
|
|
|
*
|
2008-04-11 10:28:25 +00:00
|
|
|
* This file is part of OpenOffice.org.
|
2004-11-16 11:14:38 +00:00
|
|
|
*
|
2008-04-11 10:28:25 +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:14:38 +00:00
|
|
|
*
|
2008-04-11 10:28:25 +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:14:38 +00:00
|
|
|
*
|
2008-04-11 10:28:25 +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:14:38 +00:00
|
|
|
*
|
|
|
|
************************************************************************/
|
|
|
|
|
2006-09-16 12:25:52 +00:00
|
|
|
// MARKER(update_precomp.py): autogen include statement, do not remove
|
|
|
|
#include "precompiled_extensions.hxx"
|
2004-11-16 11:14:38 +00:00
|
|
|
#include "xsdvalidationpropertyhandler.hxx"
|
|
|
|
#include "formstrings.hxx"
|
|
|
|
#include "formmetadata.hxx"
|
|
|
|
#include "xsddatatypes.hxx"
|
|
|
|
#ifndef _EXTENSIONS_PROPCTRLR_MODULEPRC_HXX_
|
|
|
|
#include "modulepcr.hxx"
|
|
|
|
#endif
|
|
|
|
#ifndef _EXTENSIONS_FORMCTRLR_PROPRESID_HRC_
|
|
|
|
#include "formresid.hrc"
|
|
|
|
#endif
|
|
|
|
#ifndef _EXTENSIONS_PROPCTRLR_FORMLOCALID_HRC_
|
|
|
|
#include "formlocalid.hrc"
|
|
|
|
#endif
|
|
|
|
#ifndef EXTENSIONS_INC_EXTENSIO_HRC
|
|
|
|
#include "extensio.hrc"
|
|
|
|
#endif
|
|
|
|
#include "newdatatype.hxx"
|
|
|
|
#include "xsdvalidationhelper.hxx"
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
#include "pcrcommon.hxx"
|
|
|
|
#include "handlerhelper.hxx"
|
2004-11-16 11:14:38 +00:00
|
|
|
|
|
|
|
/** === begin UNO includes === **/
|
|
|
|
#include <com/sun/star/beans/PropertyAttribute.hpp>
|
|
|
|
#include <com/sun/star/xsd/WhiteSpaceTreatment.hpp>
|
|
|
|
#include <com/sun/star/xsd/DataTypeClass.hpp>
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
#include <com/sun/star/inspection/PropertyControlType.hpp>
|
|
|
|
#include <com/sun/star/beans/Optional.hpp>
|
|
|
|
#include <com/sun/star/inspection/XObjectInspectorUI.hpp>
|
|
|
|
#include <com/sun/star/inspection/PropertyLineElement.hpp>
|
2004-11-16 11:14:38 +00:00
|
|
|
/** === end UNO includes === **/
|
|
|
|
#include <vcl/msgbox.hxx>
|
|
|
|
#include <tools/debug.hxx>
|
|
|
|
#include <svtools/localresaccess.hxx>
|
|
|
|
|
|
|
|
#include <algorithm>
|
|
|
|
#include <functional>
|
|
|
|
#include <limits>
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
//------------------------------------------------------------------------
|
|
|
|
extern "C" void SAL_CALL createRegistryInfo_XSDValidationPropertyHandler()
|
|
|
|
{
|
|
|
|
::pcr::XSDValidationPropertyHandler::registerImplementation();
|
|
|
|
}
|
|
|
|
|
2004-11-16 11:14:38 +00:00
|
|
|
//........................................................................
|
|
|
|
namespace pcr
|
|
|
|
{
|
|
|
|
//........................................................................
|
|
|
|
|
|
|
|
using namespace ::com::sun::star;
|
|
|
|
using namespace ::com::sun::star::uno;
|
|
|
|
using namespace ::com::sun::star::lang;
|
|
|
|
using namespace ::com::sun::star::beans;
|
|
|
|
using namespace ::com::sun::star::xforms;
|
|
|
|
using namespace ::com::sun::star::xsd;
|
|
|
|
using namespace ::com::sun::star::script;
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
using namespace ::com::sun::star::inspection;
|
2004-11-16 11:14:38 +00:00
|
|
|
|
|
|
|
using ::com::sun::star::beans::PropertyAttribute::MAYBEVOID;
|
|
|
|
|
|
|
|
//====================================================================
|
|
|
|
//= XSDValidationPropertyHandler
|
|
|
|
//====================================================================
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
DBG_NAME( XSDValidationPropertyHandler )
|
2004-11-16 11:14:38 +00:00
|
|
|
//--------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
XSDValidationPropertyHandler::XSDValidationPropertyHandler( const Reference< XComponentContext >& _rxContext )
|
|
|
|
:XSDValidationPropertyHandler_Base( _rxContext )
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
DBG_CTOR( XSDValidationPropertyHandler, NULL );
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
XSDValidationPropertyHandler::~XSDValidationPropertyHandler()
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
DBG_DTOR( XSDValidationPropertyHandler, NULL );
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
::rtl::OUString SAL_CALL XSDValidationPropertyHandler::getImplementationName_static( ) throw (RuntimeException)
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
return ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "com.sun.star.comp.extensions.XSDValidationPropertyHandler" ) );
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
Sequence< ::rtl::OUString > SAL_CALL XSDValidationPropertyHandler::getSupportedServiceNames_static( ) throw (RuntimeException)
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
Sequence< ::rtl::OUString > aSupported( 1 );
|
|
|
|
aSupported[0] = ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "com.sun.star.form.inspection.XSDValidationPropertyHandler" ) );
|
|
|
|
return aSupported;
|
|
|
|
}
|
2004-11-16 11:14:38 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
//--------------------------------------------------------------------
|
|
|
|
Any SAL_CALL XSDValidationPropertyHandler::getPropertyValue( const ::rtl::OUString& _rPropertyName ) throw (UnknownPropertyException, RuntimeException)
|
|
|
|
{
|
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
|
|
|
PropertyId nPropId( impl_getPropertyId_throw( _rPropertyName ) );
|
2004-11-16 11:14:38 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
OSL_ENSURE( m_pHelper.get(), "XSDValidationPropertyHandler::getPropertyValue: inconsistency!" );
|
|
|
|
// if we survived impl_getPropertyId_throw, we should have a helper, since no helper implies no properties
|
2004-11-16 11:14:38 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
Any aReturn;
|
|
|
|
::rtl::Reference< XSDDataType > pType = m_pHelper->getValidatingDataType();
|
|
|
|
switch ( nPropId )
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
|
|
|
// common facets
|
|
|
|
case PROPERTY_ID_XSD_DATA_TYPE: aReturn = pType.is() ? pType->getFacet( PROPERTY_NAME ) : makeAny( ::rtl::OUString() ); break;
|
|
|
|
case PROPERTY_ID_XSD_WHITESPACES:aReturn = pType.is() ? pType->getFacet( PROPERTY_XSD_WHITESPACES ) : makeAny( WhiteSpaceTreatment::Preserve ); break;
|
|
|
|
case PROPERTY_ID_XSD_PATTERN: aReturn = pType.is() ? pType->getFacet( PROPERTY_XSD_PATTERN ) : makeAny( ::rtl::OUString() ); break;
|
|
|
|
|
|
|
|
// all other properties are simply forwarded, if they exist at the given type
|
|
|
|
default:
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
if ( pType.is() && pType->hasFacet( _rPropertyName ) )
|
|
|
|
aReturn = pType->getFacet( _rPropertyName );
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return aReturn;
|
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
void SAL_CALL XSDValidationPropertyHandler::setPropertyValue( const ::rtl::OUString& _rPropertyName, const Any& _rValue ) throw (UnknownPropertyException, RuntimeException)
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
|
|
|
PropertyId nPropId( impl_getPropertyId_throw( _rPropertyName ) );
|
|
|
|
|
|
|
|
OSL_ENSURE( m_pHelper.get(), "XSDValidationPropertyHandler::getPropertyValue: inconsistency!" );
|
|
|
|
// if we survived impl_getPropertyId_throw, we should have a helper, since no helper implies no properties
|
2004-11-16 11:14:38 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
if ( PROPERTY_ID_XSD_DATA_TYPE == nPropId )
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
|
|
|
::rtl::OUString sTypeName;
|
|
|
|
OSL_VERIFY( _rValue >>= sTypeName );
|
|
|
|
m_pHelper->setValidatingDataTypeByName( sTypeName );
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
impl_setContextDocumentModified_nothrow();
|
2004-11-16 11:14:38 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
::rtl::Reference< XSDDataType > pType = m_pHelper->getValidatingDataType();
|
|
|
|
if ( !pType.is() )
|
|
|
|
{
|
|
|
|
DBG_ERROR( "XSDValidationPropertyHandler::setPropertyValue: you're trying to set a type facet, without a current type!" );
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
pType->setFacet( _rPropertyName, _rValue );
|
|
|
|
impl_setContextDocumentModified_nothrow();
|
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
void XSDValidationPropertyHandler::onNewComponent()
|
|
|
|
{
|
|
|
|
XSDValidationPropertyHandler_Base::onNewComponent();
|
|
|
|
|
|
|
|
Reference< frame::XModel > xDocument( impl_getContextDocument_nothrow() );
|
|
|
|
DBG_ASSERT( xDocument.is(), "XSDValidationPropertyHandler::onNewComponent: no document!" );
|
|
|
|
if ( EFormsHelper::isEForm( xDocument ) )
|
|
|
|
m_pHelper.reset( new XSDValidationHelper( m_aMutex, m_xComponent, xDocument ) );
|
|
|
|
else
|
|
|
|
m_pHelper.reset( NULL );
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
Sequence< Property > XSDValidationPropertyHandler::doDescribeSupportedProperties() const
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
|
|
|
::std::vector< Property > aProperties;
|
|
|
|
|
|
|
|
if ( m_pHelper.get() )
|
|
|
|
{
|
|
|
|
bool bAllowBinding = m_pHelper->canBindToAnyDataType();
|
|
|
|
|
|
|
|
if ( bAllowBinding )
|
|
|
|
{
|
|
|
|
aProperties.reserve( 12 );
|
|
|
|
|
|
|
|
addStringPropertyDescription( aProperties, PROPERTY_XSD_DATA_TYPE );
|
|
|
|
addInt16PropertyDescription ( aProperties, PROPERTY_XSD_WHITESPACES );
|
|
|
|
addStringPropertyDescription( aProperties, PROPERTY_XSD_PATTERN );
|
|
|
|
|
|
|
|
// string facets
|
|
|
|
addInt32PropertyDescription( aProperties, PROPERTY_XSD_LENGTH, MAYBEVOID );
|
|
|
|
addInt32PropertyDescription( aProperties, PROPERTY_XSD_MIN_LENGTH, MAYBEVOID );
|
|
|
|
addInt32PropertyDescription( aProperties, PROPERTY_XSD_MAX_LENGTH, MAYBEVOID );
|
|
|
|
|
|
|
|
// decimal facets
|
|
|
|
addInt32PropertyDescription( aProperties, PROPERTY_XSD_TOTAL_DIGITS, MAYBEVOID );
|
|
|
|
addInt32PropertyDescription( aProperties, PROPERTY_XSD_FRACTION_DIGITS, MAYBEVOID );
|
|
|
|
|
2005-03-23 10:59:54 +00:00
|
|
|
// facets for different types
|
|
|
|
addInt16PropertyDescription( aProperties, PROPERTY_XSD_MAX_INCLUSIVE_INT, MAYBEVOID );
|
|
|
|
addInt16PropertyDescription( aProperties, PROPERTY_XSD_MAX_EXCLUSIVE_INT, MAYBEVOID );
|
|
|
|
addInt16PropertyDescription( aProperties, PROPERTY_XSD_MIN_INCLUSIVE_INT, MAYBEVOID );
|
|
|
|
addInt16PropertyDescription( aProperties, PROPERTY_XSD_MIN_EXCLUSIVE_INT, MAYBEVOID );
|
|
|
|
addDoublePropertyDescription( aProperties, PROPERTY_XSD_MAX_INCLUSIVE_DOUBLE, MAYBEVOID );
|
|
|
|
addDoublePropertyDescription( aProperties, PROPERTY_XSD_MAX_EXCLUSIVE_DOUBLE, MAYBEVOID );
|
|
|
|
addDoublePropertyDescription( aProperties, PROPERTY_XSD_MIN_INCLUSIVE_DOUBLE, MAYBEVOID );
|
|
|
|
addDoublePropertyDescription( aProperties, PROPERTY_XSD_MIN_EXCLUSIVE_DOUBLE, MAYBEVOID );
|
|
|
|
addDatePropertyDescription( aProperties, PROPERTY_XSD_MAX_INCLUSIVE_DATE, MAYBEVOID );
|
|
|
|
addDatePropertyDescription( aProperties, PROPERTY_XSD_MAX_EXCLUSIVE_DATE, MAYBEVOID );
|
|
|
|
addDatePropertyDescription( aProperties, PROPERTY_XSD_MIN_INCLUSIVE_DATE, MAYBEVOID );
|
|
|
|
addDatePropertyDescription( aProperties, PROPERTY_XSD_MIN_EXCLUSIVE_DATE, MAYBEVOID );
|
|
|
|
addTimePropertyDescription( aProperties, PROPERTY_XSD_MAX_INCLUSIVE_TIME, MAYBEVOID );
|
|
|
|
addTimePropertyDescription( aProperties, PROPERTY_XSD_MAX_EXCLUSIVE_TIME, MAYBEVOID );
|
|
|
|
addTimePropertyDescription( aProperties, PROPERTY_XSD_MIN_INCLUSIVE_TIME, MAYBEVOID );
|
|
|
|
addTimePropertyDescription( aProperties, PROPERTY_XSD_MIN_EXCLUSIVE_TIME, MAYBEVOID );
|
|
|
|
addDateTimePropertyDescription( aProperties, PROPERTY_XSD_MAX_INCLUSIVE_DATE_TIME, MAYBEVOID );
|
|
|
|
addDateTimePropertyDescription( aProperties, PROPERTY_XSD_MAX_EXCLUSIVE_DATE_TIME, MAYBEVOID );
|
|
|
|
addDateTimePropertyDescription( aProperties, PROPERTY_XSD_MIN_INCLUSIVE_DATE_TIME, MAYBEVOID );
|
|
|
|
addDateTimePropertyDescription( aProperties, PROPERTY_XSD_MIN_EXCLUSIVE_DATE_TIME, MAYBEVOID );
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
if ( aProperties.empty() )
|
|
|
|
return Sequence< Property >();
|
|
|
|
return Sequence< Property >( &(*aProperties.begin()), aProperties.size() );
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
Sequence< ::rtl::OUString > SAL_CALL XSDValidationPropertyHandler::getSupersededProperties( ) throw (RuntimeException)
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2004-11-16 11:14:38 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
::std::vector< ::rtl::OUString > aSuperfluous;
|
2004-11-16 11:14:38 +00:00
|
|
|
if ( m_pHelper.get() )
|
|
|
|
{
|
|
|
|
aSuperfluous.push_back( PROPERTY_CONTROLSOURCE );
|
|
|
|
aSuperfluous.push_back( PROPERTY_EMPTY_IS_NULL );
|
|
|
|
aSuperfluous.push_back( PROPERTY_FILTERPROPOSAL );
|
|
|
|
aSuperfluous.push_back( PROPERTY_LISTSOURCETYPE );
|
|
|
|
aSuperfluous.push_back( PROPERTY_LISTSOURCE );
|
|
|
|
aSuperfluous.push_back( PROPERTY_BOUNDCOLUMN );
|
|
|
|
|
|
|
|
bool bAllowBinding = m_pHelper->canBindToAnyDataType();
|
|
|
|
|
|
|
|
if ( bAllowBinding )
|
|
|
|
{
|
|
|
|
aSuperfluous.push_back( PROPERTY_MAXTEXTLEN );
|
|
|
|
aSuperfluous.push_back( PROPERTY_VALUEMIN );
|
|
|
|
aSuperfluous.push_back( PROPERTY_VALUEMAX );
|
|
|
|
aSuperfluous.push_back( PROPERTY_DECIMAL_ACCURACY );
|
|
|
|
aSuperfluous.push_back( PROPERTY_TIMEMIN );
|
|
|
|
aSuperfluous.push_back( PROPERTY_TIMEMAX );
|
|
|
|
aSuperfluous.push_back( PROPERTY_DATEMIN );
|
|
|
|
aSuperfluous.push_back( PROPERTY_DATEMAX );
|
|
|
|
aSuperfluous.push_back( PROPERTY_EFFECTIVE_MIN );
|
|
|
|
aSuperfluous.push_back( PROPERTY_EFFECTIVE_MAX );
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
if ( aSuperfluous.empty() )
|
|
|
|
return Sequence< ::rtl::OUString >();
|
|
|
|
return Sequence< ::rtl::OUString >( &(*aSuperfluous.begin()), aSuperfluous.size() );
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
Sequence< ::rtl::OUString > SAL_CALL XSDValidationPropertyHandler::getActuatingProperties( ) throw (RuntimeException)
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2004-11-16 11:14:38 +00:00
|
|
|
::std::vector< ::rtl::OUString > aInterestedInActuations( 2 );
|
|
|
|
if ( m_pHelper.get() )
|
|
|
|
{
|
|
|
|
aInterestedInActuations.push_back( PROPERTY_XSD_DATA_TYPE );
|
|
|
|
aInterestedInActuations.push_back( PROPERTY_XML_DATA_MODEL );
|
|
|
|
}
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
if ( aInterestedInActuations.empty() )
|
|
|
|
return Sequence< ::rtl::OUString >();
|
|
|
|
return Sequence< ::rtl::OUString >( &(*aInterestedInActuations.begin()), aInterestedInActuations.size() );
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
namespace
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
void showPropertyUI( const Reference< XObjectInspectorUI >& _rxInspectorUI, const ::rtl::OUString& _rPropertyName, bool _bShow )
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
|
|
|
if ( _bShow )
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
_rxInspectorUI->showPropertyUI( _rPropertyName );
|
2004-11-16 11:14:38 +00:00
|
|
|
else
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
_rxInspectorUI->hidePropertyUI( _rPropertyName );
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
2006-07-26 07:02:35 +00:00
|
|
|
LineDescriptor SAL_CALL XSDValidationPropertyHandler::describePropertyLine( const ::rtl::OUString& _rPropertyName,
|
|
|
|
const Reference< XPropertyControlFactory >& _rxControlFactory )
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
throw (UnknownPropertyException, NullPointerException, RuntimeException)
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
|
|
|
if ( !_rxControlFactory.is() )
|
|
|
|
throw NullPointerException();
|
2004-11-16 11:14:38 +00:00
|
|
|
if ( !m_pHelper.get() )
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
throw RuntimeException();
|
2004-11-16 11:14:38 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
PropertyId nPropId( impl_getPropertyId_throw( _rPropertyName ) );
|
2004-11-16 11:14:38 +00:00
|
|
|
|
2006-07-26 07:02:35 +00:00
|
|
|
LineDescriptor aDescriptor;
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
if ( nPropId != PROPERTY_ID_XSD_DATA_TYPE )
|
2006-07-26 07:02:35 +00:00
|
|
|
aDescriptor.IndentLevel = 1;
|
2004-11-16 11:14:38 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
// collect some information about the to-be-created control
|
|
|
|
sal_Int16 nControlType = PropertyControlType::TextField;
|
|
|
|
::std::vector< ::rtl::OUString > aListEntries;
|
|
|
|
Optional< double > aMinValue( sal_False, 0 );
|
|
|
|
Optional< double > aMaxValue( sal_False, 0 );
|
2004-11-16 11:14:38 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
switch ( nPropId )
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_XSD_DATA_TYPE:
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
nControlType = PropertyControlType::ListBox;
|
2004-11-16 11:14:38 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
implGetAvailableDataTypeNames( aListEntries );
|
2004-11-16 11:14:38 +00:00
|
|
|
|
2006-07-26 07:02:35 +00:00
|
|
|
aDescriptor.PrimaryButtonId = UID_PROP_ADD_DATA_TYPE;
|
|
|
|
aDescriptor.SecondaryButtonId = UID_PROP_REMOVE_DATA_TYPE;
|
2007-08-03 12:53:19 +00:00
|
|
|
aDescriptor.HasPrimaryButton = aDescriptor.HasSecondaryButton = sal_True;
|
|
|
|
aDescriptor.PrimaryButtonImageURL = ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "private:graphicrepository/extensions/res/buttonplus.png" ) );
|
|
|
|
aDescriptor.SecondaryButtonImageURL = ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "private:graphicrepository/extensions/res/buttonminus.png" ) );
|
2004-11-16 11:14:38 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_XSD_WHITESPACES:
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
nControlType = PropertyControlType::ListBox;
|
|
|
|
aListEntries = m_pInfoService->getPropertyEnumRepresentations( PROPERTY_ID_XSD_WHITESPACES );
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_XSD_PATTERN:
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
nControlType = PropertyControlType::TextField;
|
2004-11-16 11:14:38 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_XSD_LENGTH:
|
|
|
|
case PROPERTY_ID_XSD_MIN_LENGTH:
|
|
|
|
case PROPERTY_ID_XSD_MAX_LENGTH:
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
nControlType = PropertyControlType::NumericField;
|
2004-11-16 11:14:38 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_XSD_TOTAL_DIGITS:
|
|
|
|
case PROPERTY_ID_XSD_FRACTION_DIGITS:
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
nControlType = PropertyControlType::NumericField;
|
2004-11-16 11:14:38 +00:00
|
|
|
break;
|
|
|
|
|
2005-03-23 10:59:54 +00:00
|
|
|
case PROPERTY_ID_XSD_MAX_INCLUSIVE_INT:
|
|
|
|
case PROPERTY_ID_XSD_MAX_EXCLUSIVE_INT:
|
|
|
|
case PROPERTY_ID_XSD_MIN_INCLUSIVE_INT:
|
|
|
|
case PROPERTY_ID_XSD_MIN_EXCLUSIVE_INT:
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
nControlType = PropertyControlType::NumericField;
|
2005-03-23 10:59:54 +00:00
|
|
|
|
|
|
|
// handle limits for various 'INT' types according to
|
|
|
|
// their actual semantics (year, month, day)
|
|
|
|
|
2004-11-16 11:14:38 +00:00
|
|
|
::rtl::Reference< XSDDataType > xDataType( m_pHelper->getValidatingDataType() );
|
|
|
|
sal_Int16 nTypeClass = xDataType.is() ? xDataType->classify() : DataTypeClass::STRING;
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
aMinValue.IsPresent = aMaxValue.IsPresent = sal_True;
|
|
|
|
aMinValue.Value = DataTypeClass::gYear == nTypeClass ? 0 : 1;
|
|
|
|
aMaxValue.Value = ::std::numeric_limits< sal_Int32 >::max();
|
2005-03-23 10:59:54 +00:00
|
|
|
if ( DataTypeClass::gMonth == nTypeClass )
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
aMaxValue.Value = 12;
|
2005-03-23 10:59:54 +00:00
|
|
|
else if ( DataTypeClass::gDay == nTypeClass )
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
aMaxValue.Value = 31;
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2005-03-23 10:59:54 +00:00
|
|
|
case PROPERTY_ID_XSD_MAX_INCLUSIVE_DOUBLE:
|
|
|
|
case PROPERTY_ID_XSD_MAX_EXCLUSIVE_DOUBLE:
|
|
|
|
case PROPERTY_ID_XSD_MIN_INCLUSIVE_DOUBLE:
|
|
|
|
case PROPERTY_ID_XSD_MIN_EXCLUSIVE_DOUBLE:
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
nControlType = PropertyControlType::NumericField;
|
2005-03-23 10:59:54 +00:00
|
|
|
// TODO/eForms: do we have "auto-digits"?
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_XSD_MAX_INCLUSIVE_DATE:
|
|
|
|
case PROPERTY_ID_XSD_MAX_EXCLUSIVE_DATE:
|
|
|
|
case PROPERTY_ID_XSD_MIN_INCLUSIVE_DATE:
|
|
|
|
case PROPERTY_ID_XSD_MIN_EXCLUSIVE_DATE:
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
nControlType = PropertyControlType::DateField;
|
2005-03-23 10:59:54 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_XSD_MAX_INCLUSIVE_TIME:
|
|
|
|
case PROPERTY_ID_XSD_MAX_EXCLUSIVE_TIME:
|
|
|
|
case PROPERTY_ID_XSD_MIN_INCLUSIVE_TIME:
|
|
|
|
case PROPERTY_ID_XSD_MIN_EXCLUSIVE_TIME:
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
nControlType = PropertyControlType::TimeField;
|
2005-03-23 10:59:54 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_XSD_MAX_INCLUSIVE_DATE_TIME:
|
|
|
|
case PROPERTY_ID_XSD_MAX_EXCLUSIVE_DATE_TIME:
|
|
|
|
case PROPERTY_ID_XSD_MIN_INCLUSIVE_DATE_TIME:
|
|
|
|
case PROPERTY_ID_XSD_MIN_EXCLUSIVE_DATE_TIME:
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
nControlType = PropertyControlType::DateTimeField;
|
2005-03-23 10:59:54 +00:00
|
|
|
break;
|
|
|
|
|
2004-11-16 11:14:38 +00:00
|
|
|
default:
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
DBG_ERROR( "XSDValidationPropertyHandler::describePropertyLine: cannot handle this property!" );
|
|
|
|
break;
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
switch ( nControlType )
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
case PropertyControlType::ListBox:
|
2006-12-13 15:59:14 +00:00
|
|
|
aDescriptor.Control = PropertyHandlerHelper::createListBoxControl( _rxControlFactory, aListEntries, sal_False, sal_False );
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
break;
|
|
|
|
case PropertyControlType::NumericField:
|
2006-07-26 07:02:35 +00:00
|
|
|
aDescriptor.Control = PropertyHandlerHelper::createNumericControl( _rxControlFactory, 0, aMinValue, aMaxValue, sal_False );
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
break;
|
2004-11-16 11:14:38 +00:00
|
|
|
default:
|
2006-07-26 07:02:35 +00:00
|
|
|
aDescriptor.Control = _rxControlFactory->createPropertyControl( nControlType, sal_False );
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
break;
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
|
2006-07-26 07:02:35 +00:00
|
|
|
aDescriptor.Category = ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "Data" ) );
|
|
|
|
aDescriptor.DisplayName = m_pInfoService->getPropertyTranslation( nPropId );
|
|
|
|
aDescriptor.HelpURL = HelpIdUrl::getHelpURL( m_pInfoService->getPropertyHelpId( nPropId ) );
|
|
|
|
|
|
|
|
return aDescriptor;
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
2006-07-26 07:02:35 +00:00
|
|
|
InteractiveSelectionResult SAL_CALL XSDValidationPropertyHandler::onInteractivePropertySelection( const ::rtl::OUString& _rPropertyName, sal_Bool _bPrimary, Any& /*_rData*/, const Reference< XObjectInspectorUI >& _rxInspectorUI ) throw (UnknownPropertyException, NullPointerException, RuntimeException)
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
if ( !_rxInspectorUI.is() )
|
|
|
|
throw NullPointerException();
|
|
|
|
|
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
|
|
|
OSL_ENSURE( m_pHelper.get(), "XSDValidationPropertyHandler::onInteractivePropertySelection: we don't have any SupportedProperties!" );
|
2004-11-16 11:14:38 +00:00
|
|
|
if ( !m_pHelper.get() )
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
return InteractiveSelectionResult_Cancelled;
|
2004-11-16 11:14:38 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
PropertyId nPropId( impl_getPropertyId_throw( _rPropertyName ) );
|
|
|
|
|
|
|
|
switch ( nPropId )
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_XSD_DATA_TYPE:
|
|
|
|
{
|
|
|
|
if ( _bPrimary )
|
|
|
|
{
|
|
|
|
::rtl::OUString sNewDataTypeName;
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
if ( implPrepareCloneDataCurrentType( sNewDataTypeName ) )
|
|
|
|
{
|
|
|
|
implDoCloneCurrentDataType( sNewDataTypeName );
|
|
|
|
return InteractiveSelectionResult_Success;
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
}
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
else
|
|
|
|
return implPrepareRemoveCurrentDataType() && implDoRemoveCurrentDataType() ? InteractiveSelectionResult_Success : InteractiveSelectionResult_Cancelled;
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
DBG_ERROR( "XSDValidationPropertyHandler::onInteractivePropertySelection: unexpected property to build a dedicated UI!" );
|
|
|
|
break;
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
return InteractiveSelectionResult_Cancelled;
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
void SAL_CALL XSDValidationPropertyHandler::addPropertyChangeListener( const Reference< XPropertyChangeListener >& _rxListener ) throw (RuntimeException)
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
|
|
|
XSDValidationPropertyHandler_Base::addPropertyChangeListener( _rxListener );
|
2004-11-16 11:14:38 +00:00
|
|
|
if ( m_pHelper.get() )
|
|
|
|
m_pHelper->registerBindingListener( _rxListener );
|
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
void SAL_CALL XSDValidationPropertyHandler::removePropertyChangeListener( const Reference< XPropertyChangeListener >& _rxListener ) throw (RuntimeException)
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2004-11-16 11:14:38 +00:00
|
|
|
if ( m_pHelper.get() )
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
m_pHelper->revokeBindingListener( _rxListener );
|
|
|
|
XSDValidationPropertyHandler_Base::removePropertyChangeListener( _rxListener );
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
bool XSDValidationPropertyHandler::implPrepareCloneDataCurrentType( ::rtl::OUString& _rNewName ) SAL_THROW(())
|
|
|
|
{
|
|
|
|
OSL_PRECOND( m_pHelper.get(), "XSDValidationPropertyHandler::implPrepareCloneDataCurrentType: this will crash!" );
|
|
|
|
|
|
|
|
::rtl::Reference< XSDDataType > pType = m_pHelper->getValidatingDataType();
|
|
|
|
if ( !pType.is() )
|
|
|
|
{
|
|
|
|
DBG_ERROR( "XSDValidationPropertyHandler::implPrepareCloneDataCurrentType: invalid current data type!" );
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
::std::vector< ::rtl::OUString > aExistentNames;
|
|
|
|
m_pHelper->getAvailableDataTypeNames( aExistentNames );
|
|
|
|
|
|
|
|
NewDataTypeDialog aDialog( NULL, pType->getName(), aExistentNames ); // TODO/eForms: proper parent
|
|
|
|
if ( aDialog.Execute() != RET_OK )
|
|
|
|
return false;
|
|
|
|
|
|
|
|
_rNewName = aDialog.GetName();
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
bool XSDValidationPropertyHandler::implDoCloneCurrentDataType( const ::rtl::OUString& _rNewName ) SAL_THROW(())
|
|
|
|
{
|
|
|
|
OSL_PRECOND( m_pHelper.get(), "XSDValidationPropertyHandler::implDoCloneCurrentDataType: this will crash!" );
|
|
|
|
|
|
|
|
::rtl::Reference< XSDDataType > pType = m_pHelper->getValidatingDataType();
|
|
|
|
if ( !pType.is() )
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if ( !m_pHelper->cloneDataType( pType, _rNewName ) )
|
|
|
|
return false;
|
|
|
|
|
|
|
|
m_pHelper->setValidatingDataTypeByName( _rNewName );
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
bool XSDValidationPropertyHandler::implPrepareRemoveCurrentDataType() SAL_THROW(())
|
|
|
|
{
|
|
|
|
OSL_PRECOND( m_pHelper.get(), "XSDValidationPropertyHandler::implPrepareRemoveCurrentDataType: this will crash!" );
|
|
|
|
|
|
|
|
::rtl::Reference< XSDDataType > pType = m_pHelper->getValidatingDataType();
|
|
|
|
if ( !pType.is() )
|
|
|
|
{
|
|
|
|
DBG_ERROR( "XSDValidationPropertyHandler::implPrepareRemoveCurrentDataType: invalid current data type!" );
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// confirmation message
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
String sConfirmation( PcrRes( RID_STR_CONFIRM_DELETE_DATA_TYPE ) );
|
2004-11-16 11:14:38 +00:00
|
|
|
sConfirmation.SearchAndReplaceAscii( "#type#", pType->getName() );
|
|
|
|
QueryBox aQuery( NULL, WB_YES_NO, sConfirmation ); // TODO/eForms: proper parent
|
|
|
|
if ( aQuery.Execute() != RET_YES )
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
bool XSDValidationPropertyHandler::implDoRemoveCurrentDataType() SAL_THROW(())
|
|
|
|
{
|
|
|
|
OSL_PRECOND( m_pHelper.get(), "XSDValidationPropertyHandler::implDoRemoveCurrentDataType: this will crash!" );
|
|
|
|
|
|
|
|
::rtl::Reference< XSDDataType > pType = m_pHelper->getValidatingDataType();
|
|
|
|
if ( !pType.is() )
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// set a new data type at the binding, which is the "basic" type for the one
|
|
|
|
// we are going to delete
|
|
|
|
// (do this before the actual deletion, so the old type is still valid for property change
|
|
|
|
// notifications)
|
|
|
|
m_pHelper->setValidatingDataTypeByName( m_pHelper->getBasicTypeNameForClass( pType->classify() ) );
|
|
|
|
// now remove the type
|
|
|
|
m_pHelper->removeDataTypeFromRepository( pType->getName() );
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
void SAL_CALL XSDValidationPropertyHandler::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:14:38 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
if ( !_rxInspectorUI.is() )
|
|
|
|
throw NullPointerException();
|
|
|
|
|
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
|
|
|
PropertyId nActuatingPropId( impl_getPropertyId_throw( _rActuatingPropertyName ) );
|
2004-11-16 11:14:38 +00:00
|
|
|
if ( !m_pHelper.get() )
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
throw RuntimeException();
|
|
|
|
// if we survived impl_getPropertyId_throw, we should have a helper, since no helper implies no properties
|
2004-11-16 11:14:38 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
switch ( nActuatingPropId )
|
2004-11-16 11:14:38 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_XSD_DATA_TYPE:
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
{
|
|
|
|
::rtl::Reference< XSDDataType > xDataType( m_pHelper->getValidatingDataType() );
|
|
|
|
|
|
|
|
// is removal of this type possible?
|
|
|
|
sal_Bool bIsBasicType = xDataType.is() && xDataType->isBasicType();
|
|
|
|
_rxInspectorUI->enablePropertyUIElements( PROPERTY_XSD_DATA_TYPE, PropertyLineElement::PrimaryButton, xDataType.is() );
|
|
|
|
_rxInspectorUI->enablePropertyUIElements( PROPERTY_XSD_DATA_TYPE, PropertyLineElement::SecondaryButton, xDataType.is() && !bIsBasicType );
|
|
|
|
|
|
|
|
//------------------------------------------------------------
|
|
|
|
// show the facets which are available at the data type
|
|
|
|
::rtl::OUString aFacets[] = {
|
|
|
|
PROPERTY_XSD_WHITESPACES, PROPERTY_XSD_PATTERN,
|
|
|
|
PROPERTY_XSD_LENGTH, PROPERTY_XSD_MIN_LENGTH, PROPERTY_XSD_MAX_LENGTH, PROPERTY_XSD_TOTAL_DIGITS,
|
|
|
|
PROPERTY_XSD_FRACTION_DIGITS,
|
|
|
|
PROPERTY_XSD_MAX_INCLUSIVE_INT,
|
|
|
|
PROPERTY_XSD_MAX_EXCLUSIVE_INT,
|
|
|
|
PROPERTY_XSD_MIN_INCLUSIVE_INT,
|
|
|
|
PROPERTY_XSD_MIN_EXCLUSIVE_INT,
|
|
|
|
PROPERTY_XSD_MAX_INCLUSIVE_DOUBLE,
|
|
|
|
PROPERTY_XSD_MAX_EXCLUSIVE_DOUBLE,
|
|
|
|
PROPERTY_XSD_MIN_INCLUSIVE_DOUBLE,
|
|
|
|
PROPERTY_XSD_MIN_EXCLUSIVE_DOUBLE,
|
|
|
|
PROPERTY_XSD_MAX_INCLUSIVE_DATE,
|
|
|
|
PROPERTY_XSD_MAX_EXCLUSIVE_DATE,
|
|
|
|
PROPERTY_XSD_MIN_INCLUSIVE_DATE,
|
|
|
|
PROPERTY_XSD_MIN_EXCLUSIVE_DATE,
|
|
|
|
PROPERTY_XSD_MAX_INCLUSIVE_TIME,
|
|
|
|
PROPERTY_XSD_MAX_EXCLUSIVE_TIME,
|
|
|
|
PROPERTY_XSD_MIN_INCLUSIVE_TIME,
|
|
|
|
PROPERTY_XSD_MIN_EXCLUSIVE_TIME,
|
|
|
|
PROPERTY_XSD_MAX_INCLUSIVE_DATE_TIME,
|
|
|
|
PROPERTY_XSD_MAX_EXCLUSIVE_DATE_TIME,
|
|
|
|
PROPERTY_XSD_MIN_INCLUSIVE_DATE_TIME,
|
|
|
|
PROPERTY_XSD_MIN_EXCLUSIVE_DATE_TIME
|
|
|
|
};
|
|
|
|
|
2008-01-14 14:02:17 +00:00
|
|
|
size_t i=0;
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
const ::rtl::OUString* pLoop = NULL;
|
|
|
|
for ( i = 0, pLoop = aFacets;
|
|
|
|
i < sizeof( aFacets ) / sizeof( aFacets[0] );
|
|
|
|
++i, ++pLoop
|
|
|
|
)
|
|
|
|
{
|
|
|
|
showPropertyUI( _rxInspectorUI, *pLoop, xDataType.is() && xDataType->hasFacet( *pLoop ) );
|
|
|
|
_rxInspectorUI->enablePropertyUI( *pLoop, !bIsBasicType );
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
2004-11-16 11:14:38 +00:00
|
|
|
|
|
|
|
case PROPERTY_ID_XML_DATA_MODEL:
|
|
|
|
{
|
|
|
|
// The data type which the current binding works with may not be present in the
|
|
|
|
// new model. Thus, transfer it.
|
|
|
|
::rtl::OUString sOldModelName; _rOldValue >>= sOldModelName;
|
|
|
|
::rtl::OUString sNewModelName; _rNewValue >>= sNewModelName;
|
|
|
|
::rtl::OUString sDataType = m_pHelper->getValidatingDataTypeName();
|
|
|
|
m_pHelper->copyDataType( sOldModelName, sNewModelName, sDataType );
|
|
|
|
|
|
|
|
// the list of available data types depends on the chosen model, so update this
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:36 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:09 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:35:13 +00:00
|
|
|
if ( !_bFirstTimeInit )
|
|
|
|
_rxInspectorUI->rebuildPropertyUI( PROPERTY_XSD_DATA_TYPE );
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2005-03-23 10:59:54 +00:00
|
|
|
DBG_ERROR( "XSDValidationPropertyHandler::actuatingPropertyChanged: cannot handle this property!" );
|
|
|
|
return;
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
2005-03-23 10:59:54 +00:00
|
|
|
|
|
|
|
// in both cases, we need to care for the current value of the XSD_DATA_TYPE property,
|
|
|
|
// and update the FormatKey of the formatted field we're inspecting (if any)
|
|
|
|
if ( !_bFirstTimeInit && m_pHelper->isInspectingFormattedField() )
|
|
|
|
m_pHelper->findDefaultFormatForIntrospectee();
|
2004-11-16 11:14:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
void XSDValidationPropertyHandler::implGetAvailableDataTypeNames( ::std::vector< ::rtl::OUString >& /* [out] */ _rNames ) const SAL_THROW(())
|
|
|
|
{
|
|
|
|
OSL_PRECOND( m_pHelper.get(), "XSDValidationPropertyHandler::implGetAvailableDataTypeNames: this will crash!" );
|
|
|
|
// start with *all* types which are available at the model
|
|
|
|
::std::vector< ::rtl::OUString > aAllTypes;
|
|
|
|
m_pHelper->getAvailableDataTypeNames( aAllTypes );
|
|
|
|
_rNames.clear();
|
|
|
|
_rNames.reserve( aAllTypes.size() );
|
|
|
|
|
|
|
|
// then allow only those which are "compatible" with our control
|
|
|
|
for ( ::std::vector< ::rtl::OUString >::const_iterator dataType = aAllTypes.begin();
|
|
|
|
dataType != aAllTypes.end();
|
|
|
|
++dataType
|
|
|
|
)
|
|
|
|
{
|
|
|
|
::rtl::Reference< XSDDataType > pType = m_pHelper->getDataTypeByName( *dataType );
|
|
|
|
if ( pType.is() && m_pHelper->canBindToDataType( pType->classify() ) )
|
|
|
|
_rNames.push_back( *dataType );
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//........................................................................
|
|
|
|
} // namespace pcr
|
|
|
|
//........................................................................
|
|
|
|
|