2004-11-16 11:04:18 +00:00
|
|
|
/*************************************************************************
|
|
|
|
*
|
2005-09-08 19:08:47 +00:00
|
|
|
* OpenOffice.org - a multi-platform office productivity suite
|
2004-11-16 11:04:18 +00:00
|
|
|
*
|
2005-09-08 19:08:47 +00:00
|
|
|
* $RCSfile: editpropertyhandler.cxx,v $
|
2004-11-16 11:04:18 +00:00
|
|
|
*
|
2006-09-16 12:15:42 +00:00
|
|
|
* $Revision: 1.7 $
|
2004-11-16 11:04:18 +00:00
|
|
|
*
|
2006-09-16 12:15:42 +00:00
|
|
|
* last change: $Author: obo $ $Date: 2006-09-16 13:15:42 $
|
2004-11-16 11:04:18 +00:00
|
|
|
*
|
2005-09-08 19:08:47 +00:00
|
|
|
* The Contents of this file are made available subject to
|
|
|
|
* the terms of GNU Lesser General Public License Version 2.1.
|
2004-11-16 11:04:18 +00:00
|
|
|
*
|
|
|
|
*
|
2005-09-08 19:08:47 +00:00
|
|
|
* GNU Lesser General Public License Version 2.1
|
|
|
|
* =============================================
|
|
|
|
* Copyright 2005 by Sun Microsystems, Inc.
|
|
|
|
* 901 San Antonio Road, Palo Alto, CA 94303, USA
|
2004-11-16 11:04:18 +00:00
|
|
|
*
|
2005-09-08 19:08:47 +00:00
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License version 2.1, as published by the Free Software Foundation.
|
2004-11-16 11:04:18 +00:00
|
|
|
*
|
2005-09-08 19:08:47 +00:00
|
|
|
* This library 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 for more details.
|
2004-11-16 11:04:18 +00:00
|
|
|
*
|
2005-09-08 19:08:47 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with this library; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
|
|
|
|
* MA 02111-1307 USA
|
2004-11-16 11:04:18 +00:00
|
|
|
*
|
|
|
|
************************************************************************/
|
|
|
|
|
2006-09-16 12:15:42 +00:00
|
|
|
// MARKER(update_precomp.py): autogen include statement, do not remove
|
|
|
|
#include "precompiled_extensions.hxx"
|
|
|
|
|
2004-11-16 11:04:18 +00:00
|
|
|
#ifndef EXTENSIONS_SOURCE_PROPCTRLR_EDITPROPERTYHANDLER_HXX
|
|
|
|
#include "editpropertyhandler.hxx"
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef _EXTENSIONS_FORMSCTRLR_FORMSTRINGS_HXX_
|
|
|
|
#include "formstrings.hxx"
|
|
|
|
#endif
|
|
|
|
#ifndef _EXTENSIONS_PROPCTRLR_FORMMETADATA_HXX_
|
|
|
|
#include "formmetadata.hxx"
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/** === begin UNO includes === **/
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
#ifndef _COM_SUN_STAR_INSPECTION_XOBJECTINSPECTORUI_HPP_
|
|
|
|
#include <com/sun/star/inspection/XObjectInspectorUI.hpp>
|
|
|
|
#endif
|
2004-11-16 11:04:18 +00:00
|
|
|
/** === end UNO includes === **/
|
|
|
|
|
|
|
|
#ifndef _TOOLS_DEBUG_HXX
|
|
|
|
#include <tools/debug.hxx>
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#define TEXTTYPE_SINGLELINE 0
|
|
|
|
#define TEXTTYPE_MULTILINE 1
|
|
|
|
#define TEXTTYPE_RICHTEXT 2
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
//------------------------------------------------------------------------
|
|
|
|
extern "C" void SAL_CALL createRegistryInfo_EditPropertyHandler()
|
|
|
|
{
|
|
|
|
::pcr::EditPropertyHandler::registerImplementation();
|
|
|
|
}
|
|
|
|
|
2004-11-16 11:04:18 +00:00
|
|
|
//........................................................................
|
|
|
|
namespace pcr
|
|
|
|
{
|
|
|
|
//........................................................................
|
|
|
|
|
|
|
|
using namespace ::com::sun::star::uno;
|
|
|
|
using namespace ::com::sun::star::lang;
|
|
|
|
using namespace ::com::sun::star::beans;
|
|
|
|
using namespace ::com::sun::star::script;
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
using namespace ::com::sun::star::frame;
|
|
|
|
using namespace ::com::sun::star::inspection;
|
2004-11-16 11:04:18 +00:00
|
|
|
|
|
|
|
//====================================================================
|
|
|
|
//= EditPropertyHandler
|
|
|
|
//====================================================================
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
DBG_NAME( EditPropertyHandler )
|
2004-11-16 11:04:18 +00:00
|
|
|
//--------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
EditPropertyHandler::EditPropertyHandler( const Reference< XComponentContext >& _rxContext )
|
|
|
|
:EditPropertyHandler_Base( _rxContext )
|
2004-11-16 11:04:18 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
DBG_CTOR( EditPropertyHandler, NULL );
|
2004-11-16 11:04:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
EditPropertyHandler::~EditPropertyHandler( )
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
DBG_DTOR( EditPropertyHandler, NULL );
|
2004-11-16 11:04:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
::rtl::OUString SAL_CALL EditPropertyHandler::getImplementationName_static( ) throw (RuntimeException)
|
2004-11-16 11:04:18 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
return ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "com.sun.star.comp.extensions.EditPropertyHandler" ) );
|
|
|
|
}
|
2004-11-16 11:04:18 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
//--------------------------------------------------------------------
|
|
|
|
Sequence< ::rtl::OUString > SAL_CALL EditPropertyHandler::getSupportedServiceNames_static( ) throw (RuntimeException)
|
|
|
|
{
|
|
|
|
Sequence< ::rtl::OUString > aSupported( 1 );
|
|
|
|
aSupported[0] = ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "com.sun.star.form.inspection.EditPropertyHandler" ) );
|
|
|
|
return aSupported;
|
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
Any SAL_CALL EditPropertyHandler::getPropertyValue( const ::rtl::OUString& _rPropertyName ) throw (UnknownPropertyException, RuntimeException)
|
|
|
|
{
|
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
|
|
|
PropertyId nPropId( impl_getPropertyId_throw( _rPropertyName ) );
|
|
|
|
|
|
|
|
Any aReturn;
|
2004-11-16 11:04:18 +00:00
|
|
|
try
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
switch ( nPropId )
|
2004-11-16 11:04:18 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_SHOW_SCROLLBARS:
|
|
|
|
{
|
|
|
|
sal_Bool bHasVScroll = sal_False;
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
m_xComponent->getPropertyValue( PROPERTY_VSCROLL ) >>= bHasVScroll;
|
2004-11-16 11:04:18 +00:00
|
|
|
sal_Bool bHasHScroll = sal_False;
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
m_xComponent->getPropertyValue( PROPERTY_HSCROLL ) >>= bHasHScroll;
|
2004-11-16 11:04:18 +00:00
|
|
|
|
|
|
|
aReturn <<= (sal_Int32)( ( bHasVScroll ? 2 : 0 ) + ( bHasHScroll ? 1 : 0 ) );
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_TEXTTYPE:
|
|
|
|
{
|
|
|
|
sal_Int32 nTextType = TEXTTYPE_SINGLELINE;
|
|
|
|
sal_Bool bRichText = sal_False;
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
OSL_VERIFY( m_xComponent->getPropertyValue( PROPERTY_RICHTEXT ) >>= bRichText );
|
2004-11-16 11:04:18 +00:00
|
|
|
if ( bRichText )
|
|
|
|
nTextType = TEXTTYPE_RICHTEXT;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
sal_Bool bMultiLine = sal_False;
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
OSL_VERIFY( m_xComponent->getPropertyValue( PROPERTY_MULTILINE ) >>= bMultiLine );
|
2004-11-16 11:04:18 +00:00
|
|
|
if ( bMultiLine )
|
|
|
|
nTextType = TEXTTYPE_MULTILINE;
|
|
|
|
else
|
|
|
|
nTextType = TEXTTYPE_SINGLELINE;
|
|
|
|
}
|
|
|
|
aReturn <<= nTextType;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
DBG_ERROR( "EditPropertyHandler::getPropertyValue: cannot handle this property!" );
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
break;
|
2004-11-16 11:04:18 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
catch( const Exception& )
|
|
|
|
{
|
|
|
|
OSL_ENSURE( sal_False, "EditPropertyHandler::getPropertyValue: caught an exception!" );
|
|
|
|
}
|
|
|
|
|
|
|
|
return aReturn;
|
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
void SAL_CALL EditPropertyHandler::setPropertyValue( const ::rtl::OUString& _rPropertyName, const Any& _rValue ) throw (UnknownPropertyException, RuntimeException)
|
2004-11-16 11:04:18 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
|
|
|
PropertyId nPropId( impl_getPropertyId_throw( _rPropertyName ) );
|
|
|
|
|
2004-11-16 11:04:18 +00:00
|
|
|
try
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
switch ( nPropId )
|
2004-11-16 11:04:18 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_SHOW_SCROLLBARS:
|
|
|
|
{
|
|
|
|
sal_Int32 nScrollbars = 0;
|
|
|
|
_rValue >>= nScrollbars;
|
|
|
|
|
|
|
|
sal_Bool bHasVScroll = 0 != ( nScrollbars & 2 );
|
|
|
|
sal_Bool bHasHScroll = 0 != ( nScrollbars & 1 );
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
m_xComponent->setPropertyValue( PROPERTY_VSCROLL, makeAny( (sal_Bool)bHasVScroll ) );
|
|
|
|
m_xComponent->setPropertyValue( PROPERTY_HSCROLL, makeAny( (sal_Bool)bHasHScroll ) );
|
2004-11-16 11:04:18 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_TEXTTYPE:
|
|
|
|
{
|
|
|
|
sal_Bool bMultiLine = sal_False;
|
|
|
|
sal_Bool bRichText = sal_False;
|
|
|
|
sal_Int32 nTextType = TEXTTYPE_SINGLELINE;
|
|
|
|
OSL_VERIFY( _rValue >>= nTextType );
|
|
|
|
switch ( nTextType )
|
|
|
|
{
|
|
|
|
case TEXTTYPE_SINGLELINE: bMultiLine = bRichText = sal_False; break;
|
|
|
|
case TEXTTYPE_MULTILINE: bMultiLine = sal_True; bRichText = sal_False; break;
|
|
|
|
case TEXTTYPE_RICHTEXT: bMultiLine = sal_True; bRichText = sal_True; break;
|
|
|
|
default:
|
|
|
|
OSL_ENSURE( sal_False, "EditPropertyHandler::setPropertyValue: invalid text type!" );
|
|
|
|
}
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
m_xComponent->setPropertyValue( PROPERTY_MULTILINE, makeAny( bMultiLine ) );
|
|
|
|
m_xComponent->setPropertyValue( PROPERTY_RICHTEXT, makeAny( bRichText ) );
|
2004-11-16 11:04:18 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
OSL_ENSURE( sal_False, "EditPropertyHandler::setPropertyValue: cannot handle this id!" );
|
|
|
|
}
|
|
|
|
}
|
|
|
|
catch( const Exception& )
|
|
|
|
{
|
|
|
|
OSL_ENSURE( sal_False, "EditPropertyHandler::setPropertyValue: caught an exception!" );
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
bool EditPropertyHandler::implHaveBothScrollBarProperties() const
|
|
|
|
{
|
|
|
|
// have a "Scrollbars" property if the object supports both "HScroll" and "VScroll"
|
|
|
|
Reference< XPropertySetInfo > xPSI;
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
if ( m_xComponent.is() )
|
|
|
|
xPSI = m_xComponent->getPropertySetInfo();
|
2004-11-16 11:04:18 +00:00
|
|
|
|
|
|
|
return xPSI.is()
|
|
|
|
&& xPSI->hasPropertyByName( PROPERTY_HSCROLL )
|
|
|
|
&& xPSI->hasPropertyByName( PROPERTY_VSCROLL );
|
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
bool EditPropertyHandler::implHaveTextTypeProperty() const
|
|
|
|
{
|
|
|
|
// have a "Scrollbars" property if the object supports both "HScroll" and "VScroll"
|
|
|
|
Reference< XPropertySetInfo > xPSI;
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
if ( m_xComponent.is() )
|
|
|
|
xPSI = m_xComponent->getPropertySetInfo();
|
2004-11-16 11:04:18 +00:00
|
|
|
|
|
|
|
return xPSI.is()
|
|
|
|
&& xPSI->hasPropertyByName( PROPERTY_RICHTEXT )
|
|
|
|
&& xPSI->hasPropertyByName( PROPERTY_MULTILINE );
|
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
Sequence< Property > SAL_CALL EditPropertyHandler::doDescribeSupportedProperties() const
|
2004-11-16 11:04:18 +00:00
|
|
|
{
|
|
|
|
::std::vector< Property > aProperties;
|
|
|
|
|
|
|
|
if ( implHaveBothScrollBarProperties() )
|
|
|
|
addInt32PropertyDescription( aProperties, PROPERTY_SHOW_SCROLLBARS );
|
|
|
|
|
|
|
|
if ( implHaveTextTypeProperty() )
|
|
|
|
addInt32PropertyDescription( aProperties, PROPERTY_TEXTTYPE );
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
if ( aProperties.empty() )
|
|
|
|
return Sequence< Property >();
|
|
|
|
return Sequence< Property >( &(*aProperties.begin()), aProperties.size() );
|
2004-11-16 11:04:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
Sequence< ::rtl::OUString > SAL_CALL EditPropertyHandler::getSupersededProperties( ) throw (RuntimeException)
|
2004-11-16 11:04:18 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2004-11-16 11:04:18 +00:00
|
|
|
::std::vector< ::rtl::OUString > aSuperseded;
|
|
|
|
if ( implHaveBothScrollBarProperties() )
|
|
|
|
{
|
|
|
|
aSuperseded.push_back( PROPERTY_HSCROLL );
|
|
|
|
aSuperseded.push_back( PROPERTY_VSCROLL );
|
|
|
|
}
|
|
|
|
if ( implHaveTextTypeProperty() )
|
|
|
|
{
|
|
|
|
aSuperseded.push_back( PROPERTY_RICHTEXT );
|
|
|
|
aSuperseded.push_back( PROPERTY_MULTILINE );
|
|
|
|
}
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
if ( aSuperseded.empty() )
|
|
|
|
return Sequence< ::rtl::OUString >();
|
|
|
|
return Sequence< ::rtl::OUString >( &(*aSuperseded.begin()), aSuperseded.size() );
|
2004-11-16 11:04:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
Sequence< ::rtl::OUString > SAL_CALL EditPropertyHandler::getActuatingProperties( ) throw (RuntimeException)
|
2004-11-16 11:04:18 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2004-11-16 11:04:18 +00:00
|
|
|
::std::vector< ::rtl::OUString > aInterestingActuatingProps;
|
|
|
|
if ( implHaveTextTypeProperty() )
|
|
|
|
aInterestingActuatingProps.push_back( PROPERTY_TEXTTYPE );
|
|
|
|
aInterestingActuatingProps.push_back( PROPERTY_MULTILINE );
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
return Sequence< ::rtl::OUString >( &(*aInterestingActuatingProps.begin()), aInterestingActuatingProps.size() );;
|
2004-11-16 11:04:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
2006-07-26 06:54:32 +00:00
|
|
|
void SAL_CALL EditPropertyHandler::actuatingPropertyChanged( const ::rtl::OUString& _rActuatingPropertyName, const Any& _rNewValue, const Any& /*_rOldValue*/, const Reference< XObjectInspectorUI >& _rxInspectorUI, sal_Bool ) throw (NullPointerException, RuntimeException)
|
2004-11-16 11:04:18 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
if ( !_rxInspectorUI.is() )
|
|
|
|
throw NullPointerException();
|
|
|
|
|
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
|
|
|
PropertyId nActuatingPropId( impl_getPropertyId_throw( _rActuatingPropertyName ) );
|
|
|
|
switch ( nActuatingPropId )
|
2004-11-16 11:04:18 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_TEXTTYPE:
|
|
|
|
{
|
|
|
|
sal_Int32 nTextType = TEXTTYPE_SINGLELINE;
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
getPropertyValue( PROPERTY_TEXTTYPE ) >>= nTextType;
|
|
|
|
|
|
|
|
if ( impl_isSupportedProperty_nothrow( PROPERTY_ID_WORDBREAK ) )
|
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_WORDBREAK, nTextType == TEXTTYPE_RICHTEXT );
|
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_MAXTEXTLEN, nTextType != TEXTTYPE_RICHTEXT );
|
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_ECHO_CHAR, nTextType == TEXTTYPE_SINGLELINE );
|
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_FONT_NAME, nTextType != TEXTTYPE_RICHTEXT );
|
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_ALIGN, nTextType != TEXTTYPE_RICHTEXT );
|
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_DEFAULT_TEXT, nTextType != TEXTTYPE_RICHTEXT );
|
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_SHOW_SCROLLBARS, nTextType != TEXTTYPE_SINGLELINE );
|
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_LINEEND_FORMAT, nTextType != TEXTTYPE_SINGLELINE );
|
|
|
|
|
|
|
|
_rxInspectorUI->showCategory( ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "Data" ) ), nTextType != TEXTTYPE_RICHTEXT );
|
2004-11-16 11:04:18 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_MULTILINE:
|
|
|
|
{
|
|
|
|
sal_Bool bIsMultiline = sal_False;
|
|
|
|
_rNewValue >>= bIsMultiline;
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/02/15 07:25:52 fs 1.3.88.13: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:38 fs 1.3.88.12: #i10000# exception specifications
2005/10/26 14:03:32 fs 1.3.88.11: some cleanups for finalizing #i53095#
2005/10/25 07:13:07 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:15 fs 1.3.88.9: some mutex locking
2005/10/13 13:01:00 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:59 fs 1.3.88.7: #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 06:53:25 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 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:38:57 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:09 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:43 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 13:59:56 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:20:48 +00:00
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_SHOW_SCROLLBARS, bIsMultiline );
|
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_ECHO_CHAR, !bIsMultiline );
|
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_LINEEND_FORMAT, bIsMultiline );
|
2004-11-16 11:04:18 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2005-03-23 10:55:43 +00:00
|
|
|
OSL_ENSURE( sal_False, "EditPropertyHandler::actuatingPropertyChanged: cannot handle this id!" );
|
2004-11-16 11:04:18 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//........................................................................
|
|
|
|
} // namespace pcr
|
|
|
|
//........................................................................
|
|
|
|
|