2004-11-16 11:05:15 +00:00
|
|
|
/*************************************************************************
|
|
|
|
|
*
|
2005-09-08 19:10:02 +00:00
|
|
|
* OpenOffice.org - a multi-platform office productivity suite
|
2004-11-16 11:05:15 +00:00
|
|
|
*
|
2005-09-08 19:10:02 +00:00
|
|
|
* $RCSfile: eformspropertyhandler.hxx,v $
|
2004-11-16 11:05:15 +00:00
|
|
|
*
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2005/11/02 11:43:40 fs 1.4.38.13: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:44 fs 1.4.38.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:15 fs 1.4.38.10: #i53095# some cleanup of remaining TODOs
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:05 fs 1.4.38.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:54:38 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:27 fs 1.4.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:51 +00:00
|
|
|
* $Revision: 1.6 $
|
2004-11-16 11:05:15 +00:00
|
|
|
*
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2005/11/02 11:43:40 fs 1.4.38.13: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:44 fs 1.4.38.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:15 fs 1.4.38.10: #i53095# some cleanup of remaining TODOs
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:05 fs 1.4.38.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:54:38 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:27 fs 1.4.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:51 +00:00
|
|
|
* last change: $Author: vg $ $Date: 2006-03-14 11:21:51 $
|
2004-11-16 11:05:15 +00:00
|
|
|
*
|
2005-09-08 19:10:02 +00:00
|
|
|
* The Contents of this file are made available subject to
|
|
|
|
|
* the terms of GNU Lesser General Public License Version 2.1.
|
2004-11-16 11:05:15 +00:00
|
|
|
*
|
|
|
|
|
*
|
2005-09-08 19:10:02 +00:00
|
|
|
* GNU Lesser General Public License Version 2.1
|
|
|
|
|
* =============================================
|
|
|
|
|
* Copyright 2005 by Sun Microsystems, Inc.
|
|
|
|
|
* 901 San Antonio Road, Palo Alto, CA 94303, USA
|
2004-11-16 11:05:15 +00:00
|
|
|
*
|
2005-09-08 19:10:02 +00:00
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
|
* License version 2.1, as published by the Free Software Foundation.
|
2004-11-16 11:05:15 +00:00
|
|
|
*
|
2005-09-08 19:10:02 +00:00
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
|
* Lesser General Public License for more details.
|
2004-11-16 11:05:15 +00:00
|
|
|
*
|
2005-09-08 19:10:02 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
|
* License along with this library; if not, write to the Free Software
|
|
|
|
|
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
|
|
|
|
|
* MA 02111-1307 USA
|
2004-11-16 11:05:15 +00:00
|
|
|
*
|
|
|
|
|
************************************************************************/
|
|
|
|
|
|
|
|
|
|
#ifndef EXTENSIONS_SOURCE_PROPCTRLR_EFORMSPROPERTYHANDLER_HXX
|
|
|
|
|
#define EXTENSIONS_SOURCE_PROPCTRLR_EFORMSPROPERTYHANDLER_HXX
|
|
|
|
|
|
|
|
|
|
#ifndef EXTENSIONS_SOURCE_PROPCTRLR_PROPERTYHANDLER_HXX
|
|
|
|
|
#include "propertyhandler.hxx"
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/** === begin UNO includes === **/
|
|
|
|
|
/** === end UNO includes === **/
|
|
|
|
|
|
|
|
|
|
#include <memory>
|
|
|
|
|
|
|
|
|
|
//........................................................................
|
|
|
|
|
namespace pcr
|
|
|
|
|
{
|
|
|
|
|
//........................................................................
|
|
|
|
|
|
|
|
|
|
class EFormsHelper;
|
|
|
|
|
//====================================================================
|
|
|
|
|
//= EFormsPropertyHandler
|
|
|
|
|
//====================================================================
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2005/11/02 11:43:40 fs 1.4.38.13: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:44 fs 1.4.38.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:15 fs 1.4.38.10: #i53095# some cleanup of remaining TODOs
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:05 fs 1.4.38.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:54:38 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:27 fs 1.4.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:51 +00:00
|
|
|
class EFormsPropertyHandler;
|
|
|
|
|
typedef HandlerComponentBase< EFormsPropertyHandler > EFormsPropertyHandler_Base;
|
|
|
|
|
class EFormsPropertyHandler : public EFormsPropertyHandler_Base
|
2004-11-16 11:05:15 +00:00
|
|
|
{
|
|
|
|
|
private:
|
|
|
|
|
::std::auto_ptr< EFormsHelper > m_pHelper;
|
2005-07-01 10:50:00 +00:00
|
|
|
/** current value of the Model property, if there is no binding, yet
|
|
|
|
|
*/
|
|
|
|
|
::rtl::OUString m_sBindingLessModelName;
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2005/11/02 11:43:40 fs 1.4.38.13: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:44 fs 1.4.38.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:15 fs 1.4.38.10: #i53095# some cleanup of remaining TODOs
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:05 fs 1.4.38.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:54:38 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:27 fs 1.4.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:51 +00:00
|
|
|
/** are we currently simulating a propertyChange event of the Model property?
|
|
|
|
|
*/
|
|
|
|
|
bool m_bSimulatingModelChange;
|
2004-11-16 11:05:15 +00:00
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
EFormsPropertyHandler(
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2005/11/02 11:43:40 fs 1.4.38.13: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:44 fs 1.4.38.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:15 fs 1.4.38.10: #i53095# some cleanup of remaining TODOs
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:05 fs 1.4.38.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:54:38 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:27 fs 1.4.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:51 +00:00
|
|
|
const ::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext >& _rxContext
|
2004-11-16 11:05:15 +00:00
|
|
|
);
|
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2005/11/02 11:43:40 fs 1.4.38.13: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:44 fs 1.4.38.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:15 fs 1.4.38.10: #i53095# some cleanup of remaining TODOs
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:05 fs 1.4.38.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:54:38 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:27 fs 1.4.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:51 +00:00
|
|
|
static ::rtl::OUString SAL_CALL getImplementationName_static( ) throw (::com::sun::star::uno::RuntimeException);
|
|
|
|
|
static ::com::sun::star::uno::Sequence< ::rtl::OUString > SAL_CALL getSupportedServiceNames_static( ) throw (::com::sun::star::uno::RuntimeException);
|
|
|
|
|
|
|
|
|
|
protected:
|
2004-11-16 11:05:15 +00:00
|
|
|
~EFormsPropertyHandler();
|
|
|
|
|
|
|
|
|
|
protected:
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2005/11/02 11:43:40 fs 1.4.38.13: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:44 fs 1.4.38.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:15 fs 1.4.38.10: #i53095# some cleanup of remaining TODOs
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:05 fs 1.4.38.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:54:38 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:27 fs 1.4.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:51 +00:00
|
|
|
// XPropertyHandler overriables
|
|
|
|
|
virtual ::com::sun::star::uno::Any SAL_CALL getPropertyValue( const ::rtl::OUString& _rPropertyName ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual void SAL_CALL setPropertyValue( const ::rtl::OUString& _rPropertyName, const ::com::sun::star::uno::Any& _rValue ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual ::com::sun::star::uno::Sequence< ::rtl::OUString >
|
|
|
|
|
SAL_CALL getActuatingProperties( ) throw (::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual void SAL_CALL describePropertyLine( const ::rtl::OUString& _rPropertyName, ::com::sun::star::inspection::LineDescriptor& /* [out] */ _rDescriptor, const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControlFactory >& _rxControlFactory ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::lang::NullPointerException, ::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual ::com::sun::star::inspection::InteractiveSelectionResult
|
|
|
|
|
SAL_CALL onInteractivePropertySelection( const ::rtl::OUString& _rPropertyName, sal_Bool _bPrimary, ::com::sun::star::uno::Any& _rData, const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XObjectInspectorUI >& _rxInspectorUI ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::lang::NullPointerException, ::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual void SAL_CALL actuatingPropertyChanged( const ::rtl::OUString& _rActuatingPropertyName, const ::com::sun::star::uno::Any& _rNewValue, const ::com::sun::star::uno::Any& _rOldValue, const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XObjectInspectorUI >& _rxInspectorUI, sal_Bool ) throw (::com::sun::star::lang::NullPointerException, ::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual ::com::sun::star::uno::Any SAL_CALL convertToPropertyValue( const ::rtl::OUString& _rPropertyName, const ::com::sun::star::uno::Any& _rControlValue ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual ::com::sun::star::uno::Any SAL_CALL convertToControlValue( const ::rtl::OUString& _rPropertyName, const ::com::sun::star::uno::Any& _rPropertyValue, const ::com::sun::star::uno::Type& _rControlValueType ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual void SAL_CALL addPropertyChangeListener( const ::com::sun::star::uno::Reference< ::com::sun::star::beans::XPropertyChangeListener >& _rxListener ) throw (::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual void SAL_CALL removePropertyChangeListener( const ::com::sun::star::uno::Reference< ::com::sun::star::beans::XPropertyChangeListener >& _rxListener ) throw (::com::sun::star::uno::RuntimeException);
|
2004-11-16 11:05:15 +00:00
|
|
|
|
|
|
|
|
// PropertyHandler overridables
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2005/11/02 11:43:40 fs 1.4.38.13: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:44 fs 1.4.38.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:15 fs 1.4.38.10: #i53095# some cleanup of remaining TODOs
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:05 fs 1.4.38.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:54:38 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:27 fs 1.4.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:51 +00:00
|
|
|
virtual ::com::sun::star::uno::Sequence< ::com::sun::star::beans::Property >
|
|
|
|
|
SAL_CALL doDescribeSupportedProperties() const;
|
|
|
|
|
virtual void onNewComponent();
|
2005-07-01 10:50:00 +00:00
|
|
|
|
|
|
|
|
protected:
|
|
|
|
|
/** returns the value of the PROPERTY_XML_DATA_MODEL property.
|
|
|
|
|
|
|
|
|
|
An extra method is necessary here, which respects both the value set at our helper,
|
|
|
|
|
and <member>m_sBindingLessModelName</member>
|
|
|
|
|
*/
|
|
|
|
|
::rtl::OUString getModelNamePropertyValue() const;
|
2004-11-16 11:05:15 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
//........................................................................
|
|
|
|
|
} // namespace pcr
|
|
|
|
|
//........................................................................
|
|
|
|
|
|
|
|
|
|
#endif // EXTENSIONS_SOURCE_PROPCTRLR_EFORMSPROPERTYHANDLER_HXX
|
|
|
|
|
|