INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
/*************************************************************************
|
|
|
|
|
*
|
|
|
|
|
* OpenOffice.org - a multi-platform office productivity suite
|
|
|
|
|
*
|
|
|
|
|
* $RCSfile: handlerhelper.cxx,v $
|
|
|
|
|
*
|
2008-01-14 13:59:27 +00:00
|
|
|
* $Revision: 1.8 $
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
*
|
2008-01-14 13:59:27 +00:00
|
|
|
* last change: $Author: ihi $ $Date: 2008-01-14 14:59:27 $
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
*
|
|
|
|
|
* The Contents of this file are made available subject to
|
|
|
|
|
* the terms of GNU Lesser General Public License Version 2.1.
|
|
|
|
|
*
|
|
|
|
|
*
|
|
|
|
|
* GNU Lesser General Public License Version 2.1
|
|
|
|
|
* =============================================
|
|
|
|
|
* Copyright 2005 by Sun Microsystems, Inc.
|
|
|
|
|
* 901 San Antonio Road, Palo Alto, CA 94303, USA
|
|
|
|
|
*
|
|
|
|
|
* 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.
|
|
|
|
|
*
|
|
|
|
|
* 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.
|
|
|
|
|
*
|
|
|
|
|
* 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
|
|
|
|
|
*
|
|
|
|
|
************************************************************************/
|
|
|
|
|
|
2006-09-16 12:19:01 +00:00
|
|
|
// MARKER(update_precomp.py): autogen include statement, do not remove
|
|
|
|
|
#include "precompiled_extensions.hxx"
|
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
#ifndef EXTENSIONS_SOURCE_PROPCTRLR_HANDLERHELPER_HXX
|
|
|
|
|
#include "handlerhelper.hxx"
|
|
|
|
|
#endif
|
2006-12-13 10:59:48 +00:00
|
|
|
#ifndef EXTENSIONS_PROPRESID_HRC
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
#include "propresid.hrc"
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef _COMPHELPER_EXTRACT_HXX_
|
|
|
|
|
#include <comphelper/extract.hxx>
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef _EXTENSIONS_PROPCTRLR_MODULEPRC_HXX_
|
|
|
|
|
#include "modulepcr.hxx"
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef EXTENSIONS_SOURCE_PROPCTRLR_ENUMREPRESENTATION_HXX
|
|
|
|
|
#include "enumrepresentation.hxx"
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef _EXTENSIONS_PROPCTRLR_FORMMETADATA_HXX_
|
|
|
|
|
#include "formmetadata.hxx"
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef EXTENSIONS_SOURCE_PROPCTRLR_PCROMPONENTCONTEXT_HXX
|
|
|
|
|
#include "pcrcomponentcontext.hxx"
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/** === begin UNO includes === **/
|
2007-07-06 07:49:40 +00:00
|
|
|
#ifndef _COM_SUN_STAR_INSPECTION_STRINGREPRESENTATION_HPP_
|
|
|
|
|
#include "com/sun/star/inspection/StringRepresentation.hpp"
|
|
|
|
|
#endif
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
#ifndef _COM_SUN_STAR_BEANS_PROPERTYATTRIBUTE_HPP_
|
|
|
|
|
#include <com/sun/star/beans/PropertyAttribute.hpp>
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef _COM_SUN_STAR_UNO_XCOMPONENTCONTEXT_HPP_
|
|
|
|
|
#include <com/sun/star/uno/XComponentContext.hpp>
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef _COM_SUN_STAR_UTIL_XMODIFIABLE_HPP_
|
|
|
|
|
#include <com/sun/star/util/XModifiable.hpp>
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef _COM_SUN_STAR_AWT_XWINDOW_HPP_
|
|
|
|
|
#include <com/sun/star/awt/XWindow.hpp>
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef _COM_SUN_STAR_INSPECTION_LINEDESCRIPTOR_HPP_
|
|
|
|
|
#include <com/sun/star/inspection/LineDescriptor.hpp>
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef _COM_SUN_STAR_INSPECTION_PROPERTYCONTROLTYPE_HPP_
|
|
|
|
|
#include <com/sun/star/inspection/PropertyControlType.hpp>
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef _COM_SUN_STAR_INSPECTION_XSTRINGLISTCONTROL_HPP_
|
|
|
|
|
#include <com/sun/star/inspection/XStringListControl.hpp>
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef _COM_SUN_STAR_INSPECTION_XNUMERICCONTROL_HPP_
|
|
|
|
|
#include <com/sun/star/inspection/XNumericControl.hpp>
|
|
|
|
|
#endif
|
|
|
|
|
/** === end UNO includes === **/
|
|
|
|
|
|
|
|
|
|
#ifndef _TOOLS_DEBUG_HXX
|
|
|
|
|
#include <tools/debug.hxx>
|
|
|
|
|
#endif
|
2008-01-14 13:59:27 +00:00
|
|
|
#ifndef TOOLS_DIAGNOSE_EX_H
|
|
|
|
|
#include <tools/diagnose_ex.h>
|
|
|
|
|
#endif
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
#ifndef _TOOLKIT_HELPER_VCLUNOHELPER_HXX_
|
|
|
|
|
#include <toolkit/helper/vclunohelper.hxx>
|
|
|
|
|
#endif
|
|
|
|
|
|
2006-12-13 15:57:36 +00:00
|
|
|
#include <algorithm>
|
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
//........................................................................
|
|
|
|
|
namespace pcr
|
|
|
|
|
{
|
|
|
|
|
//........................................................................
|
|
|
|
|
|
|
|
|
|
using namespace ::com::sun::star::uno;
|
|
|
|
|
using namespace ::com::sun::star::lang;
|
|
|
|
|
using namespace ::com::sun::star::awt;
|
|
|
|
|
using namespace ::com::sun::star::util;
|
|
|
|
|
using namespace ::com::sun::star::beans;
|
|
|
|
|
using namespace ::com::sun::star::script;
|
|
|
|
|
using namespace ::com::sun::star::inspection;
|
|
|
|
|
|
|
|
|
|
//====================================================================
|
|
|
|
|
//= PropertyHandlerHelper
|
|
|
|
|
//====================================================================
|
|
|
|
|
//--------------------------------------------------------------------
|
2006-07-26 06:58:12 +00:00
|
|
|
void PropertyHandlerHelper::describePropertyLine( const Property& _rProperty,
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
LineDescriptor& /* [out] */ _out_rDescriptor, const Reference< XPropertyControlFactory >& _rxControlFactory )
|
|
|
|
|
{
|
|
|
|
|
// display the pure property name - no L10N
|
|
|
|
|
_out_rDescriptor.DisplayName = _rProperty.Name;
|
|
|
|
|
|
|
|
|
|
OSL_PRECOND( _rxControlFactory.is(), "PropertyHandlerHelper::describePropertyLine: no factory -> no control!" );
|
|
|
|
|
if ( !_rxControlFactory.is() )
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
sal_Bool bReadOnlyControl = requiresReadOnlyControl( _rProperty.Attributes );
|
|
|
|
|
|
2006-12-13 15:57:36 +00:00
|
|
|
// special handling for booleans (this will become a list)
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
if ( _rProperty.Type.getTypeClass() == TypeClass_BOOLEAN )
|
|
|
|
|
{
|
|
|
|
|
String aBoolOptions = String( PcrRes( RID_STR_BOOL ) );
|
|
|
|
|
Sequence< ::rtl::OUString > aEntries(2);
|
|
|
|
|
for ( xub_StrLen i=0; i<2; ++i )
|
|
|
|
|
aEntries[i] = aBoolOptions.GetToken( i );
|
2006-12-13 15:57:36 +00:00
|
|
|
_out_rDescriptor.Control = createListBoxControl( _rxControlFactory, aEntries, bReadOnlyControl, sal_False );
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
sal_Int16 nControlType = PropertyControlType::TextField;
|
|
|
|
|
switch ( _rProperty.Type.getTypeClass() )
|
|
|
|
|
{
|
|
|
|
|
case TypeClass_BYTE:
|
|
|
|
|
case TypeClass_SHORT:
|
|
|
|
|
case TypeClass_UNSIGNED_SHORT:
|
|
|
|
|
case TypeClass_LONG:
|
|
|
|
|
case TypeClass_UNSIGNED_LONG:
|
|
|
|
|
case TypeClass_HYPER:
|
|
|
|
|
case TypeClass_UNSIGNED_HYPER:
|
|
|
|
|
case TypeClass_FLOAT:
|
|
|
|
|
case TypeClass_DOUBLE:
|
|
|
|
|
nControlType = PropertyControlType::NumericField;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case TypeClass_SEQUENCE:
|
|
|
|
|
nControlType = PropertyControlType::StringListField;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
DBG_ERROR( "PropertyHandlerHelper::describePropertyLine: don't know how to represent this at the UI!" );
|
|
|
|
|
// NO break!
|
|
|
|
|
|
|
|
|
|
case TypeClass_STRING:
|
|
|
|
|
nControlType = PropertyControlType::TextField;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// create a control
|
|
|
|
|
_out_rDescriptor.Control = _rxControlFactory->createPropertyControl( nControlType, bReadOnlyControl );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
|
namespace
|
|
|
|
|
{
|
|
|
|
|
Reference< XPropertyControl > lcl_implCreateListLikeControl(
|
|
|
|
|
const Reference< XPropertyControlFactory >& _rxControlFactory,
|
|
|
|
|
const ::std::vector< ::rtl::OUString >& _rInitialListEntries,
|
|
|
|
|
sal_Bool _bReadOnlyControl,
|
2006-12-13 15:57:36 +00:00
|
|
|
sal_Bool _bSorted,
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
sal_Bool _bTrueIfListBoxFalseIfComboBox
|
|
|
|
|
)
|
|
|
|
|
{
|
|
|
|
|
Reference< XStringListControl > xListControl(
|
|
|
|
|
_rxControlFactory->createPropertyControl(
|
|
|
|
|
_bTrueIfListBoxFalseIfComboBox ? PropertyControlType::ListBox : PropertyControlType::ComboBox, _bReadOnlyControl
|
|
|
|
|
),
|
|
|
|
|
UNO_QUERY_THROW
|
|
|
|
|
);
|
|
|
|
|
|
2006-12-13 15:57:36 +00:00
|
|
|
::std::vector< ::rtl::OUString > aInitialEntries( _rInitialListEntries );
|
|
|
|
|
if ( _bSorted )
|
|
|
|
|
::std::sort( aInitialEntries.begin(), aInitialEntries.end() );
|
|
|
|
|
|
|
|
|
|
for ( ::std::vector< ::rtl::OUString >::const_iterator loop = aInitialEntries.begin();
|
|
|
|
|
loop != aInitialEntries.end();
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
++loop
|
|
|
|
|
)
|
|
|
|
|
xListControl->appendListEntry( *loop );
|
|
|
|
|
return xListControl.get();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
|
Reference< XPropertyControl > PropertyHandlerHelper::createListBoxControl( const Reference< XPropertyControlFactory >& _rxControlFactory,
|
2006-12-13 15:57:36 +00:00
|
|
|
const Sequence< ::rtl::OUString >& _rInitialListEntries, sal_Bool _bReadOnlyControl, sal_Bool _bSorted )
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
{
|
|
|
|
|
::std::vector< ::rtl::OUString > aAsVector( _rInitialListEntries.getConstArray(), _rInitialListEntries.getConstArray() + _rInitialListEntries.getLength() );
|
2006-12-13 15:57:36 +00:00
|
|
|
return lcl_implCreateListLikeControl( _rxControlFactory, aAsVector, _bReadOnlyControl, _bSorted, sal_True );
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
|
Reference< XPropertyControl > PropertyHandlerHelper::createListBoxControl( const Reference< XPropertyControlFactory >& _rxControlFactory,
|
2006-12-13 15:57:36 +00:00
|
|
|
const ::std::vector< ::rtl::OUString >& _rInitialListEntries, sal_Bool _bReadOnlyControl, sal_Bool _bSorted )
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
{
|
2006-12-13 15:57:36 +00:00
|
|
|
return lcl_implCreateListLikeControl( _rxControlFactory, _rInitialListEntries, _bReadOnlyControl, _bSorted, sal_True );
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
|
Reference< XPropertyControl > PropertyHandlerHelper::createComboBoxControl( const Reference< XPropertyControlFactory >& _rxControlFactory,
|
2006-12-13 15:57:36 +00:00
|
|
|
const Sequence< ::rtl::OUString >& _rInitialListEntries, sal_Bool _bReadOnlyControl, sal_Bool _bSorted )
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
{
|
|
|
|
|
::std::vector< ::rtl::OUString > aAsVector( _rInitialListEntries.getConstArray(), _rInitialListEntries.getConstArray() + _rInitialListEntries.getLength() );
|
2006-12-13 15:57:36 +00:00
|
|
|
return lcl_implCreateListLikeControl( _rxControlFactory, aAsVector, _bReadOnlyControl, _bSorted, sal_False );
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
|
Reference< XPropertyControl > PropertyHandlerHelper::createComboBoxControl( const Reference< XPropertyControlFactory >& _rxControlFactory,
|
2006-12-13 15:57:36 +00:00
|
|
|
const ::std::vector< ::rtl::OUString >& _rInitialListEntries, sal_Bool _bReadOnlyControl, sal_Bool _bSorted )
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
{
|
2006-12-13 15:57:36 +00:00
|
|
|
return lcl_implCreateListLikeControl( _rxControlFactory, _rInitialListEntries, _bReadOnlyControl, _bSorted, sal_False );
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
|
Reference< XPropertyControl > PropertyHandlerHelper::createNumericControl( const Reference< XPropertyControlFactory >& _rxControlFactory,
|
|
|
|
|
sal_Int16 _nDigits, const Optional< double >& _rMinValue, const Optional< double >& _rMaxValue, sal_Bool _bReadOnlyControl )
|
|
|
|
|
{
|
|
|
|
|
Reference< XNumericControl > xNumericControl(
|
|
|
|
|
_rxControlFactory->createPropertyControl( PropertyControlType::NumericField, _bReadOnlyControl ),
|
|
|
|
|
UNO_QUERY_THROW
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
xNumericControl->setDecimalDigits( _nDigits );
|
|
|
|
|
xNumericControl->setMinValue( _rMinValue );
|
|
|
|
|
xNumericControl->setMaxValue( _rMaxValue );
|
|
|
|
|
|
|
|
|
|
return xNumericControl.get();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
2007-07-06 07:49:40 +00:00
|
|
|
Any PropertyHandlerHelper::convertToPropertyValue( const Reference< XComponentContext >& _rxContext,const Reference< XTypeConverter >& _rxTypeConverter,
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
const Property& _rProperty, const Any& _rControlValue )
|
|
|
|
|
{
|
|
|
|
|
Any aPropertyValue( _rControlValue );
|
|
|
|
|
if ( !aPropertyValue.hasValue() )
|
|
|
|
|
// NULL is converted to NULL
|
|
|
|
|
return aPropertyValue;
|
|
|
|
|
|
|
|
|
|
if ( aPropertyValue.getValueType().equals( _rProperty.Type ) )
|
|
|
|
|
// nothing to do, type is already as desired
|
|
|
|
|
return aPropertyValue;
|
|
|
|
|
|
|
|
|
|
if ( _rControlValue.getValueType().getTypeClass() == TypeClass_STRING )
|
|
|
|
|
{
|
|
|
|
|
::rtl::OUString sControlValue;
|
|
|
|
|
_rControlValue >>= sControlValue;
|
|
|
|
|
|
2007-07-06 07:49:40 +00:00
|
|
|
Reference< XStringRepresentation > xConversionHelper = StringRepresentation::create( _rxContext,_rxTypeConverter );
|
|
|
|
|
aPropertyValue = xConversionHelper->convertToPropertyValue( sControlValue, _rProperty.Type );
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
try
|
|
|
|
|
{
|
|
|
|
|
if ( _rxTypeConverter.is() )
|
|
|
|
|
aPropertyValue = _rxTypeConverter->convertTo( _rControlValue, _rProperty.Type );
|
|
|
|
|
}
|
|
|
|
|
catch( const Exception& )
|
|
|
|
|
{
|
|
|
|
|
OSL_ENSURE( sal_False, "PropertyHandlerHelper::convertToPropertyValue: caught an exception while converting via TypeConverter!" );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return aPropertyValue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
2007-07-06 07:49:40 +00:00
|
|
|
Any PropertyHandlerHelper::convertToControlValue( const Reference< XComponentContext >& _rxContext,const Reference< XTypeConverter >& _rxTypeConverter,
|
2006-07-26 06:58:12 +00:00
|
|
|
const Any& _rPropertyValue, const Type& _rControlValueType )
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
{
|
|
|
|
|
Any aControlValue( _rPropertyValue );
|
|
|
|
|
if ( !aControlValue.hasValue() )
|
|
|
|
|
// NULL is converted to NULL
|
|
|
|
|
return aControlValue;
|
|
|
|
|
|
|
|
|
|
if ( _rControlValueType.getTypeClass() == TypeClass_STRING )
|
|
|
|
|
{
|
2007-07-06 07:49:40 +00:00
|
|
|
Reference< XStringRepresentation > xConversionHelper = StringRepresentation::create( _rxContext,_rxTypeConverter );
|
|
|
|
|
aControlValue <<= xConversionHelper->convertToControlValue( _rPropertyValue );
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
try
|
|
|
|
|
{
|
|
|
|
|
if ( _rxTypeConverter.is() )
|
|
|
|
|
aControlValue = _rxTypeConverter->convertTo( _rPropertyValue, _rControlValueType );
|
|
|
|
|
}
|
|
|
|
|
catch( const Exception& )
|
|
|
|
|
{
|
|
|
|
|
OSL_ENSURE( sal_False, "PropertyHandlerHelper::convertToControlValue: caught an exception while converting via TypeConverter!" );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return aControlValue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
|
void PropertyHandlerHelper::setContextDocumentModified( const ComponentContext& _rContext )
|
|
|
|
|
{
|
|
|
|
|
try
|
|
|
|
|
{
|
|
|
|
|
Reference< XModifiable > xDocumentModifiable( _rContext.getContextValueByAsciiName( "ContextDocument" ), UNO_QUERY_THROW );
|
|
|
|
|
xDocumentModifiable->setModified( sal_True );
|
|
|
|
|
}
|
2008-01-14 13:59:27 +00:00
|
|
|
catch( const Exception& )
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
{
|
2008-01-14 13:59:27 +00:00
|
|
|
DBG_UNHANDLED_EXCEPTION();
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
|
Window* PropertyHandlerHelper::getDialogParentWindow( const ComponentContext& _rContext )
|
|
|
|
|
{
|
|
|
|
|
Window* pInspectorWindow = NULL;
|
|
|
|
|
try
|
|
|
|
|
{
|
|
|
|
|
Reference< XWindow > xInspectorWindow( _rContext.getContextValueByAsciiName( "DialogParentWindow" ), UNO_QUERY_THROW );
|
|
|
|
|
pInspectorWindow = VCLUnoHelper::GetWindow( xInspectorWindow );
|
|
|
|
|
}
|
2008-01-14 13:59:27 +00:00
|
|
|
catch( const Exception& )
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
{
|
2008-01-14 13:59:27 +00:00
|
|
|
DBG_UNHANDLED_EXCEPTION();
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #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/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:03 fs 1.1.2.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:25:27 +00:00
|
|
|
}
|
|
|
|
|
return pInspectorWindow;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//........................................................................
|
|
|
|
|
} // namespace pcr
|
|
|
|
|
//........................................................................
|