Files
libreoffice/extensions/source/propctrlr/submissionhandler.cxx

451 lines
19 KiB
C++
Raw Normal View History

/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
/*************************************************************************
*
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* Copyright 2000, 2010 Oracle and/or its affiliates.
*
* OpenOffice.org - a multi-platform office productivity suite
*
* This file is part of OpenOffice.org.
*
* 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.
*
* 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).
*
* 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.
*
************************************************************************/
// MARKER(update_precomp.py): autogen include statement, do not remove
#include "precompiled_extensions.hxx"
#include "submissionhandler.hxx"
#include "formmetadata.hxx"
#include "formstrings.hxx"
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
#include "handlerhelper.hxx"
/** === begin UNO includes === **/
#include <com/sun/star/form/FormButtonType.hpp>
#include <com/sun/star/container/XNamed.hpp>
#include <com/sun/star/container/XIndexAccess.hpp>
#include <com/sun/star/form/submission/XSubmissionSupplier.hpp>
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
#include <com/sun/star/inspection/XObjectInspectorUI.hpp>
/** === end UNO includes === **/
#include <tools/debug.hxx>
#include <rtl/ustrbuf.hxx>
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
//------------------------------------------------------------------------
extern "C" void SAL_CALL createRegistryInfo_SubmissionPropertyHandler()
{
::pcr::SubmissionPropertyHandler::registerImplementation();
}
//........................................................................
namespace pcr
{
//........................................................................
using namespace ::comphelper;
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::script;
using namespace ::com::sun::star::form;
using namespace ::com::sun::star::xforms;
using namespace ::com::sun::star::container;
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
using namespace ::com::sun::star::inspection;
//====================================================================
//= SubmissionHelper
//====================================================================
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
SubmissionHelper::SubmissionHelper( ::osl::Mutex& _rMutex, const Reference< XPropertySet >& _rxIntrospectee, const Reference< frame::XModel >& _rxContextDocument )
:EFormsHelper( _rMutex, _rxIntrospectee, _rxContextDocument )
{
OSL_ENSURE( canTriggerSubmissions( _rxIntrospectee, _rxContextDocument ),
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
"SubmissionHelper::SubmissionHelper: you should not have instantiated me!" );
}
//--------------------------------------------------------------------
bool SubmissionHelper::canTriggerSubmissions( const Reference< XPropertySet >& _rxControlModel,
const Reference< frame::XModel >& _rxContextDocument ) SAL_THROW(())
{
if ( !EFormsHelper::isEForm( _rxContextDocument ) )
return false;
try
{
Reference< submission::XSubmissionSupplier > xSubmissionSupp( _rxControlModel, UNO_QUERY );
if ( xSubmissionSupp.is() )
return true;
}
catch( const Exception& )
{
OSL_ENSURE( sal_False, "SubmissionHelper::canTriggerSubmissions: caught an exception!" );
}
return false;
}
//====================================================================
//= SubmissionPropertyHandler
//====================================================================
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
DBG_NAME( SubmissionPropertyHandler )
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
SubmissionPropertyHandler::SubmissionPropertyHandler( const Reference< XComponentContext >& _rxContext )
:EditPropertyHandler_Base( _rxContext )
,OPropertyChangeListener( m_aMutex )
,m_pPropChangeMultiplexer( NULL )
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
DBG_CTOR( SubmissionPropertyHandler, NULL );
}
//--------------------------------------------------------------------
SubmissionPropertyHandler::~SubmissionPropertyHandler( )
{
disposeAdapter();
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
DBG_DTOR( SubmissionPropertyHandler, NULL );
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
::rtl::OUString SAL_CALL SubmissionPropertyHandler::getImplementationName_static( ) throw (RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
return ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "com.sun.star.comp.extensions.SubmissionPropertyHandler" ) );
}
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
//--------------------------------------------------------------------
Sequence< ::rtl::OUString > SAL_CALL SubmissionPropertyHandler::getSupportedServiceNames_static( ) throw (RuntimeException)
{
Sequence< ::rtl::OUString > aSupported( 1 );
aSupported[0] = ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "com.sun.star.form.inspection.SubmissionPropertyHandler" ) );
return aSupported;
}
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
//--------------------------------------------------------------------
Any SAL_CALL SubmissionPropertyHandler::getPropertyValue( const ::rtl::OUString& _rPropertyName ) throw (UnknownPropertyException, RuntimeException)
{
::osl::MutexGuard aGuard( m_aMutex );
PropertyId nPropId( impl_getPropertyId_throw( _rPropertyName ) );
OSL_ENSURE( m_pHelper.get(), "SubmissionPropertyHandler::getPropertyValue: inconsistency!" );
// if we survived impl_getPropertyId_throw, we should have a helper, since no helper implies no properties
Any aReturn;
try
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
switch ( nPropId )
{
case PROPERTY_ID_SUBMISSION_ID:
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
Reference< submission::XSubmissionSupplier > xSubmissionSupp( m_xComponent, UNO_QUERY );
OSL_ENSURE( xSubmissionSupp.is(), "SubmissionPropertyHandler::getPropertyValue: this should never happen ..." );
// this handler is not intended for components which are no XSubmissionSupplier
Reference< submission::XSubmission > xSubmission;
if ( xSubmissionSupp.is() )
xSubmission = xSubmissionSupp->getSubmission( );
aReturn <<= xSubmission;
}
break;
case PROPERTY_ID_XFORMS_BUTTONTYPE:
{
FormButtonType eType = FormButtonType_PUSH;
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
OSL_VERIFY( m_xComponent->getPropertyValue( PROPERTY_BUTTONTYPE ) >>= eType );
if ( ( eType != FormButtonType_PUSH ) && ( eType != FormButtonType_SUBMIT ) )
eType = FormButtonType_PUSH;
aReturn <<= eType;
}
break;
default:
2011-03-01 17:55:09 +01:00
OSL_FAIL( "SubmissionPropertyHandler::getPropertyValue: cannot handle this property!" );
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
break;
}
}
catch( const Exception& )
{
OSL_ENSURE( sal_False, "SubmissionPropertyHandler::getPropertyValue: caught an exception!" );
}
return aReturn;
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
void SAL_CALL SubmissionPropertyHandler::setPropertyValue( const ::rtl::OUString& _rPropertyName, const Any& _rValue ) throw (UnknownPropertyException, RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
::osl::MutexGuard aGuard( m_aMutex );
PropertyId nPropId( impl_getPropertyId_throw( _rPropertyName ) );
OSL_ENSURE( m_pHelper.get(), "SubmissionPropertyHandler::setPropertyValue: inconsistency!" );
// if we survived impl_getPropertyId_throw, we should have a helper, since no helper implies no properties
try
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
switch ( nPropId )
{
case PROPERTY_ID_SUBMISSION_ID:
{
Reference< submission::XSubmission > xSubmission;
OSL_VERIFY( _rValue >>= xSubmission );
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
Reference< submission::XSubmissionSupplier > xSubmissionSupp( m_xComponent, UNO_QUERY );
OSL_ENSURE( xSubmissionSupp.is(), "SubmissionPropertyHandler::setPropertyValue: this should never happen ..." );
// this handler is not intended for components which are no XSubmissionSupplier
if ( xSubmissionSupp.is() )
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
{
xSubmissionSupp->setSubmission( xSubmission );
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
impl_setContextDocumentModified_nothrow();
}
}
break;
case PROPERTY_ID_XFORMS_BUTTONTYPE:
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
m_xComponent->setPropertyValue( PROPERTY_BUTTONTYPE, _rValue );
break;
default:
OSL_ENSURE( sal_False, "SubmissionPropertyHandler::setPropertyValue: cannot handle this id!" );
}
}
catch( const Exception& )
{
OSL_ENSURE( sal_False, "SubmissionPropertyHandler::setPropertyValue: caught an exception!" );
}
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
Sequence< ::rtl::OUString > SAL_CALL SubmissionPropertyHandler::getActuatingProperties( ) throw (RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
::osl::MutexGuard aGuard( m_aMutex );
if ( !m_pHelper.get() )
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
return Sequence< ::rtl::OUString >();
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
Sequence< ::rtl::OUString > aReturn( 1 );
aReturn[ 0 ] = PROPERTY_XFORMS_BUTTONTYPE;
return aReturn;
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
Sequence< ::rtl::OUString > SAL_CALL SubmissionPropertyHandler::getSupersededProperties( ) throw (RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
::osl::MutexGuard aGuard( m_aMutex );
if ( !m_pHelper.get() )
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
return Sequence< ::rtl::OUString >();
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
Sequence< ::rtl::OUString > aReturn( 3 );
aReturn[ 0 ] = PROPERTY_TARGET_URL;
aReturn[ 1 ] = PROPERTY_TARGET_FRAME;
aReturn[ 2 ] = PROPERTY_BUTTONTYPE;
return aReturn;
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
void SubmissionPropertyHandler::onNewComponent()
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
if ( m_pPropChangeMultiplexer )
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
m_pPropChangeMultiplexer->dispose();
m_pPropChangeMultiplexer->release();
m_pPropChangeMultiplexer = NULL;
}
EditPropertyHandler_Base::onNewComponent();
Reference< frame::XModel > xDocument( impl_getContextDocument_nothrow() );
DBG_ASSERT( xDocument.is(), "SubmissionPropertyHandler::onNewComponent: no document!" );
m_pHelper.reset( NULL );
if ( SubmissionHelper::canTriggerSubmissions( m_xComponent, xDocument ) )
{
m_pHelper.reset( new SubmissionHelper( m_aMutex, m_xComponent, xDocument ) );
m_pPropChangeMultiplexer = new OPropertyChangeMultiplexer( this, m_xComponent );
m_pPropChangeMultiplexer->acquire();
m_pPropChangeMultiplexer->addProperty( PROPERTY_BUTTONTYPE );
}
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
Sequence< Property > SAL_CALL SubmissionPropertyHandler::doDescribeSupportedProperties() const
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
::std::vector< Property > aProperties;
if ( m_pHelper.get() )
{
implAddPropertyDescription( aProperties, PROPERTY_SUBMISSION_ID, ::getCppuType( static_cast< Reference< submission::XSubmission > * >( NULL ) ) );
implAddPropertyDescription( aProperties, PROPERTY_XFORMS_BUTTONTYPE, ::getCppuType( static_cast< FormButtonType* >( NULL ) ) );
}
if ( aProperties.empty() )
return Sequence< Property >();
return Sequence< Property >( &(*aProperties.begin()), aProperties.size() );
}
//--------------------------------------------------------------------
LineDescriptor SAL_CALL SubmissionPropertyHandler::describePropertyLine( const ::rtl::OUString& _rPropertyName,
const Reference< XPropertyControlFactory >& _rxControlFactory )
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
throw (UnknownPropertyException, NullPointerException, RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
::osl::MutexGuard aGuard( m_aMutex );
if ( !_rxControlFactory.is() )
throw NullPointerException();
if ( !m_pHelper.get() )
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
RuntimeException();
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
::std::vector< ::rtl::OUString > aListEntries;
PropertyId nPropId( impl_getPropertyId_throw( _rPropertyName ) );
switch ( nPropId )
{
case PROPERTY_ID_SUBMISSION_ID:
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
const_cast< SubmissionHelper* >( m_pHelper.get() )->getAllElementUINames( EFormsHelper::Submission, aListEntries, false );
break;
case PROPERTY_ID_XFORMS_BUTTONTYPE:
{
// available options are nearly the same as for the "normal" button type, but only the
// first two options
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
aListEntries = m_pInfoService->getPropertyEnumRepresentations( PROPERTY_ID_BUTTONTYPE );
aListEntries.resize( 2 );
}
break;
default:
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
OSL_ENSURE( sal_False, "SubmissionPropertyHandler::describePropertyLine: cannot handle this id!" );
return LineDescriptor();
}
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
LineDescriptor aDescriptor;
aDescriptor.Control = PropertyHandlerHelper::createListBoxControl( _rxControlFactory, aListEntries, sal_False, sal_True );
aDescriptor.DisplayName = m_pInfoService->getPropertyTranslation( nPropId );
aDescriptor.Category = ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "General" ) );
aDescriptor.HelpURL = HelpIdUrl::getHelpURL( m_pInfoService->getPropertyHelpId( nPropId ) );
return aDescriptor;
}
//--------------------------------------------------------------------
void SAL_CALL SubmissionPropertyHandler::actuatingPropertyChanged( const ::rtl::OUString& _rActuatingPropertyName, const Any& _rNewValue, const Any& /*_rOldValue*/, const Reference< XObjectInspectorUI >& _rxInspectorUI, sal_Bool ) throw (NullPointerException, RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
if ( !_rxInspectorUI.is() )
throw NullPointerException();
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
::osl::MutexGuard aGuard( m_aMutex );
PropertyId nActuatingPropId( impl_getPropertyId_throw( _rActuatingPropertyName ) );
OSL_PRECOND( m_pHelper.get(), "SubmissionPropertyHandler::actuatingPropertyChanged: inconsistentcy!" );
// if we survived impl_getPropertyId_throw, we should have a helper, since no helper implies no properties
switch ( nActuatingPropId )
{
case PROPERTY_ID_XFORMS_BUTTONTYPE:
{
FormButtonType eType = FormButtonType_PUSH;
OSL_VERIFY( _rNewValue >>= eType );
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
_rxInspectorUI->enablePropertyUI( PROPERTY_SUBMISSION_ID, eType == FormButtonType_SUBMIT );
}
break;
default:
OSL_ENSURE( sal_False, "SubmissionPropertyHandler::actuatingPropertyChanged: cannot handle this id!" );
}
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
Any SAL_CALL SubmissionPropertyHandler::convertToPropertyValue( const ::rtl::OUString& _rPropertyName, const Any& _rControlValue ) throw (UnknownPropertyException, RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
::osl::MutexGuard aGuard( m_aMutex );
Any aPropertyValue;
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
OSL_ENSURE( m_pHelper.get(), "SubmissionPropertyHandler::convertToPropertyValue: we have no SupportedProperties!" );
if ( !m_pHelper.get() )
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
return aPropertyValue;
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
::rtl::OUString sControlValue;
OSL_VERIFY( _rControlValue >>= sControlValue );
PropertyId nPropId( m_pInfoService->getPropertyId( _rPropertyName ) );
switch ( nPropId )
{
case PROPERTY_ID_SUBMISSION_ID:
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
Reference< XSubmission > xSubmission( m_pHelper->getModelElementFromUIName( EFormsHelper::Submission, sControlValue ), UNO_QUERY );
aPropertyValue <<= xSubmission;
}
break;
case PROPERTY_ID_XFORMS_BUTTONTYPE:
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
::rtl::Reference< IPropertyEnumRepresentation > aEnumConversion(
new DefaultEnumRepresentation( *m_pInfoService, ::getCppuType( static_cast< FormButtonType* >( NULL ) ), PROPERTY_ID_BUTTONTYPE ) );
// TODO/UNOize: make aEnumConversion a member?
aEnumConversion->getValueFromDescription( sControlValue, aPropertyValue );
}
break;
default:
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
OSL_ENSURE( sal_False, "SubmissionPropertyHandler::convertToPropertyValue: cannot handle this id!" );
}
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
return aPropertyValue;
}
//--------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
Any SAL_CALL SubmissionPropertyHandler::convertToControlValue( const ::rtl::OUString& _rPropertyName, const Any& _rPropertyValue, const Type& _rControlValueType ) throw (UnknownPropertyException, RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
::osl::MutexGuard aGuard( m_aMutex );
Any aControlValue;
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
OSL_ENSURE( m_pHelper.get(), "SubmissionPropertyHandler::convertToControlValue: we have no SupportedProperties!" );
if ( !m_pHelper.get() )
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
return aControlValue;
OSL_ENSURE( _rControlValueType.getTypeClass() == TypeClass_STRING,
"SubmissionPropertyHandler::convertToControlValue: all our controls should use strings for value exchange!" );
(void)_rControlValueType;
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
PropertyId nPropId( m_pInfoService->getPropertyId( _rPropertyName ) );
switch ( nPropId )
{
case PROPERTY_ID_SUBMISSION_ID:
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
Reference< XPropertySet > xSubmission( _rPropertyValue, UNO_QUERY );
if ( xSubmission.is() )
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
aControlValue <<= m_pHelper->getModelElementUIName( EFormsHelper::Submission, xSubmission );
}
break;
case PROPERTY_ID_XFORMS_BUTTONTYPE:
{
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
::rtl::Reference< IPropertyEnumRepresentation > aEnumConversion(
new DefaultEnumRepresentation( *m_pInfoService, _rPropertyValue.getValueType(), PROPERTY_ID_BUTTONTYPE ) );
// TODO/UNOize: make aEnumConversion a member?
aControlValue <<= aEnumConversion->getDescriptionForValue( _rPropertyValue );
}
break;
default:
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
OSL_ENSURE( sal_False, "SubmissionPropertyHandler::convertToControlValue: cannot handle this id!" );
}
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED 2006/03/10 11:32:29 fs 1.3.88.19: help ids 2006/03/10 09:43:46 fs 1.3.88.18: proper enum types 2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers 2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications 2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it) 2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs 2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:20 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:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED 2005/09/05 07:41:55 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:35 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:07 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:08 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:33:39 +00:00
return aControlValue;
}
//--------------------------------------------------------------------
void SubmissionPropertyHandler::_propertyChanged( const PropertyChangeEvent& _rEvent ) throw(RuntimeException)
{
if ( _rEvent.PropertyName == PROPERTY_BUTTONTYPE )
firePropertyChange( PROPERTY_XFORMS_BUTTONTYPE, PROPERTY_ID_XFORMS_BUTTONTYPE, _rEvent.OldValue, _rEvent.NewValue );
}
//........................................................................
} // namespace pcr
//........................................................................
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */