mir/libreoffice
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f4f11f0a47acceba1b75f52ef8f9e77486eb3747
libreoffice/extensions/source/propctrlr/propcontroller.hxx

436 lines
21 KiB
C++
Raw Normal View History

initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
/*************************************************************************
*
INTEGRATION: CWS ooo19126 (1.27.56); FILE MERGED 2005/09/05 13:00:30 rt 1.27.56.1: #i54170# Change license header: remove SISSL
2005-09-08 19:23:27 +00:00
* OpenOffice.org - a multi-platform office productivity suite
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
*
INTEGRATION: CWS ooo19126 (1.27.56); FILE MERGED 2005/09/05 13:00:30 rt 1.27.56.1: #i54170# Change license header: remove SISSL
2005-09-08 19:23:27 +00:00
* $RCSfile: propcontroller.hxx,v $
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
*
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
* $Revision: 1.30 $
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
*
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
* last change: $Author: vg $ $Date: 2006-03-14 11:29:34 $
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
*
INTEGRATION: CWS ooo19126 (1.27.56); FILE MERGED 2005/09/05 13:00:30 rt 1.27.56.1: #i54170# Change license header: remove SISSL
2005-09-08 19:23:27 +00:00
* The Contents of this file are made available subject to
* the terms of GNU Lesser General Public License Version 2.1.
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
*
*
INTEGRATION: CWS ooo19126 (1.27.56); FILE MERGED 2005/09/05 13:00:30 rt 1.27.56.1: #i54170# Change license header: remove SISSL
2005-09-08 19:23:27 +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
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
*
INTEGRATION: CWS ooo19126 (1.27.56); FILE MERGED 2005/09/05 13:00:30 rt 1.27.56.1: #i54170# Change license header: remove SISSL
2005-09-08 19:23:27 +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.
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
*
INTEGRATION: CWS ooo19126 (1.27.56); FILE MERGED 2005/09/05 13:00:30 rt 1.27.56.1: #i54170# Change license header: remove SISSL
2005-09-08 19:23:27 +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.
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
*
INTEGRATION: CWS ooo19126 (1.27.56); FILE MERGED 2005/09/05 13:00:30 rt 1.27.56.1: #i54170# Change license header: remove SISSL
2005-09-08 19:23:27 +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
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
*
************************************************************************/
#ifndef _EXTENSIONS_PROPCTRLR_PROPCONTROLLER_HXX_
#define _EXTENSIONS_PROPCTRLR_PROPCONTROLLER_HXX_
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
#ifndef EXTENSIONS_SOURCE_PROPCTRLR_COMPOSEDUIUPDATE_HXX
#include "composeduiupdate.hxx"
#endif
#ifndef _EXTENSIONS_FORMSCTRLR_FORMBROWSERTOOLS_HXX_
#include "formbrowsertools.hxx"
#endif
#ifndef _EXTENSIONS_PROPCTRLR_FORMMETADATA_HXX_
#include "formmetadata.hxx"
#endif
#ifndef _EXTENSIONS_PROPCTRLR_PROPLINELISTENER_HXX_
#include "proplinelistener.hxx"
#endif
#ifndef _EXTENSIONS_PROPCTRLR_BROWSERVIEW_HXX_
#include "browserview.hxx"
#endif
#ifndef _EXTENSIONS_PROPCTRLR_MODULEPCR_HXX_
#include "modulepcr.hxx"
#endif
#ifndef _EXTENSIONS_PROPCTRLR_PROPERTYINFO_HXX_
#include "propertyinfo.hxx"
#endif
#ifndef EXTENSIONS_SOURCE_PROPCTRLR_PCROMPONENTCONTEXT_HXX
#include "pcrcomponentcontext.hxx"
#endif
/** === begin UNO includes === **/
#86838# be a focus listener on the container window, forward the focus to the property box
2001-05-30 12:41:46 +00:00
#ifndef _COM_SUN_STAR_AWT_XFOCUSLISTENER_HPP_
#include <com/sun/star/awt/XFocusListener.hpp>
#endif
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
#ifndef _COM_SUN_STAR_BEANS_XPROPERTYSTATE_HPP_
#include <com/sun/star/beans/XPropertyState.hpp>
#endif
#ifndef _COM_SUN_STAR_BEANS_XPROPERTYSET_HPP_
#include <com/sun/star/beans/XPropertySet.hpp>
#endif
INTEGRATION: CWS formdesign01 (1.18.8); FILE MERGED 2004/03/03 09:20:36 fs 1.18.8.10: corrected some small issues discovered during pre-QA 2003/12/18 13:06:39 fs 1.18.8.9: #i22878# easier input of selection / default selection with dedicated dialog 2003/12/17 10:38:25 fs 1.18.8.8: #i22878# filter and sort order dialog from within the property browser 2003/12/15 07:55:22 fs 1.18.8.7: #i23418# linking master/detail form via a dedicated dialog 2003/12/04 14:11:38 fs 1.18.8.6: #i23190# graphically design SQL commands, using the usual query design UI 2003/12/03 10:06:42 fs 1.18.8.5: #i22878# measurement units for Width and RowHeight 2003/11/27 14:47:29 fs 1.18.8.4: #i22878# file URL display and date input 2003/11/27 10:21:13 fs 1.18.8.3: #i22878# added TabOrder dialog handling 2003/11/26 15:57:44 fs 1.18.8.2: #i22878# implementations for disabling property controls depending on other property's values 2003/11/26 11:40:05 fs 1.18.8.1: #i22878# implementations for disabling property controls depending on other property's values
2004-03-19 11:05:47 +00:00
#ifndef _COM_SUN_STAR_BEANS_XPROPERTYCHANGELISTENER_HPP_
#include <com/sun/star/beans/XPropertyChangeListener.hpp>
#endif
#87690# don't set connections on rowsets permanently - instead dispose connections which we created ourself upon switching to a new object
2001-08-06 13:52:59 +00:00
#ifndef _COM_SUN_STAR_LANG_XMULTISERVICEFACTORY_HPP_
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
#include <com/sun/star/lang/XMultiServiceFactory.hpp>
#87690# don't set connections on rowsets permanently - instead dispose connections which we created ourself upon switching to a new object
2001-08-06 13:52:59 +00:00
#endif
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
#ifndef _COM_SUN_STAR_UNO_XCOMPONENTCONTEXT_HPP_
#include <com/sun/star/uno/XComponentContext.hpp>
#endif
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
#ifndef _COM_SUN_STAR_FORM_XFORM_HPP_
#include <com/sun/star/form/XForm.hpp>
#endif
#ifndef _COM_SUN_STAR_SCRIPT_XEVENTATTACHERMANAGER_HPP_
#include <com/sun/star/script/XEventAttacherManager.hpp>
#endif
#90958# +getRowSet / +ensureRowsetConnection
2001-08-13 14:45:53 +00:00
#ifndef _COM_SUN_STAR_SDBC_XROWSET_HPP_
#include <com/sun/star/sdbc/XRowSet.hpp>
#endif
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
#ifndef _COM_SUN_STAR_UNO_SEQUENCE_HXX_
#include <com/sun/star/uno/Sequence.hxx>
#endif
#ifndef _COM_SUN_STAR_FRAME_XCONTROLLER_HPP_
#include <com/sun/star/frame/XController.hpp>
#endif
#ifndef _COM_SUN_STAR_LANG_XSERVICEINFO_HPP_
#include <com/sun/star/lang/XServiceInfo.hpp>
#endif
#87690# don't set connections on rowsets permanently - instead dispose connections which we created ourself upon switching to a new object
2001-08-06 13:52:59 +00:00
#ifndef _COM_SUN_STAR_LANG_XEVENTLISTENER_HPP_
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
#include <com/sun/star/lang/XEventListener.hpp>
#87690# don't set connections on rowsets permanently - instead dispose connections which we created ourself upon switching to a new object
2001-08-06 13:52:59 +00:00
#endif
#ifndef _COM_SUN_STAR_SDBC_XCONNECTION_HPP_
#include <com/sun/star/sdbc/XConnection.hpp>
#endif
#95343# (on behalf of sleepybear@openoffice.org) implemented XLayoutConstraints
2002-11-12 11:12:36 +00:00
#ifndef _COM_SUN_STAR_AWT_XLAYOUTCONSTRAINS_HPP_
#include <com/sun/star/awt/XLayoutConstrains.hpp>
#endif
preparations for #95343# - support the XLayoutConstraints interface
2001-12-13 08:14:26 +00:00
#ifndef _COM_SUN_STAR_AWT_XLAYOUTCONSTRAINS_HPP_
#include <com/sun/star/awt/XLayoutConstrains.hpp>
#endif
INTEGRATION: CWS formdesign01 (1.18.8); FILE MERGED 2004/03/03 09:20:36 fs 1.18.8.10: corrected some small issues discovered during pre-QA 2003/12/18 13:06:39 fs 1.18.8.9: #i22878# easier input of selection / default selection with dedicated dialog 2003/12/17 10:38:25 fs 1.18.8.8: #i22878# filter and sort order dialog from within the property browser 2003/12/15 07:55:22 fs 1.18.8.7: #i23418# linking master/detail form via a dedicated dialog 2003/12/04 14:11:38 fs 1.18.8.6: #i23190# graphically design SQL commands, using the usual query design UI 2003/12/03 10:06:42 fs 1.18.8.5: #i22878# measurement units for Width and RowHeight 2003/11/27 14:47:29 fs 1.18.8.4: #i22878# file URL display and date input 2003/11/27 10:21:13 fs 1.18.8.3: #i22878# added TabOrder dialog handling 2003/11/26 15:57:44 fs 1.18.8.2: #i22878# implementations for disabling property controls depending on other property's values 2003/11/26 11:40:05 fs 1.18.8.1: #i22878# implementations for disabling property controls depending on other property's values
2004-03-19 11:05:47 +00:00
#ifndef _COM_SUN_STAR_AWT_XCONTROLCONTAINER_HPP_
#include <com/sun/star/awt/XControlContainer.hpp>
#endif
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
#ifndef _COM_SUN_STAR_INSPECTION_XPROPERTYCONTROLFACTORY_HPP_
#include <com/sun/star/inspection/XPropertyControlFactory.hpp>
INTEGRATION: CWS formdesign01 (1.18.8); FILE MERGED 2004/03/03 09:20:36 fs 1.18.8.10: corrected some small issues discovered during pre-QA 2003/12/18 13:06:39 fs 1.18.8.9: #i22878# easier input of selection / default selection with dedicated dialog 2003/12/17 10:38:25 fs 1.18.8.8: #i22878# filter and sort order dialog from within the property browser 2003/12/15 07:55:22 fs 1.18.8.7: #i23418# linking master/detail form via a dedicated dialog 2003/12/04 14:11:38 fs 1.18.8.6: #i23190# graphically design SQL commands, using the usual query design UI 2003/12/03 10:06:42 fs 1.18.8.5: #i22878# measurement units for Width and RowHeight 2003/11/27 14:47:29 fs 1.18.8.4: #i22878# file URL display and date input 2003/11/27 10:21:13 fs 1.18.8.3: #i22878# added TabOrder dialog handling 2003/11/26 15:57:44 fs 1.18.8.2: #i22878# implementations for disabling property controls depending on other property's values 2003/11/26 11:40:05 fs 1.18.8.1: #i22878# implementations for disabling property controls depending on other property's values
2004-03-19 11:05:47 +00:00
#endif
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
#ifndef _COM_SUN_STAR_INSPECTION_XOBJECTINSPECTOR_HPP_
#include <com/sun/star/inspection/XObjectInspector.hpp>
#endif
#ifndef _COM_SUN_STAR_INSPECTION_XOBJECTINSPECTORUI_HPP_
#include <com/sun/star/inspection/XObjectInspectorUI.hpp>
#endif
#ifndef _COM_SUN_STAR_INSPECTION_XPROPERTYHANDLER_HPP_
#include <com/sun/star/inspection/XPropertyHandler.hpp>
#endif
/** === end UNO includes === **/
INTEGRATION: CWS dba201b (1.27.12); FILE MERGED 2005/09/21 08:14:49 oj 1.27.12.2: RESYNC: (1.27-1.28); FILE MERGED 2005/07/21 12:03:56 fs 1.27.12.1: refined connection handling in the course of #i52255#, where the semantics of ::dbtools::connectRowset was extended to also care for connections of the rowset is embedded in a database form document
2005-09-23 11:52:18 +00:00
#ifndef _CONNECTIVITY_DBTOOLS_HXX_
#include <connectivity/dbtools.hxx>
#endif
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
#ifndef _CPPUHELPER_INTERFACECONTAINER_HXX_
#include <cppuhelper/interfacecontainer.hxx>
#endif
#ifndef _CPPUHELPER_IMPLBASE7_HXX_
#include <cppuhelper/implbase7.hxx>
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
#endif
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
#ifndef _COMPHELPER_BROADCASTHELPER_HXX_
#include <comphelper/broadcasthelper.hxx>
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
#endif
#include <map>
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
#include <hash_map>
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
#include <vector>
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
#include <memory>
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
class SvNumberFormatsSupplierObj;
class Font;
class Window;
#86096# +implGetInt32FontProperty / +implInvalidateItem
2001-06-06 07:14:28 +00:00
class SfxItemSet;
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
//............................................................................
namespace pcr
{
//............................................................................
class OPropertyEditor;
struct OLineDescriptor;
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
#if OSL_DEBUG_LEVEL > 0
const char* CheckPropertyBrowserInvariants( const void* pVoid );
// for dignostics with DBG_CHKTHIS
#endif
DBG_NAMEEX( OPropertyBrowserController )
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
//========================================================================
//= OPropertyBrowserController
//========================================================================
#95343# (on behalf of sleepybear@openoffice.org) implemented XLayoutConstraints
2002-11-12 11:12:36 +00:00
// #95343#------------------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
typedef ::cppu::WeakImplHelper7 < ::com::sun::star::lang::XServiceInfo
#86838# be a focus listener on the container window, forward the focus to the property box
2001-05-30 12:41:46 +00:00
, ::com::sun::star::awt::XFocusListener
preparations for #95343# - support the XLayoutConstraints interface
2001-12-13 08:14:26 +00:00
, ::com::sun::star::awt::XLayoutConstrains
INTEGRATION: CWS formdesign01 (1.18.8); FILE MERGED 2004/03/03 09:20:36 fs 1.18.8.10: corrected some small issues discovered during pre-QA 2003/12/18 13:06:39 fs 1.18.8.9: #i22878# easier input of selection / default selection with dedicated dialog 2003/12/17 10:38:25 fs 1.18.8.8: #i22878# filter and sort order dialog from within the property browser 2003/12/15 07:55:22 fs 1.18.8.7: #i23418# linking master/detail form via a dedicated dialog 2003/12/04 14:11:38 fs 1.18.8.6: #i23190# graphically design SQL commands, using the usual query design UI 2003/12/03 10:06:42 fs 1.18.8.5: #i22878# measurement units for Width and RowHeight 2003/11/27 14:47:29 fs 1.18.8.4: #i22878# file URL display and date input 2003/11/27 10:21:13 fs 1.18.8.3: #i22878# added TabOrder dialog handling 2003/11/26 15:57:44 fs 1.18.8.2: #i22878# implementations for disabling property controls depending on other property's values 2003/11/26 11:40:05 fs 1.18.8.1: #i22878# implementations for disabling property controls depending on other property's values
2004-03-19 11:05:47 +00:00
, ::com::sun::star::beans::XPropertyChangeListener
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
, ::com::sun::star::inspection::XPropertyControlFactory
, ::com::sun::star::inspection::XObjectInspectorUI
, ::com::sun::star::inspection::XObjectInspector
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
> OPropertyBrowserController_Base;
class OPropertyBrowserController
:public ::comphelper::OMutexAndBroadcastHelper
,public OPropertyBrowserController_Base
,public IPropertyLineListener
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
,public IPropertyExistenceCheck
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
{
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
private:
typedef ::std::map< sal_Int32, ::com::sun::star::beans::Property > OrderedPropertyMap;
typedef ::std::vector< ::com::sun::star::uno::Reference< ::com::sun::star::uno::XInterface > >
InterfaceArray;
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
protected:
ComponentContext m_aContext;
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
private:
::com::sun::star::uno::Reference< ::com::sun::star::frame::XFrame > m_xFrame;
::com::sun::star::uno::Reference< ::com::sun::star::awt::XWindow > m_xView;
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
::cppu::OInterfaceContainerHelper m_aDisposeListeners;
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
// meta data about the properties
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
OPropertyBrowserView* m_pView;
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
::rtl::OUString m_sPageSelection;
::rtl::OUString m_sLastValidPageSelection;
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
typedef ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyHandler >
PropertyHandlerRef;
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
typedef ::std::vector< PropertyHandlerRef > PropertyHandlerArray;
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
typedef ::std::hash_map< ::rtl::OUString, PropertyHandlerRef, ::rtl::OUStringHash >
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
PropertyHandlerRepository;
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
typedef ::std::hash_multimap< ::rtl::OUString, PropertyHandlerRef, ::rtl::OUStringHash >
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
PropertyHandlerMultiRepository;
PropertyHandlerRepository m_aPropertyHandlers;
PropertyHandlerMultiRepository m_aDependencyHandlers;
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
::std::auto_ptr< ComposedPropertyUIUpdate > m_pUIRequestComposer;
/// our InspectorModel
::com::sun::star::uno::Reference< ::com::sun::star::inspection::XObjectInspectorModel >
m_xModel;
/// the object(s) we're currently inspecting
InterfaceArray m_aInspectedObjects;
/// the properties of the currently inspected object(s)
OrderedPropertyMap m_aProperties;
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
/// the property we're just committing
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
::rtl::OUString m_sCommittingProperty;
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
typedef ::std::hash_map< ::rtl::OUString, sal_uInt16, ::rtl::OUStringHash > HashString2Int16;
HashString2Int16 m_aPageIds;
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
bool m_bContainerFocusListening : 1;
bool m_bSuspendingPropertyHandlers : 1;
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
protected:
// XServiceInfo
virtual ::rtl::OUString SAL_CALL getImplementationName( ) throw(::com::sun::star::uno::RuntimeException);
virtual sal_Bool SAL_CALL supportsService( const ::rtl::OUString& ServiceName ) throw(::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::uno::Sequence< ::rtl::OUString > SAL_CALL getSupportedServiceNames( ) throw(::com::sun::star::uno::RuntimeException);
// XController
virtual void SAL_CALL attachFrame( const ::com::sun::star::uno::Reference< ::com::sun::star::frame::XFrame >& xFrame ) throw(::com::sun::star::uno::RuntimeException);
virtual sal_Bool SAL_CALL attachModel( const ::com::sun::star::uno::Reference< ::com::sun::star::frame::XModel >& xModel ) throw(::com::sun::star::uno::RuntimeException);
virtual sal_Bool SAL_CALL suspend( sal_Bool bSuspend ) throw(::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::uno::Any SAL_CALL getViewData( ) throw(::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL restoreViewData( const ::com::sun::star::uno::Any& Data ) throw(::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::uno::Reference< ::com::sun::star::frame::XModel > SAL_CALL getModel( ) throw(::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::uno::Reference< ::com::sun::star::frame::XFrame > SAL_CALL getFrame( ) throw(::com::sun::star::uno::RuntimeException);
// XComponent
virtual void SAL_CALL dispose( ) throw(::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL addEventListener( const ::com::sun::star::uno::Reference< ::com::sun::star::lang::XEventListener >& xListener ) throw(::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL removeEventListener( const ::com::sun::star::uno::Reference< ::com::sun::star::lang::XEventListener >& aListener ) throw(::com::sun::star::uno::RuntimeException);
#86838# be a focus listener on the container window, forward the focus to the property box
2001-05-30 12:41:46 +00:00
// XFocusListener
virtual void SAL_CALL focusGained( const ::com::sun::star::awt::FocusEvent& _rSource ) throw (::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL focusLost( const ::com::sun::star::awt::FocusEvent& _rSource ) throw (::com::sun::star::uno::RuntimeException);
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
// XEventListener
virtual void SAL_CALL disposing( const ::com::sun::star::lang::EventObject& Source ) throw(::com::sun::star::uno::RuntimeException);
#95343# (on behalf of sleepybear@openoffice.org) implemented XLayoutConstraints
2002-11-12 11:12:36 +00:00
// XLayoutConstrains #95343# ----------------
preparations for #95343# - support the XLayoutConstraints interface
2001-12-13 08:14:26 +00:00
virtual ::com::sun::star::awt::Size SAL_CALL getMinimumSize( ) throw (::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::awt::Size SAL_CALL getPreferredSize( ) throw (::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::awt::Size SAL_CALL calcAdjustedSize( const ::com::sun::star::awt::Size& aNewSize ) throw (::com::sun::star::uno::RuntimeException);
INTEGRATION: CWS formdesign01 (1.18.8); FILE MERGED 2004/03/03 09:20:36 fs 1.18.8.10: corrected some small issues discovered during pre-QA 2003/12/18 13:06:39 fs 1.18.8.9: #i22878# easier input of selection / default selection with dedicated dialog 2003/12/17 10:38:25 fs 1.18.8.8: #i22878# filter and sort order dialog from within the property browser 2003/12/15 07:55:22 fs 1.18.8.7: #i23418# linking master/detail form via a dedicated dialog 2003/12/04 14:11:38 fs 1.18.8.6: #i23190# graphically design SQL commands, using the usual query design UI 2003/12/03 10:06:42 fs 1.18.8.5: #i22878# measurement units for Width and RowHeight 2003/11/27 14:47:29 fs 1.18.8.4: #i22878# file URL display and date input 2003/11/27 10:21:13 fs 1.18.8.3: #i22878# added TabOrder dialog handling 2003/11/26 15:57:44 fs 1.18.8.2: #i22878# implementations for disabling property controls depending on other property's values 2003/11/26 11:40:05 fs 1.18.8.1: #i22878# implementations for disabling property controls depending on other property's values
2004-03-19 11:05:47 +00:00
// XPropertyChangeListener
virtual void SAL_CALL propertyChange( const ::com::sun::star::beans::PropertyChangeEvent& _rEvent ) throw (::com::sun::star::uno::RuntimeException);
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
/** XPropertyControlFactory
*/
virtual ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl > SAL_CALL createPropertyControl( ::sal_Int16 ControlType, ::sal_Bool CreateReadOnly ) throw (::com::sun::star::lang::IllegalArgumentException, ::com::sun::star::uno::RuntimeException);
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
public:
OPropertyBrowserController(
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
const ::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext >& _rxContext);
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
protected:
virtual ~OPropertyBrowserController();
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
public:
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
// XServiceInfo - static versions
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
static ::rtl::OUString getImplementationName_static( ) throw(::com::sun::star::uno::RuntimeException);
static ::com::sun::star::uno::Sequence< ::rtl::OUString > getSupportedServiceNames_static( ) throw(::com::sun::star::uno::RuntimeException);
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
static ::com::sun::star::uno::Reference< ::com::sun::star::uno::XInterface > SAL_CALL
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
Create(const ::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext >&);
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
protected:
// IPropertyLineListener
virtual void Clicked( const ::rtl::OUString& _rName, sal_Bool _bPrimary );
virtual void Commit( const ::rtl::OUString& _rName, const ::com::sun::star::uno::Any& _rVal );
// IPropertyExistenceCheck
virtual ::sal_Bool SAL_CALL hasPropertyByName( const ::rtl::OUString& _rName ) throw (::com::sun::star::uno::RuntimeException);
// XObjectInspectorUI
virtual void SAL_CALL enablePropertyUI( const ::rtl::OUString& _rPropertyName, ::sal_Bool _bEnable ) throw (::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL enablePropertyUIElements( const ::rtl::OUString& _rPropertyName, ::sal_Int16 _nElements, ::sal_Bool _bEnable ) throw (::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL rebuildPropertyUI( const ::rtl::OUString& _rPropertyName ) throw (::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL showPropertyUI( const ::rtl::OUString& _rPropertyName ) throw (::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL hidePropertyUI( const ::rtl::OUString& _rPropertyName ) throw (::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL showCategory( const ::rtl::OUString& _rCategory, ::sal_Bool _bShow ) throw (::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl > SAL_CALL getPropertyControl( const ::rtl::OUString& _rPropertyName ) throw (::com::sun::star::uno::RuntimeException);
// XObjectInspector
virtual ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XObjectInspectorModel > SAL_CALL getInspectorModel() throw (::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL setInspectorModel( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XObjectInspectorModel >& _inspectormodel ) throw (::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL inspect( const ::com::sun::star::uno::Sequence< ::com::sun::star::uno::Reference< ::com::sun::star::uno::XInterface > >& Objects ) throw (::com::sun::star::util::VetoException, ::com::sun::star::uno::RuntimeException);
// XDispatchProvider
virtual ::com::sun::star::uno::Reference< ::com::sun::star::frame::XDispatch > SAL_CALL queryDispatch( const ::com::sun::star::util::URL& URL, const ::rtl::OUString& TargetFrameName, ::sal_Int32 SearchFlags ) throw (::com::sun::star::uno::RuntimeException);
virtual ::com::sun::star::uno::Sequence< ::com::sun::star::uno::Reference< ::com::sun::star::frame::XDispatch > > SAL_CALL queryDispatches( const ::com::sun::star::uno::Sequence< ::com::sun::star::frame::DispatchDescriptor >& Requests ) throw (::com::sun::star::uno::RuntimeException);
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
private:
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
void UpdateUI();
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
#86838# be a focus listener on the container window, forward the focus to the property box
2001-05-30 12:41:46 +00:00
void startContainerWindowListening();
void stopContainerWindowListening();
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
// stop the inspection
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
void stopInspection( bool _bCommitModified );
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
sal_Bool haveView() const { return NULL != m_pView; }
OPropertyEditor* getPropertyBox() { return m_pView->getPropertyBox(); }
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
// does the inspection of the objects as indicated by our model
void doInspection();
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
// bind the browser to m_xIntrospecteeAsProperty
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
void rebindToInspectee( const InterfaceArray& _rObjects );
INTEGRATION: CWS formcelllinkage (1.17.94); FILE MERGED 2003/10/01 09:17:57 fs 1.17.94.1: #i18994# merging the changes from the CWS fs002
2003-10-21 08:06:45 +00:00
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
/** retrieves special property handlers for our introspectee
INTEGRATION: CWS formcelllinkage (1.17.94); FILE MERGED 2003/10/01 09:17:57 fs 1.17.94.1: #i18994# merging the changes from the CWS fs002
2003-10-21 08:06:45 +00:00
*/
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
void getPropertyHandlers( const InterfaceArray& _rObjects, PropertyHandlerArray& _rHandlers );
INTEGRATION: CWS frmcontrols02 (1.18.32); FILE MERGED 2004/03/24 10:03:54 fs 1.18.32.3: RESYNC: (1.18-1.19); FILE MERGED 2004/02/02 07:46:11 fs 1.18.32.2: #i24415# 2004/01/23 17:33:12 fs 1.18.32.1: removed obsolete parameter from ChangeFontProperty
2004-04-13 10:24:38 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
/** called when a property changed, to broadcast any handlers which might have
registered for this property
INTEGRATION: CWS dbabetap2 (1.21.54); FILE MERGED 2004/11/12 16:38:27 fs 1.21.54.1: #i37089# in updateComplexPropertyDependencies, care whether a real property change instigated this
2004-11-26 17:27:01 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
@param _bFirstTimeInit
if set to <FALSE/>, this is a real change in the property value, not just a call
for purposes of initialization.
INTEGRATION: CWS formcelllinkage (1.17.94); FILE MERGED 2003/10/01 09:17:57 fs 1.17.94.1: #i18994# merging the changes from the CWS fs002
2003-10-21 08:06:45 +00:00
*/
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
void impl_broadcastPropertyChange_nothrow( const ::rtl::OUString& _rPropertyName, const ::com::sun::star::uno::Any& _rNewValue, const ::com::sun::star::uno::Any& _rOldValue, bool _bFirstTimeInit ) const;
INTEGRATION: CWS formcelllinkage (1.17.94); FILE MERGED 2003/10/01 09:17:57 fs 1.17.94.1: #i18994# merging the changes from the CWS fs002
2003-10-21 08:06:45 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
/** determines whether the given property is an actuating property, that is, at least one
handler expressed interest in changes to this property's value.
INTEGRATION: CWS formdesign01 (1.18.8); FILE MERGED 2004/03/03 09:20:36 fs 1.18.8.10: corrected some small issues discovered during pre-QA 2003/12/18 13:06:39 fs 1.18.8.9: #i22878# easier input of selection / default selection with dedicated dialog 2003/12/17 10:38:25 fs 1.18.8.8: #i22878# filter and sort order dialog from within the property browser 2003/12/15 07:55:22 fs 1.18.8.7: #i23418# linking master/detail form via a dedicated dialog 2003/12/04 14:11:38 fs 1.18.8.6: #i23190# graphically design SQL commands, using the usual query design UI 2003/12/03 10:06:42 fs 1.18.8.5: #i22878# measurement units for Width and RowHeight 2003/11/27 14:47:29 fs 1.18.8.4: #i22878# file URL display and date input 2003/11/27 10:21:13 fs 1.18.8.3: #i22878# added TabOrder dialog handling 2003/11/26 15:57:44 fs 1.18.8.2: #i22878# implementations for disabling property controls depending on other property's values 2003/11/26 11:40:05 fs 1.18.8.1: #i22878# implementations for disabling property controls depending on other property's values
2004-03-19 11:05:47 +00:00
*/
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
inline bool impl_isActuatingProperty_nothrow( const ::rtl::OUString& _rPropertyName ) const
{
return ( m_aDependencyHandlers.find( _rPropertyName ) != m_aDependencyHandlers.end() );
}
#84694# +recalcConnection
2001-04-12 05:28:14 +00:00
INTEGRATION: CWS formcelllinkage (1.17.94); FILE MERGED 2003/10/01 09:17:57 fs 1.17.94.1: #i18994# merging the changes from the CWS fs002
2003-10-21 08:06:45 +00:00
sal_uInt32 GetPropertyPos(const ::rtl::OUString& _rPropName);
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
/** retrieves the value of the given property, by asking the appropriate XPropertyHandler
@param _rPropertyName
the name whose handler is to be obtained. Must be the name of a property
for which a handler is registered.
@throws
RuntimeException if there is no handler for the given property
@return
the value of this property
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
*/
INTEGRATION: CWS formcelllinkage (1.17.94); FILE MERGED 2003/10/01 09:17:57 fs 1.17.94.1: #i18994# merging the changes from the CWS fs002
2003-10-21 08:06:45 +00:00
::com::sun::star::uno::Any
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
impl_getPropertyValue_throw( const ::rtl::OUString& _rPropertyName );
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
/// calls XPropertyHandler::suspend for all our property handlers
sal_Bool suspendPropertyHandlers_nothrow( sal_Bool _bSuspend );
#83649# correctly eval the return value of getIntrospecteeProperty / #84041# infrastructure for activating pages from outside
2001-02-19 13:08:05 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
/** selects a page according to our current view data
*/
void selectPageFromViewData();
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
/** updates our view data from the currently active page
*/
void updateViewDataFromActivePage();
INTEGRATION: CWS formdesign01 (1.18.8); FILE MERGED 2004/03/03 09:20:36 fs 1.18.8.10: corrected some small issues discovered during pre-QA 2003/12/18 13:06:39 fs 1.18.8.9: #i22878# easier input of selection / default selection with dedicated dialog 2003/12/17 10:38:25 fs 1.18.8.8: #i22878# filter and sort order dialog from within the property browser 2003/12/15 07:55:22 fs 1.18.8.7: #i23418# linking master/detail form via a dedicated dialog 2003/12/04 14:11:38 fs 1.18.8.6: #i23190# graphically design SQL commands, using the usual query design UI 2003/12/03 10:06:42 fs 1.18.8.5: #i22878# measurement units for Width and RowHeight 2003/11/27 14:47:29 fs 1.18.8.4: #i22878# file URL display and date input 2003/11/27 10:21:13 fs 1.18.8.3: #i22878# added TabOrder dialog handling 2003/11/26 15:57:44 fs 1.18.8.2: #i22878# implementations for disabling property controls depending on other property's values 2003/11/26 11:40:05 fs 1.18.8.1: #i22878# implementations for disabling property controls depending on other property's values
2004-03-19 11:05:47 +00:00
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
/// describes the UI for the given property
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
void describePropertyLine( const ::com::sun::star::beans::Property& _rPropertyName, OLineDescriptor& _rDescriptor )
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
SAL_THROW((::com::sun::star::uno::Exception));
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
/** retrieves the position of the property given by name in m_aProperties
@return
<TRUE/> if and only if the property could be found. In this case, <arg>_pProperty</arg> (if
not <NULL/> contains the iterator pointing to this property.
INTEGRATION: CWS formdesign01 (1.18.8); FILE MERGED 2004/03/03 09:20:36 fs 1.18.8.10: corrected some small issues discovered during pre-QA 2003/12/18 13:06:39 fs 1.18.8.9: #i22878# easier input of selection / default selection with dedicated dialog 2003/12/17 10:38:25 fs 1.18.8.8: #i22878# filter and sort order dialog from within the property browser 2003/12/15 07:55:22 fs 1.18.8.7: #i23418# linking master/detail form via a dedicated dialog 2003/12/04 14:11:38 fs 1.18.8.6: #i23190# graphically design SQL commands, using the usual query design UI 2003/12/03 10:06:42 fs 1.18.8.5: #i22878# measurement units for Width and RowHeight 2003/11/27 14:47:29 fs 1.18.8.4: #i22878# file URL display and date input 2003/11/27 10:21:13 fs 1.18.8.3: #i22878# added TabOrder dialog handling 2003/11/26 15:57:44 fs 1.18.8.2: #i22878# implementations for disabling property controls depending on other property's values 2003/11/26 11:40:05 fs 1.18.8.1: #i22878# implementations for disabling property controls depending on other property's values
2004-03-19 11:05:47 +00:00
*/
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
bool impl_findObjectProperty_nothrow( const ::rtl::OUString& _rName, OrderedPropertyMap::const_iterator* _pProperty = NULL );
INTEGRATION: CWS formdesign01 (1.18.8); FILE MERGED 2004/03/03 09:20:36 fs 1.18.8.10: corrected some small issues discovered during pre-QA 2003/12/18 13:06:39 fs 1.18.8.9: #i22878# easier input of selection / default selection with dedicated dialog 2003/12/17 10:38:25 fs 1.18.8.8: #i22878# filter and sort order dialog from within the property browser 2003/12/15 07:55:22 fs 1.18.8.7: #i23418# linking master/detail form via a dedicated dialog 2003/12/04 14:11:38 fs 1.18.8.6: #i23190# graphically design SQL commands, using the usual query design UI 2003/12/03 10:06:42 fs 1.18.8.5: #i22878# measurement units for Width and RowHeight 2003/11/27 14:47:29 fs 1.18.8.4: #i22878# file URL display and date input 2003/11/27 10:21:13 fs 1.18.8.3: #i22878# added TabOrder dialog handling 2003/11/26 15:57:44 fs 1.18.8.2: #i22878# implementations for disabling property controls depending on other property's values 2003/11/26 11:40:05 fs 1.18.8.1: #i22878# implementations for disabling property controls depending on other property's values
2004-03-19 11:05:47 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
sal_Bool Construct(Window* _pParentWin);
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
/** retrieves the property handler for a given property name
@param _rPropertyName
the name whose handler is to be obtained. Must be the name of a property
for which a handler is registered.
@throws
RuntimeException if there is no handler for the given property
@return
the handler which is responsible for the given property
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
*/
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
PropertyHandlerRef
impl_getHandlerForProperty_throw( const ::rtl::OUString& _rPropertyName ) const;
/** builds up m_aPageIds from InspectorModel::describeCategories, and insert all the
respective tab pages into our view
@precond
m_aPageIds is empty
@throws ::com::sun::star::uno::RuntimeException
if one of the callees of this method throws this exception
*/
void
impl_buildCategories_throw();
/** retrieves the id of the tab page which represents a given category.
@param _rCategoryName
the programmatic name of a category.
@return
the id of the tab page, or <code>(sal_uInt16)-1</code> if there
is no tab page for the given category
INTEGRATION: CWS eforms2 (1.19.22); FILE MERGED 2004/11/03 12:03:17 fs 1.19.22.8: #i10000# make compile on unxsols4 2004/08/16 17:05:38 dvo 1.19.22.7: RESYNC: (1.20-1.21); FILE MERGED 2004/07/21 11:24:18 fs 1.19.22.6: #i31762# support for inspecting multiple objects 2004/07/21 07:54:33 fs 1.19.22.5: some consolidation in preparation of #i31762# 2004/07/12 14:32:21 fs 1.19.22.4: #114856# 2004/06/29 14:24:06 dvo 1.19.22.3: RESYNC: (1.19-1.20); FILE MERGED 2004/04/27 14:15:48 fs 1.19.22.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:42:39 fs 1.19.22.1: conceptual change: no 'virtual' properties anymore, but instead dedicated 'handlers' for properties, which care for all the set/getPropertyValue, building the UI, etc.
2004-11-16 11:10:28 +00:00
*/
sal_uInt16
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
impl_getPageIdForCategory_nothrow( const ::rtl::OUString& _rCategoryName ) const;
INTEGRATION: CWS formdesign01 (1.18.8); FILE MERGED 2004/03/03 09:20:36 fs 1.18.8.10: corrected some small issues discovered during pre-QA 2003/12/18 13:06:39 fs 1.18.8.9: #i22878# easier input of selection / default selection with dedicated dialog 2003/12/17 10:38:25 fs 1.18.8.8: #i22878# filter and sort order dialog from within the property browser 2003/12/15 07:55:22 fs 1.18.8.7: #i23418# linking master/detail form via a dedicated dialog 2003/12/04 14:11:38 fs 1.18.8.6: #i23190# graphically design SQL commands, using the usual query design UI 2003/12/03 10:06:42 fs 1.18.8.5: #i22878# measurement units for Width and RowHeight 2003/11/27 14:47:29 fs 1.18.8.4: #i22878# file URL display and date input 2003/11/27 10:21:13 fs 1.18.8.3: #i22878# added TabOrder dialog handling 2003/11/26 15:57:44 fs 1.18.8.2: #i22878# implementations for disabling property controls depending on other property's values 2003/11/26 11:40:05 fs 1.18.8.1: #i22878# implementations for disabling property controls depending on other property's values
2004-03-19 11:05:47 +00:00
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED 2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories 2005/10/31 13:45:58 fs 1.27.38.21: some cleanup 2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095# 2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs 2005/10/17 08:17:02 fs 1.27.38.14: #i53095# 2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:36 fs 1.27.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 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED 2005/09/05 07:41:53 fs 1.27.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:33 fs 1.27.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:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.27.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:47 fs 1.27.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 14:00:04 fs 1.27.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:29:34 +00:00
/** adds or removes ourself as XEventListener to/from all our inspectees
*/
void impl_toggleInspecteeListening_nothrow( bool _bOn );
#92755# Assign Standard Values for Basic Controls in Designmode
2001-10-19 11:58:51 +00:00
#83649# correctly eval the return value of getIntrospecteeProperty / #84041# infrastructure for activating pages from outside
2001-02-19 13:08:05 +00:00
private:
DECL_LINK(OnPageActivation, void*);
initial checkin - outsourced the form property browser
2001-01-12 10:35:45 +00:00
};
//............................................................................
} // namespace pcr
//............................................................................
#endif // _EXTENSIONS_PROPCTRLR_PROPCONTROLLER_HXX_
Reference in New Issue Copy Permalink