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

1770 lines
72 KiB
C++
Raw Normal View History

/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
/*************************************************************************
*
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* Copyright 2000, 2010 Oracle and/or its affiliates.
*
* OpenOffice.org - a multi-platform office productivity suite
*
* This file is part of OpenOffice.org.
*
* OpenOffice.org is free software: you can redistribute it and/or modify
* it under the terms of the GNU Lesser General Public License version 3
* only, as published by the Free Software Foundation.
*
* OpenOffice.org is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Lesser General Public License version 3 for more details
* (a copy is included in the LICENSE file that accompanied this code).
*
* You should have received a copy of the GNU Lesser General Public License
* version 3 along with OpenOffice.org. If not, see
* <http://www.openoffice.org/license.html>
* for a copy of the LGPLv3 License.
*
************************************************************************/
#include "propcontroller.hxx"
#include "pcrstrings.hxx"
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
#include "standardcontrol.hxx"
#include "linedescriptor.hxx"
#include "propresid.hrc"
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
#include "formresid.hrc"
#include "propertyeditor.hxx"
#include "modulepcr.hxx"
#include "formstrings.hxx"
#include "formmetadata.hxx"
#include "formbrowsertools.hxx"
#include "propertycomposer.hxx"
#include <com/sun/star/awt/XWindow.hpp>
#include <com/sun/star/util/XCloseable.hpp>
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
#include <com/sun/star/inspection/PropertyControlType.hpp>
#include <com/sun/star/ucb/AlreadyInitializedException.hpp>
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
#include <tools/debug.hxx>
#include <tools/diagnose_ex.h>
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
#include <comphelper/types.hxx>
#include <comphelper/extract.hxx>
#include <toolkit/awt/vclxwindow.hxx>
#include <toolkit/unohlp.hxx>
2001-02-05 07:58:27 +00:00
#include <comphelper/property.hxx>
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
#include <vcl/msgbox.hxx>
#include <vcl/svapp.hxx>
#include <osl/mutex.hxx>
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
#include <cppuhelper/component_context.hxx>
#include <cppuhelper/exc_hlp.hxx>
#include <algorithm>
#include <functional>
2010-10-15 18:15:35 +01:00
#include <sal/macros.h>
//------------------------------------------------------------------------
// !!! outside the namespace !!!
extern "C" void SAL_CALL createRegistryInfo_OPropertyBrowserController()
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
::pcr::OAutoRegistration< ::pcr::OPropertyBrowserController > aAutoRegistration;
}
//............................................................................
namespace pcr
{
//............................................................................
using namespace ::com::sun::star;
using namespace ::com::sun::star::uno;
using namespace ::com::sun::star::awt;
using namespace ::com::sun::star::form;
using namespace ::com::sun::star::beans;
using namespace ::com::sun::star::script;
using namespace ::com::sun::star::lang;
using namespace ::com::sun::star::container;
using namespace ::com::sun::star::frame;
using namespace ::com::sun::star::util;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
using namespace ::com::sun::star::inspection;
using namespace ::com::sun::star::ucb;
using namespace ::comphelper;
#define THISREF() static_cast< XController* >(this)
//========================================================================
//= OPropertyBrowserController
//========================================================================
2001-01-18 13:45:10 +00:00
DBG_NAME(OPropertyBrowserController)
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
OPropertyBrowserController::OPropertyBrowserController( const Reference< XComponentContext >& _rxContext )
:m_aContext(_rxContext)
,m_aDisposeListeners( m_aMutex )
,m_aControlObservers( m_aMutex )
,m_pView(NULL)
,m_bContainerFocusListening( false )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
,m_bSuspendingPropertyHandlers( false )
,m_bConstructed( false )
CWS-TOOLING: integrate CWS dba32g 2009-09-09 07:53:55 +0200 oj r275964 : replace strlen with rtl_str_getLength 2009-09-07 20:59:10 +0200 fs r275913 : disable the CopyTableWizard test until issue 104869 is fixed 2009-09-07 12:17:31 +0200 oj r275885 : #i104810# remove de as lang 2009-09-05 22:26:21 +0200 fs r275857 : protect StateChanged against re-entrance 2009-09-05 22:25:52 +0200 fs r275856 : don't attempt to classify the parent of a form as control 2009-09-05 22:25:29 +0200 fs r275855 : protect against re-entrance 2009-09-05 00:11:40 +0200 fs r275835 : #i10000# 2009-09-04 23:25:50 +0200 fs r275834 : #i10000# 2009-09-04 23:23:47 +0200 fs r275833 : #i10000# 2009-09-04 21:49:37 +0200 fs r275830 : #i10000# correct wrong conflict resolution 2009-09-04 20:59:51 +0200 fs r275829 : CWS-TOOLING: rebase CWS dba32g to trunk@275801 (milestone: DEV300:m57) 2009-09-04 11:08:32 +0200 oj r275791 : #i104780# new version 1.2.0 2009-09-03 22:29:21 +0200 fs r275775 : OSL_TRACE doesn't need \n anymore 2009-09-03 08:33:21 +0200 fs r275743 : CWS-TOOLING: rebase CWS dba32g to trunk@275331 (milestone: DEV300:m56) 2009-09-02 13:48:12 +0200 fs r275708 : removed useless include 2009-09-02 13:45:43 +0200 fs r275707 : more since tags, which are used across offapi/udkapi 2009-09-02 13:23:04 +0200 fs r275705 : should *not* have the dtor, copy ctor, and assignment operator compiler-generated, else we run into trouble as soon as the compiler creates different versions of our singleton member's static data in different libraries 2009-09-02 12:32:45 +0200 fs r275704 : AutoIncrementIsPrimaryKey is a driver setting, not a data source setting 2009-09-02 11:42:49 +0200 fs r275701 : URL meta data are meta data which are valid for all connections of this type, not per-data-source properties. Settings them as data source properties is a hack. 2009-09-02 08:43:34 +0200 fs r275696 : 3.x.x is not a valid 'since' tag 2009-09-01 16:05:24 +0200 fs r275665 : #i104686# don't treat controls bound to read-only columns as required 2009-09-01 13:10:22 +0200 fs r275657 : #i104574# use PageUp/Down to scroll through the complete page 2009-09-01 07:04:48 +0200 oj r275641 : #i104104# correct line ends 2009-08-31 15:52:34 +0200 fs r275612 : #i104410# 2009-08-31 12:29:05 +0200 fs r275596 : #i104364# 2009-08-31 12:28:56 +0200 fs r275595 : #i104364# 2009-08-31 11:43:09 +0200 fs r275593 : #i104649# JavaDriverClassPath is also a known JDBC-bridge setting 2009-08-31 11:41:37 +0200 fs r275592 : #i104649# 2009-08-28 21:48:27 +0200 fs r275552 : during #i96862#: renamed the configuration data which controls availability of certain DBA-related UI 2009-08-28 21:48:17 +0200 fs r275551 : #i96862# do not show the 'Create a new database' option when a) no embedded/dBase driver is installed or b) the configuration requests to hide the option 2009-08-28 21:47:19 +0200 fs r275550 : during #i96862#: renamed the configuration data which controls availability of certain DBA-related UI 2009-08-28 21:46:41 +0200 fs r275549 : #i96862# renamed and extended the configuration data which controls availability of certain DBA-related UI 2009-08-28 15:10:19 +0200 fs r275535 : #i96862# if no embedded driver is installed, use dBase for creating new DBs. If no dBase driver is installed, too, do not offer the 'Create new database' option 2009-08-28 14:03:04 +0200 fs r275532 : #i104454# allow multiple fields to display the same column 2009-08-28 13:14:00 +0200 fs r275528 : #i104584# driver meta data do not belong into a data source's settings 2009-08-28 13:09:57 +0200 fs r275527 : properly chech the MySQL type buttons (else next/back in the wizard leads to state with two buttons checked) 2009-08-28 13:09:17 +0200 fs r275526 : #i104584# driver meta data do not belong into a data source's settings 2009-08-28 13:07:18 +0200 fs r275525 : BooleanComparisonMode is a property, or a feature - but not a driver meta data 2009-08-28 11:00:31 +0200 fs r275521 : #i104580# 2009-08-28 10:40:05 +0200 fs r275519 : #i104577# correct assertion: If the template node type is ANY, then any value type is allowed 2009-08-28 10:09:30 +0200 fs r275518 : #i104575# implement Named Pipe UI 2009-08-28 10:09:07 +0200 fs r275517 : pass the trigger-event to IWindowOperator::operateOn / work with VclWindowEvents, not VclSimpleEvents 2009-08-27 14:27:36 +0200 fs r275484 : ImplPosTabPage: respect mbEmptyViewMargin for WINDOWALIGN_LEFT 2009-08-27 13:43:56 +0200 fs r275480 : merging latest changes from CWS dba32f herein 2009-08-27 13:23:07 +0200 fs r275475 : #i103882# 2009-08-27 11:56:55 +0200 fs r275466 : #i104544# SetState: Do not call Update at the window which we just set text for. It should (sic\!) not be needed, but causes trouble 2009-08-27 11:55:34 +0200 fs r275465 : #i104544# do not allow re-entrance for impl_ensureControl_nothrow Actually, this is part of the fix only. I also removed the code which triggered this re-entrance (from the grid control implementation), but to ensure it won't happen, again, I added some safety herein. 2009-08-27 10:14:11 +0200 fs r275459 : preparations for supporting a 'NamedPipe' parameter for the MySQL Connector/OOo 2009-08-27 10:13:21 +0200 fs r275458 : preparations for supporting a 'NamedPipe' setting for the MySQL Connector/OOo 2009-08-27 10:11:14 +0200 fs r275456 : outsourced the MySQLNative settings into a dedicated class, to not duplicate all the code in two tab page implementations 2009-08-26 14:18:13 +0200 fs r275422 : #i10000# 2009-08-26 13:26:36 +0200 fs r275419 : ignore output paths 2009-08-26 13:23:38 +0200 fs r275417 : support the LocalSocket property for the MySQL native driver 2009-08-26 13:17:05 +0200 fs r275416 : some re-factoring, to outsource the tab page for setting up the MySQLNative connection, into a dedicated class (needed later) 2009-08-26 13:15:15 +0200 fs r275415 : support a NoThousandSep property for NumericFormatters - I'm tired of correcting this at runtime, instead of controlling it in the resource 2009-08-26 11:45:08 +0200 fs r275410 : oops, 'flat' shouldn't have got lost 2009-08-26 09:38:57 +0200 fs r275398 : #i102631# when saving the document fails, ensure that the interaction handler really can handle/display the error 2009-08-26 09:37:05 +0200 fs r275397 : #i102631# don't let non-IO/RuntimeExceptions escape from DatabaseDocument::store*, wrap them into an IOException 2009-08-26 09:35:39 +0200 fs r275395 : let the default interaction handler implement XInteractionHandler2 2009-08-25 13:51:34 +0200 fs r275352 : #i102631# createTempFile: pass URL through FileHelper.getOOoCompatibleFileURL 2009-08-25 13:49:23 +0200 fs r275351 : #i102631# createTempFileURL: immediately delete the file implicitly created by createTempFile, we really only need the URL 2009-08-24 14:49:07 +0200 fs r275318 : #i10000# 2009-08-24 14:36:03 +0200 fs r275315 : properly terminate message with 0 character 2009-08-24 14:35:45 +0200 fs r275314 : trace method concepts in non-pro, if special flag is enabled 2009-08-24 14:24:17 +0200 fs r275312 : #i98973# filter some more events for grid control columns 2009-08-24 14:15:23 +0200 fs r275311 : #i98973# implement XComboBox for combo box cells 2009-08-24 13:39:24 +0200 fs r275308 : #i98973# do not display the 'actionPerformed' event for grid combo box columns 2009-08-24 12:52:03 +0200 fs r275303 : #i98973# implement XCheckBox and XButton for check box cells 2009-08-24 11:56:05 +0200 oj r275300 : #i104447# wrong default for orientation 2009-08-24 10:51:21 +0200 fs r275296 : in the script selector dialog, interpret a double click onto a function as OK 2009-08-24 10:50:56 +0200 fs r275295 : localize some to-be-displayed names, consolidate some code regarding form/control naming 2009-08-21 14:28:05 +0200 fs r275255 : #i98973# implement KeyListeners 2009-08-21 14:27:20 +0200 fs r275254 : #i98973# move the conversion VCL[Mouse|Key]Event->Awt[Mouse|Key]Event from vclxwindow.cxx to VCLUnoHelper 2009-08-21 14:08:50 +0200 fs r275248 : #i98973# implement Mouse- and MouseMotion-broadcasting 2009-08-21 13:31:08 +0200 fs r275244 : #i98973# implement text and change listeners at text cells 2009-08-21 12:47:38 +0200 fs r275234 : #i104399# some refactoring: If the MySQL Connector/OOo is installed, it registers for the sdbc:mysqlc: protocol (now known as DST_MYSQL_NATIVE_DIRECT). However, we do not want to display this in the UI, instead we display "MySQL" only, which collects DST_MYSQL_ODBC, DST_MYSQL_JDBC, and DST_MYSQL_NATIVE. 2009-08-21 12:45:18 +0200 fs r275232 : #i104399# also register for the sdbc:mysql:mysqlc protocol, decide at runtime (depending on the availability of sdbc:mysqlc:), whether it is really accepted. This prevents that the C/OOo extension needs to register *our* implementation name for the sdbc:mysql:mysqlc: protocol, which would be somewhat weird 2009-08-20 16:18:48 +0200 fs r275190 : merging the latest changes from CWS dba32f (which this CWS was created from) 2009-08-19 20:19:59 +0200 fs r275160 : add some spacing between the radios 2009-08-19 14:50:15 +0200 fs r275150 : #i98973# slightly refactoring the grid cell implementations, to prepare for proper events being fired. Implement focus events for the moment, more to come. 2009-08-19 10:53:38 +0200 fs r275142 : #i99936# initialize newly created models 2009-08-18 23:03:48 +0200 fs r275132 : merging latest changes from CWS dba32f 2009-08-18 15:14:08 +0200 fs r275110 : #i102819# SetColumnPos: SCROLL_CLIP is deadly here
2009-09-14 11:18:01 +00:00
,m_bBindingIntrospectee( false )
{
DBG_CTOR(OPropertyBrowserController,NULL);
}
//------------------------------------------------------------------------
OPropertyBrowserController::~OPropertyBrowserController()
{
// stop listening for property changes
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
acquire();
stopInspection( true );
DBG_DTOR(OPropertyBrowserController,NULL);
}
//------------------------------------------------------------------------
IMPLEMENT_FORWARD_REFCOUNT( OPropertyBrowserController, OPropertyBrowserController_Base )
//------------------------------------------------------------------------
Any SAL_CALL OPropertyBrowserController::queryInterface( const Type& _rType ) throw (RuntimeException)
{
Any aReturn = OPropertyBrowserController_Base::queryInterface( _rType );
if ( !aReturn.hasValue() )
aReturn = ::cppu::queryInterface(
_rType,
static_cast< XObjectInspectorUI* >( this )
);
return aReturn;
}
//------------------------------------------------------------------------
void OPropertyBrowserController::startContainerWindowListening()
{
if (m_bContainerFocusListening)
return;
if (m_xFrame.is())
{
Reference< XWindow > xContainerWindow = m_xFrame->getContainerWindow();
if (xContainerWindow.is())
{
xContainerWindow->addFocusListener(this);
m_bContainerFocusListening = sal_True;
}
}
DBG_ASSERT(m_bContainerFocusListening, "OPropertyBrowserController::startContainerWindowListening: unable to start listening (inconsistence)!");
}
//------------------------------------------------------------------------
void OPropertyBrowserController::stopContainerWindowListening()
{
if (!m_bContainerFocusListening)
return;
if (m_xFrame.is())
{
Reference< XWindow > xContainerWindow = m_xFrame->getContainerWindow();
if (xContainerWindow.is())
{
xContainerWindow->removeFocusListener(this);
m_bContainerFocusListening = sal_False;
}
}
DBG_ASSERT(!m_bContainerFocusListening, "OPropertyBrowserController::stopContainerWindowListening: unable to stop listening (inconsistence)!");
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
//--------------------------------------------------------------------
Reference< XObjectInspectorModel > SAL_CALL OPropertyBrowserController::getInspectorModel() throw (RuntimeException)
{
return m_xModel;
}
//--------------------------------------------------------------------
void OPropertyBrowserController::impl_initializeView_nothrow()
{
OSL_PRECOND( haveView(), "OPropertyBrowserController::impl_initializeView_nothrow: not to be called when we have no view!" );
if ( !haveView() )
return;
if ( !m_xModel.is() )
// allowed
return;
try
{
getPropertyBox().EnableHelpSection( m_xModel->getHasHelpSection() );
getPropertyBox().SetHelpLineLimites( m_xModel->getMinHelpTextLines(), m_xModel->getMaxHelpTextLines() );
}
catch( const Exception& )
{
DBG_UNHANDLED_EXCEPTION();
}
}
//--------------------------------------------------------------------
void OPropertyBrowserController::impl_updateReadOnlyView_nothrow()
{
// this is a huge cudgel, admitted.
// The problem is that in case we were previously read-only, all our controls
// were created read-only, too. We cannot simply switch them to not-read-only.
// Even if they had an API for this, we do not know whether they were
// originally created read-only, or if they are read-only just because
// the model was.
impl_rebindToInspectee_nothrow( m_aInspectedObjects );
}
//--------------------------------------------------------------------
bool OPropertyBrowserController::impl_isReadOnlyModel_throw() const
{
if ( !m_xModel.is() )
return false;
return m_xModel->getIsReadOnly();
}
//--------------------------------------------------------------------
void OPropertyBrowserController::impl_startOrStopModelListening_nothrow( bool _bDoListen ) const
{
try
{
Reference< XPropertySet > xModelProperties( m_xModel, UNO_QUERY );
if ( !xModelProperties.is() )
// okay, so the model doesn't want to change its properties
// dynamically - fine with us
return;
void (SAL_CALL XPropertySet::*pListenerOperation)( const ::rtl::OUString&, const Reference< XPropertyChangeListener >& )
= _bDoListen ? &XPropertySet::addPropertyChangeListener : &XPropertySet::removePropertyChangeListener;
(xModelProperties.get()->*pListenerOperation)(
::rtl::OUString( "IsReadOnly" ),
const_cast< OPropertyBrowserController* >( this )
);
}
catch( const Exception& )
{
DBG_UNHANDLED_EXCEPTION();
}
}
//--------------------------------------------------------------------
void OPropertyBrowserController::impl_bindToNewModel_nothrow( const Reference< XObjectInspectorModel >& _rxInspectorModel )
{
impl_startOrStopModelListening_nothrow( false );
m_xModel = _rxInspectorModel;
impl_startOrStopModelListening_nothrow( true );
// initialize the view, if we already have one
if ( haveView() )
impl_initializeView_nothrow();
// inspect again, if we already have inspectees
if ( !m_aInspectedObjects.empty() )
impl_rebindToInspectee_nothrow( m_aInspectedObjects );
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
//--------------------------------------------------------------------
void SAL_CALL OPropertyBrowserController::setInspectorModel( const Reference< XObjectInspectorModel >& _inspectorModel ) throw (RuntimeException)
{
::osl::MutexGuard aGuard( m_aMutex );
if ( m_xModel == _inspectorModel )
return;
impl_bindToNewModel_nothrow( _inspectorModel );
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
//--------------------------------------------------------------------
Reference< XObjectInspectorUI > SAL_CALL OPropertyBrowserController::getInspectorUI() throw (RuntimeException)
{
// we're derived from this interface, though we do not expose it in queryInterface and getTypes.
return this;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
//--------------------------------------------------------------------
void SAL_CALL OPropertyBrowserController::inspect( const Sequence< Reference< XInterface > >& _rObjects ) throw (com::sun::star::util::VetoException, RuntimeException)
{
SolarMutexGuard aSolarGuard;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
::osl::MutexGuard aGuard( m_aMutex );
if ( m_bSuspendingPropertyHandlers || !suspendAll_nothrow() )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
{ // we already are trying to suspend the component (this is somewhere up the stack)
// OR one of our property handlers raised a veto against closing. Well, we *need* to close
// it in order to inspect another object.
throw VetoException();
}
CWS-TOOLING: integrate CWS dba32g 2009-09-09 07:53:55 +0200 oj r275964 : replace strlen with rtl_str_getLength 2009-09-07 20:59:10 +0200 fs r275913 : disable the CopyTableWizard test until issue 104869 is fixed 2009-09-07 12:17:31 +0200 oj r275885 : #i104810# remove de as lang 2009-09-05 22:26:21 +0200 fs r275857 : protect StateChanged against re-entrance 2009-09-05 22:25:52 +0200 fs r275856 : don't attempt to classify the parent of a form as control 2009-09-05 22:25:29 +0200 fs r275855 : protect against re-entrance 2009-09-05 00:11:40 +0200 fs r275835 : #i10000# 2009-09-04 23:25:50 +0200 fs r275834 : #i10000# 2009-09-04 23:23:47 +0200 fs r275833 : #i10000# 2009-09-04 21:49:37 +0200 fs r275830 : #i10000# correct wrong conflict resolution 2009-09-04 20:59:51 +0200 fs r275829 : CWS-TOOLING: rebase CWS dba32g to trunk@275801 (milestone: DEV300:m57) 2009-09-04 11:08:32 +0200 oj r275791 : #i104780# new version 1.2.0 2009-09-03 22:29:21 +0200 fs r275775 : OSL_TRACE doesn't need \n anymore 2009-09-03 08:33:21 +0200 fs r275743 : CWS-TOOLING: rebase CWS dba32g to trunk@275331 (milestone: DEV300:m56) 2009-09-02 13:48:12 +0200 fs r275708 : removed useless include 2009-09-02 13:45:43 +0200 fs r275707 : more since tags, which are used across offapi/udkapi 2009-09-02 13:23:04 +0200 fs r275705 : should *not* have the dtor, copy ctor, and assignment operator compiler-generated, else we run into trouble as soon as the compiler creates different versions of our singleton member's static data in different libraries 2009-09-02 12:32:45 +0200 fs r275704 : AutoIncrementIsPrimaryKey is a driver setting, not a data source setting 2009-09-02 11:42:49 +0200 fs r275701 : URL meta data are meta data which are valid for all connections of this type, not per-data-source properties. Settings them as data source properties is a hack. 2009-09-02 08:43:34 +0200 fs r275696 : 3.x.x is not a valid 'since' tag 2009-09-01 16:05:24 +0200 fs r275665 : #i104686# don't treat controls bound to read-only columns as required 2009-09-01 13:10:22 +0200 fs r275657 : #i104574# use PageUp/Down to scroll through the complete page 2009-09-01 07:04:48 +0200 oj r275641 : #i104104# correct line ends 2009-08-31 15:52:34 +0200 fs r275612 : #i104410# 2009-08-31 12:29:05 +0200 fs r275596 : #i104364# 2009-08-31 12:28:56 +0200 fs r275595 : #i104364# 2009-08-31 11:43:09 +0200 fs r275593 : #i104649# JavaDriverClassPath is also a known JDBC-bridge setting 2009-08-31 11:41:37 +0200 fs r275592 : #i104649# 2009-08-28 21:48:27 +0200 fs r275552 : during #i96862#: renamed the configuration data which controls availability of certain DBA-related UI 2009-08-28 21:48:17 +0200 fs r275551 : #i96862# do not show the 'Create a new database' option when a) no embedded/dBase driver is installed or b) the configuration requests to hide the option 2009-08-28 21:47:19 +0200 fs r275550 : during #i96862#: renamed the configuration data which controls availability of certain DBA-related UI 2009-08-28 21:46:41 +0200 fs r275549 : #i96862# renamed and extended the configuration data which controls availability of certain DBA-related UI 2009-08-28 15:10:19 +0200 fs r275535 : #i96862# if no embedded driver is installed, use dBase for creating new DBs. If no dBase driver is installed, too, do not offer the 'Create new database' option 2009-08-28 14:03:04 +0200 fs r275532 : #i104454# allow multiple fields to display the same column 2009-08-28 13:14:00 +0200 fs r275528 : #i104584# driver meta data do not belong into a data source's settings 2009-08-28 13:09:57 +0200 fs r275527 : properly chech the MySQL type buttons (else next/back in the wizard leads to state with two buttons checked) 2009-08-28 13:09:17 +0200 fs r275526 : #i104584# driver meta data do not belong into a data source's settings 2009-08-28 13:07:18 +0200 fs r275525 : BooleanComparisonMode is a property, or a feature - but not a driver meta data 2009-08-28 11:00:31 +0200 fs r275521 : #i104580# 2009-08-28 10:40:05 +0200 fs r275519 : #i104577# correct assertion: If the template node type is ANY, then any value type is allowed 2009-08-28 10:09:30 +0200 fs r275518 : #i104575# implement Named Pipe UI 2009-08-28 10:09:07 +0200 fs r275517 : pass the trigger-event to IWindowOperator::operateOn / work with VclWindowEvents, not VclSimpleEvents 2009-08-27 14:27:36 +0200 fs r275484 : ImplPosTabPage: respect mbEmptyViewMargin for WINDOWALIGN_LEFT 2009-08-27 13:43:56 +0200 fs r275480 : merging latest changes from CWS dba32f herein 2009-08-27 13:23:07 +0200 fs r275475 : #i103882# 2009-08-27 11:56:55 +0200 fs r275466 : #i104544# SetState: Do not call Update at the window which we just set text for. It should (sic\!) not be needed, but causes trouble 2009-08-27 11:55:34 +0200 fs r275465 : #i104544# do not allow re-entrance for impl_ensureControl_nothrow Actually, this is part of the fix only. I also removed the code which triggered this re-entrance (from the grid control implementation), but to ensure it won't happen, again, I added some safety herein. 2009-08-27 10:14:11 +0200 fs r275459 : preparations for supporting a 'NamedPipe' parameter for the MySQL Connector/OOo 2009-08-27 10:13:21 +0200 fs r275458 : preparations for supporting a 'NamedPipe' setting for the MySQL Connector/OOo 2009-08-27 10:11:14 +0200 fs r275456 : outsourced the MySQLNative settings into a dedicated class, to not duplicate all the code in two tab page implementations 2009-08-26 14:18:13 +0200 fs r275422 : #i10000# 2009-08-26 13:26:36 +0200 fs r275419 : ignore output paths 2009-08-26 13:23:38 +0200 fs r275417 : support the LocalSocket property for the MySQL native driver 2009-08-26 13:17:05 +0200 fs r275416 : some re-factoring, to outsource the tab page for setting up the MySQLNative connection, into a dedicated class (needed later) 2009-08-26 13:15:15 +0200 fs r275415 : support a NoThousandSep property for NumericFormatters - I'm tired of correcting this at runtime, instead of controlling it in the resource 2009-08-26 11:45:08 +0200 fs r275410 : oops, 'flat' shouldn't have got lost 2009-08-26 09:38:57 +0200 fs r275398 : #i102631# when saving the document fails, ensure that the interaction handler really can handle/display the error 2009-08-26 09:37:05 +0200 fs r275397 : #i102631# don't let non-IO/RuntimeExceptions escape from DatabaseDocument::store*, wrap them into an IOException 2009-08-26 09:35:39 +0200 fs r275395 : let the default interaction handler implement XInteractionHandler2 2009-08-25 13:51:34 +0200 fs r275352 : #i102631# createTempFile: pass URL through FileHelper.getOOoCompatibleFileURL 2009-08-25 13:49:23 +0200 fs r275351 : #i102631# createTempFileURL: immediately delete the file implicitly created by createTempFile, we really only need the URL 2009-08-24 14:49:07 +0200 fs r275318 : #i10000# 2009-08-24 14:36:03 +0200 fs r275315 : properly terminate message with 0 character 2009-08-24 14:35:45 +0200 fs r275314 : trace method concepts in non-pro, if special flag is enabled 2009-08-24 14:24:17 +0200 fs r275312 : #i98973# filter some more events for grid control columns 2009-08-24 14:15:23 +0200 fs r275311 : #i98973# implement XComboBox for combo box cells 2009-08-24 13:39:24 +0200 fs r275308 : #i98973# do not display the 'actionPerformed' event for grid combo box columns 2009-08-24 12:52:03 +0200 fs r275303 : #i98973# implement XCheckBox and XButton for check box cells 2009-08-24 11:56:05 +0200 oj r275300 : #i104447# wrong default for orientation 2009-08-24 10:51:21 +0200 fs r275296 : in the script selector dialog, interpret a double click onto a function as OK 2009-08-24 10:50:56 +0200 fs r275295 : localize some to-be-displayed names, consolidate some code regarding form/control naming 2009-08-21 14:28:05 +0200 fs r275255 : #i98973# implement KeyListeners 2009-08-21 14:27:20 +0200 fs r275254 : #i98973# move the conversion VCL[Mouse|Key]Event->Awt[Mouse|Key]Event from vclxwindow.cxx to VCLUnoHelper 2009-08-21 14:08:50 +0200 fs r275248 : #i98973# implement Mouse- and MouseMotion-broadcasting 2009-08-21 13:31:08 +0200 fs r275244 : #i98973# implement text and change listeners at text cells 2009-08-21 12:47:38 +0200 fs r275234 : #i104399# some refactoring: If the MySQL Connector/OOo is installed, it registers for the sdbc:mysqlc: protocol (now known as DST_MYSQL_NATIVE_DIRECT). However, we do not want to display this in the UI, instead we display "MySQL" only, which collects DST_MYSQL_ODBC, DST_MYSQL_JDBC, and DST_MYSQL_NATIVE. 2009-08-21 12:45:18 +0200 fs r275232 : #i104399# also register for the sdbc:mysql:mysqlc protocol, decide at runtime (depending on the availability of sdbc:mysqlc:), whether it is really accepted. This prevents that the C/OOo extension needs to register *our* implementation name for the sdbc:mysql:mysqlc: protocol, which would be somewhat weird 2009-08-20 16:18:48 +0200 fs r275190 : merging the latest changes from CWS dba32f (which this CWS was created from) 2009-08-19 20:19:59 +0200 fs r275160 : add some spacing between the radios 2009-08-19 14:50:15 +0200 fs r275150 : #i98973# slightly refactoring the grid cell implementations, to prepare for proper events being fired. Implement focus events for the moment, more to come. 2009-08-19 10:53:38 +0200 fs r275142 : #i99936# initialize newly created models 2009-08-18 23:03:48 +0200 fs r275132 : merging latest changes from CWS dba32f 2009-08-18 15:14:08 +0200 fs r275110 : #i102819# SetColumnPos: SCROLL_CLIP is deadly here
2009-09-14 11:18:01 +00:00
if ( m_bBindingIntrospectee )
throw VetoException();
m_bBindingIntrospectee = true;
impl_rebindToInspectee_nothrow( InterfaceArray( _rObjects.getConstArray(), _rObjects.getConstArray() + _rObjects.getLength() ) );
CWS-TOOLING: integrate CWS dba32g 2009-09-09 07:53:55 +0200 oj r275964 : replace strlen with rtl_str_getLength 2009-09-07 20:59:10 +0200 fs r275913 : disable the CopyTableWizard test until issue 104869 is fixed 2009-09-07 12:17:31 +0200 oj r275885 : #i104810# remove de as lang 2009-09-05 22:26:21 +0200 fs r275857 : protect StateChanged against re-entrance 2009-09-05 22:25:52 +0200 fs r275856 : don't attempt to classify the parent of a form as control 2009-09-05 22:25:29 +0200 fs r275855 : protect against re-entrance 2009-09-05 00:11:40 +0200 fs r275835 : #i10000# 2009-09-04 23:25:50 +0200 fs r275834 : #i10000# 2009-09-04 23:23:47 +0200 fs r275833 : #i10000# 2009-09-04 21:49:37 +0200 fs r275830 : #i10000# correct wrong conflict resolution 2009-09-04 20:59:51 +0200 fs r275829 : CWS-TOOLING: rebase CWS dba32g to trunk@275801 (milestone: DEV300:m57) 2009-09-04 11:08:32 +0200 oj r275791 : #i104780# new version 1.2.0 2009-09-03 22:29:21 +0200 fs r275775 : OSL_TRACE doesn't need \n anymore 2009-09-03 08:33:21 +0200 fs r275743 : CWS-TOOLING: rebase CWS dba32g to trunk@275331 (milestone: DEV300:m56) 2009-09-02 13:48:12 +0200 fs r275708 : removed useless include 2009-09-02 13:45:43 +0200 fs r275707 : more since tags, which are used across offapi/udkapi 2009-09-02 13:23:04 +0200 fs r275705 : should *not* have the dtor, copy ctor, and assignment operator compiler-generated, else we run into trouble as soon as the compiler creates different versions of our singleton member's static data in different libraries 2009-09-02 12:32:45 +0200 fs r275704 : AutoIncrementIsPrimaryKey is a driver setting, not a data source setting 2009-09-02 11:42:49 +0200 fs r275701 : URL meta data are meta data which are valid for all connections of this type, not per-data-source properties. Settings them as data source properties is a hack. 2009-09-02 08:43:34 +0200 fs r275696 : 3.x.x is not a valid 'since' tag 2009-09-01 16:05:24 +0200 fs r275665 : #i104686# don't treat controls bound to read-only columns as required 2009-09-01 13:10:22 +0200 fs r275657 : #i104574# use PageUp/Down to scroll through the complete page 2009-09-01 07:04:48 +0200 oj r275641 : #i104104# correct line ends 2009-08-31 15:52:34 +0200 fs r275612 : #i104410# 2009-08-31 12:29:05 +0200 fs r275596 : #i104364# 2009-08-31 12:28:56 +0200 fs r275595 : #i104364# 2009-08-31 11:43:09 +0200 fs r275593 : #i104649# JavaDriverClassPath is also a known JDBC-bridge setting 2009-08-31 11:41:37 +0200 fs r275592 : #i104649# 2009-08-28 21:48:27 +0200 fs r275552 : during #i96862#: renamed the configuration data which controls availability of certain DBA-related UI 2009-08-28 21:48:17 +0200 fs r275551 : #i96862# do not show the 'Create a new database' option when a) no embedded/dBase driver is installed or b) the configuration requests to hide the option 2009-08-28 21:47:19 +0200 fs r275550 : during #i96862#: renamed the configuration data which controls availability of certain DBA-related UI 2009-08-28 21:46:41 +0200 fs r275549 : #i96862# renamed and extended the configuration data which controls availability of certain DBA-related UI 2009-08-28 15:10:19 +0200 fs r275535 : #i96862# if no embedded driver is installed, use dBase for creating new DBs. If no dBase driver is installed, too, do not offer the 'Create new database' option 2009-08-28 14:03:04 +0200 fs r275532 : #i104454# allow multiple fields to display the same column 2009-08-28 13:14:00 +0200 fs r275528 : #i104584# driver meta data do not belong into a data source's settings 2009-08-28 13:09:57 +0200 fs r275527 : properly chech the MySQL type buttons (else next/back in the wizard leads to state with two buttons checked) 2009-08-28 13:09:17 +0200 fs r275526 : #i104584# driver meta data do not belong into a data source's settings 2009-08-28 13:07:18 +0200 fs r275525 : BooleanComparisonMode is a property, or a feature - but not a driver meta data 2009-08-28 11:00:31 +0200 fs r275521 : #i104580# 2009-08-28 10:40:05 +0200 fs r275519 : #i104577# correct assertion: If the template node type is ANY, then any value type is allowed 2009-08-28 10:09:30 +0200 fs r275518 : #i104575# implement Named Pipe UI 2009-08-28 10:09:07 +0200 fs r275517 : pass the trigger-event to IWindowOperator::operateOn / work with VclWindowEvents, not VclSimpleEvents 2009-08-27 14:27:36 +0200 fs r275484 : ImplPosTabPage: respect mbEmptyViewMargin for WINDOWALIGN_LEFT 2009-08-27 13:43:56 +0200 fs r275480 : merging latest changes from CWS dba32f herein 2009-08-27 13:23:07 +0200 fs r275475 : #i103882# 2009-08-27 11:56:55 +0200 fs r275466 : #i104544# SetState: Do not call Update at the window which we just set text for. It should (sic\!) not be needed, but causes trouble 2009-08-27 11:55:34 +0200 fs r275465 : #i104544# do not allow re-entrance for impl_ensureControl_nothrow Actually, this is part of the fix only. I also removed the code which triggered this re-entrance (from the grid control implementation), but to ensure it won't happen, again, I added some safety herein. 2009-08-27 10:14:11 +0200 fs r275459 : preparations for supporting a 'NamedPipe' parameter for the MySQL Connector/OOo 2009-08-27 10:13:21 +0200 fs r275458 : preparations for supporting a 'NamedPipe' setting for the MySQL Connector/OOo 2009-08-27 10:11:14 +0200 fs r275456 : outsourced the MySQLNative settings into a dedicated class, to not duplicate all the code in two tab page implementations 2009-08-26 14:18:13 +0200 fs r275422 : #i10000# 2009-08-26 13:26:36 +0200 fs r275419 : ignore output paths 2009-08-26 13:23:38 +0200 fs r275417 : support the LocalSocket property for the MySQL native driver 2009-08-26 13:17:05 +0200 fs r275416 : some re-factoring, to outsource the tab page for setting up the MySQLNative connection, into a dedicated class (needed later) 2009-08-26 13:15:15 +0200 fs r275415 : support a NoThousandSep property for NumericFormatters - I'm tired of correcting this at runtime, instead of controlling it in the resource 2009-08-26 11:45:08 +0200 fs r275410 : oops, 'flat' shouldn't have got lost 2009-08-26 09:38:57 +0200 fs r275398 : #i102631# when saving the document fails, ensure that the interaction handler really can handle/display the error 2009-08-26 09:37:05 +0200 fs r275397 : #i102631# don't let non-IO/RuntimeExceptions escape from DatabaseDocument::store*, wrap them into an IOException 2009-08-26 09:35:39 +0200 fs r275395 : let the default interaction handler implement XInteractionHandler2 2009-08-25 13:51:34 +0200 fs r275352 : #i102631# createTempFile: pass URL through FileHelper.getOOoCompatibleFileURL 2009-08-25 13:49:23 +0200 fs r275351 : #i102631# createTempFileURL: immediately delete the file implicitly created by createTempFile, we really only need the URL 2009-08-24 14:49:07 +0200 fs r275318 : #i10000# 2009-08-24 14:36:03 +0200 fs r275315 : properly terminate message with 0 character 2009-08-24 14:35:45 +0200 fs r275314 : trace method concepts in non-pro, if special flag is enabled 2009-08-24 14:24:17 +0200 fs r275312 : #i98973# filter some more events for grid control columns 2009-08-24 14:15:23 +0200 fs r275311 : #i98973# implement XComboBox for combo box cells 2009-08-24 13:39:24 +0200 fs r275308 : #i98973# do not display the 'actionPerformed' event for grid combo box columns 2009-08-24 12:52:03 +0200 fs r275303 : #i98973# implement XCheckBox and XButton for check box cells 2009-08-24 11:56:05 +0200 oj r275300 : #i104447# wrong default for orientation 2009-08-24 10:51:21 +0200 fs r275296 : in the script selector dialog, interpret a double click onto a function as OK 2009-08-24 10:50:56 +0200 fs r275295 : localize some to-be-displayed names, consolidate some code regarding form/control naming 2009-08-21 14:28:05 +0200 fs r275255 : #i98973# implement KeyListeners 2009-08-21 14:27:20 +0200 fs r275254 : #i98973# move the conversion VCL[Mouse|Key]Event->Awt[Mouse|Key]Event from vclxwindow.cxx to VCLUnoHelper 2009-08-21 14:08:50 +0200 fs r275248 : #i98973# implement Mouse- and MouseMotion-broadcasting 2009-08-21 13:31:08 +0200 fs r275244 : #i98973# implement text and change listeners at text cells 2009-08-21 12:47:38 +0200 fs r275234 : #i104399# some refactoring: If the MySQL Connector/OOo is installed, it registers for the sdbc:mysqlc: protocol (now known as DST_MYSQL_NATIVE_DIRECT). However, we do not want to display this in the UI, instead we display "MySQL" only, which collects DST_MYSQL_ODBC, DST_MYSQL_JDBC, and DST_MYSQL_NATIVE. 2009-08-21 12:45:18 +0200 fs r275232 : #i104399# also register for the sdbc:mysql:mysqlc protocol, decide at runtime (depending on the availability of sdbc:mysqlc:), whether it is really accepted. This prevents that the C/OOo extension needs to register *our* implementation name for the sdbc:mysql:mysqlc: protocol, which would be somewhat weird 2009-08-20 16:18:48 +0200 fs r275190 : merging the latest changes from CWS dba32f (which this CWS was created from) 2009-08-19 20:19:59 +0200 fs r275160 : add some spacing between the radios 2009-08-19 14:50:15 +0200 fs r275150 : #i98973# slightly refactoring the grid cell implementations, to prepare for proper events being fired. Implement focus events for the moment, more to come. 2009-08-19 10:53:38 +0200 fs r275142 : #i99936# initialize newly created models 2009-08-18 23:03:48 +0200 fs r275132 : merging latest changes from CWS dba32f 2009-08-18 15:14:08 +0200 fs r275110 : #i102819# SetColumnPos: SCROLL_CLIP is deadly here
2009-09-14 11:18:01 +00:00
m_bBindingIntrospectee = false;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
//--------------------------------------------------------------------
Reference< XDispatch > SAL_CALL OPropertyBrowserController::queryDispatch( const URL& /*URL*/, const ::rtl::OUString& /*TargetFrameName*/, ::sal_Int32 /*SearchFlags*/ ) throw (RuntimeException)
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
{
// we don't have any dispatches at all, right now
return Reference< XDispatch >();
}
//--------------------------------------------------------------------
Sequence< Reference< XDispatch > > SAL_CALL OPropertyBrowserController::queryDispatches( const Sequence< DispatchDescriptor >& Requests ) throw (RuntimeException)
{
Sequence< Reference< XDispatch > > aReturn;
sal_Int32 nLen = Requests.getLength();
aReturn.realloc( nLen );
Reference< XDispatch >* pReturn = aReturn.getArray();
const Reference< XDispatch >* pReturnEnd = aReturn.getArray() + nLen;
const DispatchDescriptor* pDescripts = Requests.getConstArray();
for ( ; pReturn != pReturnEnd; ++ pReturn, ++pDescripts )
*pReturn = queryDispatch( pDescripts->FeatureURL, pDescripts->FrameName, pDescripts->SearchFlags );
return aReturn;
}
//------------------------------------------------------------------------
void SAL_CALL OPropertyBrowserController::initialize( const Sequence< Any >& _arguments ) throw (Exception, RuntimeException)
{
if ( m_bConstructed )
throw AlreadyInitializedException();
StlSyntaxSequence< Any > arguments( _arguments );
if ( arguments.empty() )
{ // constructor: "createDefault()"
createDefault();
return;
}
Reference< XObjectInspectorModel > xModel;
if ( arguments.size() == 1 )
{ // constructor: "createWithModel( XObjectInspectorModel )"
if ( !( arguments[0] >>= xModel ) )
throw IllegalArgumentException( ::rtl::OUString(), *this, 0 );
createWithModel( xModel );
return;
}
throw IllegalArgumentException( ::rtl::OUString(), *this, 0 );
}
//------------------------------------------------------------------------
void OPropertyBrowserController::createDefault()
{
m_bConstructed = true;
}
//------------------------------------------------------------------------
void OPropertyBrowserController::createWithModel( const Reference< XObjectInspectorModel >& _rxModel )
{
osl_incrementInterlockedCount( &m_refCount );
{
setInspectorModel( _rxModel );
}
osl_decrementInterlockedCount( &m_refCount );
m_bConstructed = true;
}
//------------------------------------------------------------------------
void SAL_CALL OPropertyBrowserController::attachFrame( const Reference< XFrame >& _rxFrame ) throw(RuntimeException)
{
SolarMutexGuard aSolarGuard;
::osl::MutexGuard aGuard( m_aMutex );
if (_rxFrame.is() && haveView())
throw RuntimeException(::rtl::OUString("Unable to attach to a second frame."),*this);
// revoke as focus listener from the old container window
stopContainerWindowListening();
m_xFrame = _rxFrame;
if (!m_xFrame.is())
return;
// TODO: this construction perhaps should be done outside. Don't know the exact meaning of attachFrame.
// Maybe it is intended to only announce the frame to the controller, and the instance doing this
// announcement is responsible for calling setComponent, too.
Reference< XWindow > xContainerWindow = m_xFrame->getContainerWindow();
VCLXWindow* pContainerWindow = VCLXWindow::GetImplementation(xContainerWindow);
Window* pParentWin = pContainerWindow ? pContainerWindow->GetWindow() : NULL;
if (!pParentWin)
throw RuntimeException(::rtl::OUString("The frame is invalid. Unable to extract the container window."),*this);
if ( Construct( pParentWin ) )
{
try
{
m_xFrame->setComponent( VCLUnoHelper::GetInterface( m_pView ), this );
}
catch( const Exception& )
{
OSL_FAIL( "OPropertyBrowserController::attachFrame: caught an exception!" );
}
}
startContainerWindowListening();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
UpdateUI();
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
sal_Bool SAL_CALL OPropertyBrowserController::attachModel( const Reference< XModel >& _rxModel ) throw(RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
Reference< XObjectInspectorModel > xModel( _rxModel, UNO_QUERY );
if ( !xModel.is() )
return false;
setInspectorModel( xModel );
return getInspectorModel() == _rxModel;
}
//------------------------------------------------------------------------
sal_Bool OPropertyBrowserController::suspendAll_nothrow()
{
// if there is a handle inside its "onInteractivePropertySelection" method,
// then veto
// Normally, we could expect every handler to do this itself, but being
// realistic, it's safer to handle this here in general.
if ( m_xInteractiveHandler.is() )
return sal_False;
m_bSuspendingPropertyHandlers = true;
sal_Bool bHandlerVeto = !suspendPropertyHandlers_nothrow( sal_True );
m_bSuspendingPropertyHandlers = false;
if ( bHandlerVeto )
return sal_False;
return sal_True;
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
//------------------------------------------------------------------------
sal_Bool OPropertyBrowserController::suspendPropertyHandlers_nothrow( sal_Bool _bSuspend )
{
PropertyHandlerArray aAllHandlers; // will contain every handler exactly once
for ( PropertyHandlerRepository::const_iterator handler = m_aPropertyHandlers.begin();
handler != m_aPropertyHandlers.end();
++handler
)
{
if ( ::std::find( aAllHandlers.begin(), aAllHandlers.end(), handler->second ) != aAllHandlers.end() )
// already visited this particular handler (m_aPropertyHandlers usually contains
// the same handler more than once)
continue;
aAllHandlers.push_back( handler->second );
}
for ( PropertyHandlerArray::iterator loop = aAllHandlers.begin();
loop != aAllHandlers.end();
++loop
)
{
try
{
if ( !(*loop)->suspend( _bSuspend ) )
if ( _bSuspend )
// if we're not suspending, but reactivating, ignore the error
return sal_False;
}
catch( const Exception& )
{
OSL_FAIL( "OPropertyBrowserController::suspendPropertyHandlers_nothrow: caught an exception!" );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
}
return sal_True;
}
//------------------------------------------------------------------------
sal_Bool SAL_CALL OPropertyBrowserController::suspend( sal_Bool _bSuspend ) throw(RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
::osl::MutexGuard aGuard( m_aMutex );
OSL_ENSURE( haveView(), "OPropertyBrowserController::suspend: don't have a view anymore!" );
if ( !_bSuspend )
{ // this means a "suspend" is to be "revoked"
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
suspendPropertyHandlers_nothrow( sal_False );
// we ourself cannot revoke our suspend
return sal_False;
}
if ( !suspendAll_nothrow() )
return sal_False;
// commit the editor's content
if ( haveView() )
getPropertyBox().CommitModified();
// stop listening
stopContainerWindowListening();
// outtahere
return sal_True;
}
//------------------------------------------------------------------------
Any SAL_CALL OPropertyBrowserController::getViewData( ) throw(RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
return makeAny( m_sPageSelection );
}
//------------------------------------------------------------------------
void SAL_CALL OPropertyBrowserController::restoreViewData( const Any& Data ) throw(RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
::rtl::OUString sPageSelection;
if ( ( Data >>= sPageSelection ) && !sPageSelection.isEmpty() )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
{
m_sPageSelection = sPageSelection;
selectPageFromViewData();
}
}
//------------------------------------------------------------------------
Reference< XModel > SAL_CALL OPropertyBrowserController::getModel( ) throw(RuntimeException)
{
// have no model
return Reference< XModel >();
}
//------------------------------------------------------------------------
Reference< XFrame > SAL_CALL OPropertyBrowserController::getFrame( ) throw(RuntimeException)
{
return m_xFrame;
}
//------------------------------------------------------------------------
void SAL_CALL OPropertyBrowserController::dispose( ) throw(RuntimeException)
{
SolarMutexGuard aSolarGuard;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// stop inspecting the current object
stopInspection( false );
// say our dispose listeners goodbye
::com::sun::star::lang::EventObject aEvt;
aEvt.Source = static_cast< ::cppu::OWeakObject* >(this);
m_aDisposeListeners.disposeAndClear(aEvt);
m_aControlObservers.disposeAndClear(aEvt);
// don't delete explicitly (this is done by the frame we reside in)
m_pView = NULL;
Reference< XComponent > xViewAsComp( m_xView, UNO_QUERY );
if ( xViewAsComp.is() )
xViewAsComp->removeEventListener( static_cast< XPropertyChangeListener* >( this ) );
m_xView.clear( );
m_aInspectedObjects.clear();
impl_bindToNewModel_nothrow( NULL );
}
//------------------------------------------------------------------------
void SAL_CALL OPropertyBrowserController::addEventListener( const Reference< XEventListener >& _rxListener ) throw(RuntimeException)
{
m_aDisposeListeners.addInterface(_rxListener);
}
//------------------------------------------------------------------------
void SAL_CALL OPropertyBrowserController::removeEventListener( const Reference< XEventListener >& _rxListener ) throw(RuntimeException)
{
m_aDisposeListeners.removeInterface(_rxListener);
}
//------------------------------------------------------------------------
::rtl::OUString SAL_CALL OPropertyBrowserController::getImplementationName( ) throw(RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
return getImplementationName_static();
}
//------------------------------------------------------------------------
sal_Bool SAL_CALL OPropertyBrowserController::supportsService( const ::rtl::OUString& ServiceName ) throw(RuntimeException)
{
Sequence< ::rtl::OUString > aSupported(getSupportedServiceNames());
const ::rtl::OUString* pArray = aSupported.getConstArray();
for (sal_Int32 i = 0; i < aSupported.getLength(); ++i, ++pArray)
if (pArray->equals(ServiceName))
return sal_True;
return sal_False;
}
//------------------------------------------------------------------------
Sequence< ::rtl::OUString > SAL_CALL OPropertyBrowserController::getSupportedServiceNames( ) throw(RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
return getSupportedServiceNames_static();
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
::rtl::OUString OPropertyBrowserController::getImplementationName_static( ) throw(RuntimeException)
{
return ::rtl::OUString("org.openoffice.comp.extensions.ObjectInspector");
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
Sequence< ::rtl::OUString > OPropertyBrowserController::getSupportedServiceNames_static( ) throw(RuntimeException)
{
Sequence< ::rtl::OUString > aSupported(1);
aSupported[0] = ::rtl::OUString("com.sun.star.inspection.ObjectInspector");
return aSupported;
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
Reference< XInterface > SAL_CALL OPropertyBrowserController::Create(const Reference< XComponentContext >& _rxContext)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
return *(new OPropertyBrowserController( _rxContext ) );
}
//------------------------------------------------------------------------
void SAL_CALL OPropertyBrowserController::focusGained( const FocusEvent& _rSource ) throw (RuntimeException)
{
Reference< XWindow > xSourceWindow(_rSource.Source, UNO_QUERY);
Reference< XWindow > xContainerWindow;
if (m_xFrame.is())
xContainerWindow = m_xFrame->getContainerWindow();
if ( xContainerWindow.get() == xSourceWindow.get() )
{ // our container window got the focus
if ( haveView() )
getPropertyBox().GrabFocus();
}
}
//------------------------------------------------------------------------
void SAL_CALL OPropertyBrowserController::focusLost( const FocusEvent& /*_rSource*/ ) throw (RuntimeException)
{
// not interested in
}
//------------------------------------------------------------------------
void SAL_CALL OPropertyBrowserController::disposing( const EventObject& _rSource ) throw(RuntimeException)
{
if ( m_xView.is() && ( m_xView == _rSource.Source ) )
{
m_xView = NULL;
m_pView = NULL;
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
for ( InterfaceArray::iterator loop = m_aInspectedObjects.begin();
loop != m_aInspectedObjects.end();
++loop
)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
if ( *loop == _rSource.Source )
{
m_aInspectedObjects.erase( loop );
break;
}
}
}
//------------------------------------------------------------------------
IMPL_LINK_NOARG(OPropertyBrowserController, OnPageActivation)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
updateViewDataFromActivePage();
return 0L;
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
void OPropertyBrowserController::updateViewDataFromActivePage()
{
if (!haveView())
return;
::rtl::OUString sOldSelection = m_sPageSelection;
m_sPageSelection = ::rtl::OUString();
const sal_uInt16 nCurrentPage = m_pView->getActivaPage();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
if ( (sal_uInt16)-1 != nCurrentPage )
{
for ( HashString2Int16::const_iterator pageId = m_aPageIds.begin();
pageId != m_aPageIds.end();
++pageId
)
{
if ( nCurrentPage == pageId->second )
{
m_sPageSelection = pageId->first;
break;
}
}
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
if ( !m_sPageSelection.isEmpty() )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
m_sLastValidPageSelection = m_sPageSelection;
else if ( !sOldSelection.isEmpty() )
m_sLastValidPageSelection = sOldSelection;
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
sal_uInt16 OPropertyBrowserController::impl_getPageIdForCategory_nothrow( const ::rtl::OUString& _rCategoryName ) const
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
sal_uInt16 nPageId = (sal_uInt16)-1;
HashString2Int16::const_iterator pagePos = m_aPageIds.find( _rCategoryName );
if ( pagePos != m_aPageIds.end() )
nPageId = pagePos->second;
return nPageId;
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
void OPropertyBrowserController::selectPageFromViewData()
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
sal_uInt16 nNewPage = impl_getPageIdForCategory_nothrow( m_sPageSelection );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
if ( haveView() && ( nNewPage != (sal_uInt16)-1 ) )
m_pView->activatePage( nNewPage );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// just in case ...
updateViewDataFromActivePage();
}
//------------------------------------------------------------------------
sal_Bool OPropertyBrowserController::Construct(Window* _pParentWin)
{
DBG_ASSERT(!haveView(), "OPropertyBrowserController::Construct: already have a view!");
DBG_ASSERT(_pParentWin, "OPropertyBrowserController::Construct: invalid parent window!");
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
m_pView = new OPropertyBrowserView(m_aContext.getLegacyServiceFactory(), _pParentWin);
m_pView->setPageActivationHandler(LINK(this, OPropertyBrowserController, OnPageActivation));
// add as dispose listener for our view. The view is disposed by the frame we're plugged into,
// and this disposal _deletes_ the view, so it would be deadly if we use our m_pView member
// after that
m_xView = VCLUnoHelper::GetInterface(m_pView);
Reference< XComponent > xViewAsComp(m_xView, UNO_QUERY);
if (xViewAsComp.is())
xViewAsComp->addEventListener( static_cast< XPropertyChangeListener* >( this ) );
getPropertyBox().SetLineListener(this);
getPropertyBox().SetControlObserver(this);
impl_initializeView_nothrow();
m_pView->Show();
return sal_True;
}
//------------------------------------------------------------------------
void SAL_CALL OPropertyBrowserController::propertyChange( const PropertyChangeEvent& _rEvent ) throw (RuntimeException)
{
if ( _rEvent.Source == m_xModel )
{
if ( _rEvent.PropertyName == "IsReadOnly" )
impl_updateReadOnlyView_nothrow();
return;
}
CWS-TOOLING: integrate CWS dba32b 2009-06-03 14:58:08 +0200 fs r272581 : #i102439# 2009-05-29 13:56:18 +0200 fs r272456 : remove the sub form when the 'add subform' setting changes from <true/> to <false/>, not only its controls 2009-05-29 13:19:27 +0200 fs r272454 : display '(Default)' instead of an empty string when a control has the default font 2009-05-28 20:49:18 +0200 fs r272428 : #i98162# getFirstSelectedValue: do not return reference to a temporary 2009-05-27 15:30:22 +0200 msc r272353 : #102303# 2009-05-26 13:03:06 +0200 fs r272295 : spelling 2009-05-26 12:59:54 +0200 fs r272294 : merge m48 version to get latest cygwin related fixes 2009-05-25 14:02:06 +0200 fs r272239 : remove references to local files, needed for debugging sessions only 2009-05-25 14:01:16 +0200 fs r272238 : #i102021# ensure members such as bNumberFormat are initialized before actually returning them 2009-05-25 13:10:20 +0200 fs r272236 : #i10000# reset ENABLE_EVOAB2 2009-05-22 06:44:45 +0200 oj r272167 : #i99104# add import handler for calc-sett 2009-05-22 06:42:27 +0200 oj r272166 : #i99104# impl NullDate as member 2009-05-22 06:36:22 +0200 oj r272165 : #i99104# handle nulldate from parent model 2009-05-22 06:33:13 +0200 oj r272164 : #i99104# export and import calculation-settings and nulldate 2009-05-22 06:27:50 +0200 oj r272163 : #i99104# export and import calculation-settings and nulldate 2009-05-20 13:29:58 +0200 oj r272118 : #i99911# handle invalid name 2009-05-20 13:28:49 +0200 oj r272117 : #i101261# handle different rowsets 2009-05-20 11:29:55 +0200 msc r272111 : #i100000# 2009-05-20 11:28:27 +0200 msc r272110 : merge in change from dba32a 2009-05-20 11:27:38 +0200 msc r272109 : #102082# CTRL + C does not work 2009-05-20 09:43:36 +0200 oj r272106 : clean up includes 2009-05-20 09:32:15 +0200 oj r272105 : #i99060# merge error resovled now VERTICAL_ALIGN is in both stmt 2009-05-20 08:37:21 +0200 msc r272104 : add workaround for issue #102010# 2009-05-20 08:10:12 +0200 oj r272103 : #i99104# use numberformatkey 2009-05-20 08:07:02 +0200 oj r272102 : #i99104# use column info from rowset 2009-05-20 08:04:43 +0200 oj r272101 : #i102032# use a special column type where prec and scale are the values currently set at the column 2009-05-20 08:03:04 +0200 oj r272100 : #i102032# correct type info, we have to use SQL defined type names 2009-05-19 10:27:02 +0200 oj r272061 : #i99104# export null-date 2009-05-19 08:26:53 +0200 oj r272056 : #i99104# export null-date 2009-05-18 13:15:10 +0200 msc r272014 : add issue #102019# 2009-05-18 11:33:07 +0200 msc r272005 : add issue #102019# 2009-05-18 08:59:45 +0200 msc r271996 : add workaroud for issue #102010# 2009-05-15 10:21:24 +0200 msc r271929 : #101944# 2009-05-11 21:18:30 +0200 fs r271792 : #i99914# 2009-05-08 13:52:06 +0200 oj r271715 : #i96423# remember column span 2009-05-08 11:26:19 +0200 oj r271708 : #i98605# impl new scale mode 2009-05-08 10:33:35 +0200 fs r271706 : SendUserCall: only call into the shape notification routine for UserCall types where this is necessary (performance issue) 2009-05-07 20:52:44 +0200 fs r271698 : outsource ShapeProperty from shapepropertynotifier.hxx 2009-05-07 20:43:33 +0200 fs r271697 : #i99056# use notifyShapePropertyChange, instead of getShapePropertyChangeNotifier - the latter throws if no shape exists, yet 2009-05-07 20:33:58 +0200 fs r271696 : #i99056# +notifyShapePropertyChange: allow notifying chages without checking whether there actually already exists an SvxShape 2009-05-07 16:22:15 +0200 fs r271679 : #i10000# cygwin needs quotes around the classpath 2009-05-07 16:21:37 +0200 fs r271678 : #i10000# cygwin needs quotes around the classpath 2009-05-07 16:01:11 +0200 oj r271677 : #i99914# notify parent handler 2009-05-07 15:54:54 +0200 fs r271676 : #i10000# cygwin needs some quoting 2009-05-07 14:49:48 +0200 oj r271672 : #i99277# quote alias name 2009-05-07 14:48:12 +0200 oj r271671 : #i92538# add ~ in front of type 2009-05-07 14:37:13 +0200 oj r271667 : #i99118# change type from char to varchar 2009-05-07 14:36:23 +0200 oj r271666 : #i99118# clear dest columns when changing to create new table 2009-05-07 13:35:32 +0200 oj r271657 : #i94467# handle type 0 as double as well 2009-05-07 13:20:49 +0200 oj r271655 : i99743# setNull when varchar is no text 2009-05-07 12:58:06 +0200 fs r271651 : initialize the SdrObject's property change notifier after the ctor, if necessary 2009-05-07 11:47:18 +0200 fs r271647 : #i10000# 2009-05-07 10:57:16 +0200 fs r271639 : OPropertyBrowserController::propertyChange: care for the current property state, too, and properly forward it to the UI 2009-05-07 10:18:14 +0200 fs r271636 : onNewComponent: do not ask the map for grid columns, it will throw 2009-05-07 10:09:55 +0200 fs r271634 : #i101623# 2009-05-07 09:53:44 +0200 fs r271631 : #i101622# 2009-05-06 21:55:53 +0200 fs r271615 : #i10000# 2009-05-06 21:10:42 +0200 fs r271611 : #i10000# 2009-05-06 13:11:48 +0200 fs r271583 : #i10000# 2009-05-05 22:29:31 +0200 fs r271559 : proper assertion message 2009-05-05 22:29:03 +0200 fs r271558 : diagnostics 2009-05-05 22:16:16 +0200 fs r271557 : #i10000# 2009-05-05 13:50:32 +0200 fs r271513 : #i10000# 2009-05-05 10:21:50 +0200 fs r271503 : #i10000# 2009-05-05 09:30:26 +0200 fs r271501 : why did those survive the rebase -C step? 2009-05-05 09:18:12 +0200 fs r271500 : #i10000# 2009-05-04 17:08:17 +0200 fs r271475 : CWS-TOOLING: rebase CWS dba32b to trunk@271427 (milestone: DEV300:m47) 2009-05-04 14:51:26 +0200 fs r271456 : line ends 2009-04-30 15:55:27 +0200 fs r271418 : NewURL -> PublicConnectionURL 2009-04-22 21:18:34 +0200 fs r271141 : #i100944# 2009-04-22 09:12:26 +0200 oj r271071 : #i101261# little code change 2009-04-22 09:11:43 +0200 oj r271070 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:11:25 +0200 oj r271069 : #i101261# new grabage container for nodes 2009-04-22 09:11:02 +0200 oj r271068 : #i101261# new grabage container for nodes 2009-04-22 09:10:44 +0200 oj r271067 : #i101261# new grabage container for nodes 2009-04-22 09:10:21 +0200 oj r271066 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:08:24 +0200 oj r271065 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:07:25 +0200 oj r271064 : #i101261# only ask for parameters which aren't set before 2009-04-22 08:49:07 +0200 oj r271062 : #i77501# preview only when needed 2009-04-22 08:45:44 +0200 oj r271061 : #i101261# new prop max rows 2009-04-22 08:44:18 +0200 oj r271060 : #i101261# create dataprovider earlier to avoid the wrong legend in chart 2009-04-22 08:42:48 +0200 oj r271059 : #i101261# handle parameter 2009-04-17 21:00:23 +0200 fs r270954 : #i98350# 2009-04-17 13:54:19 +0200 fs r270942 : #i99565# 2009-04-17 13:51:34 +0200 fs r270940 : #i101153# only localize the (potentially) localizable properties when there really is support at the control model 2009-04-17 11:43:14 +0200 fs r270932 : removed superfluous include 2009-04-17 10:10:15 +0200 fs r270926 : #i10000# 2009-04-17 10:02:36 +0200 fs r270925 : #i10000# 2009-04-17 09:15:13 +0200 fs r270918 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 09:14:56 +0200 fs r270917 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 09:13:25 +0200 fs r270915 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 08:30:34 +0200 fs r270914 : removed unotools/servicehelper.hxx in favour of the (duplicated) comphelper/servicehelper.hxx 2009-04-16 21:05:25 +0200 fs r270903 : #i10000# 2009-04-16 20:43:43 +0200 fs r270902 : #i99056# shape notification outsourced to the SdrObject, this is what all other shape implementations (which only aggregate an SvxShape) have access to, too 2009-04-16 15:57:36 +0200 fs r270891 : #i99056# make SetUnoControlModel virtual 2009-04-16 15:44:02 +0200 fs r270890 : #i99056# let the ScShapeObj notify changes in its Anchor property 2009-04-16 15:36:47 +0200 fs r270889 : #i99056# enable the sheet anchor type property, too 2009-04-16 15:33:45 +0200 fs r270887 : #i99056# shape notification outsourced to the SdrObject, this is what all other shape implementations (which only aggregate an SvxShape) have access to, too 2009-04-15 14:53:13 +0200 fs r270844 : #i10000# 2009-04-15 13:08:29 +0200 fs r270836 : #i10000# 2009-04-15 12:28:14 +0200 fs r270832 : #i10000# 2009-04-15 10:59:14 +0200 fs r270827 : #i10000# 2009-04-15 09:41:08 +0200 oj r270823 : fix issues found with findbugs and pmd 2009-04-14 21:08:04 +0200 fs r270808 : #i99056# implement SheetAnchorType - now the only thing missing to enable it is the proper notification when it is modified 2009-04-14 17:09:00 +0200 fs r270799 : #i99056# implement XServiceInfo for the ScShapeObj 2009-04-14 17:07:55 +0200 fs r270798 : #i99056# implement TextAnchorType, partially implement SheetAnchorType 2009-04-14 15:54:05 +0200 fs r270786 : #i99056# SwXShape: notify changes of the AnchorType property 2009-04-14 15:47:32 +0200 fs r270785 : #i99056# deliver shapepropertynotifier.hxx 2009-04-14 15:46:54 +0200 fs r270784 : diagnostics 2009-04-14 15:08:28 +0200 fs r270781 : #i99056# outsourced the SvxShape's property change notification code into a dedicated class 2009-04-14 14:41:09 +0200 fs r270773 : #i99056# outsourced the SvxShape's property change notification code into a dedicated class 2009-04-14 14:37:23 +0200 fs r270772 : in dtor, remove the properties from the temporary component context 2009-04-14 14:36:34 +0200 fs r270771 : getWeakUnoShape made const 2009-04-14 12:23:08 +0200 oj r270757 : #i101064# add missing braces 2009-04-14 12:21:25 +0200 oj r270756 : #i101065# add braces for gcc 4.3.2 2009-04-14 12:17:45 +0200 oj r270755 : #i101059# add dep for manifest 2009-04-09 12:06:58 +0200 oj r270686 : #i93100# use OptimalSize from control to get height 2009-04-08 09:56:55 +0200 oj r270619 : #i92537# handle calculations in the select columns as well 2009-04-08 09:30:39 +0200 oj r270615 : #i96657# throw error message when the key doesn't have any columns 2009-04-07 12:08:26 +0200 oj r270592 : #i77501# impl preview of the executed report 2009-04-07 12:01:56 +0200 oj r270591 : #i77501# impl preview of the executed report 2009-04-07 11:41:03 +0200 oj r270590 : #i77501# impl preview of the executed report 2009-04-07 11:39:32 +0200 oj r270589 : #i77501# impl preview of the executed report 2009-04-07 11:29:25 +0200 oj r270588 : #i77501# convert dos to unix lineends 2009-04-07 11:28:23 +0200 oj r270587 : #i77501# impl preview of the executed report 2009-04-07 11:16:50 +0200 oj r270586 : #i77501# impl preview of the executed report 2009-04-07 11:16:00 +0200 oj r270585 : #i77501# impl preview of the executed report 2009-04-07 11:15:44 +0200 oj r270584 : #i77501# impl preview of the executed report 2009-04-07 11:15:28 +0200 oj r270583 : #i77501# impl preview of the executed report 2009-04-07 11:15:04 +0200 oj r270582 : #i77501# impl preview of the executed report 2009-04-06 15:38:54 +0200 fs r270559 : merge changes from CWS dba32a herein 2009-04-03 15:56:16 +0200 fs r270494 : ImpSvMEdit::Resize: do multiple iterations, if necessary 2009-04-03 14:35:49 +0200 fs r270487 : #i10000# 2009-04-03 13:17:16 +0200 fs r270476 : #i99056# display geometry information for controls, too 2009-04-03 13:16:37 +0200 fs r270475 : #i99056# better ordering of the geometry properties 2009-04-03 13:16:07 +0200 fs r270473 : #i99056# now that SvxShape supports property change listeners, forward add/remove requests to it 2009-04-03 13:13:18 +0200 fs r270472 : #i99056# at SvxShape, allow for PropertyChangeListeners for Size/Position 2009-04-03 09:29:27 +0200 oj r270456 : #i94571# use correct prop name 2009-04-03 09:14:54 +0200 fs r270451 : merge changes from CWS dba32a herein 2009-04-02 17:00:51 +0200 fs r270424 : better diagnostics 2009-04-02 16:35:19 +0200 fs r270421 : diagnostics 2009-04-02 16:34:50 +0200 fs r270420 : #i99056# mxUnoShape not accessible anymore, use impl_setUnoShape instead 2009-04-02 16:32:48 +0200 fs r270419 : #i99056# make getUnoShape cheaper: keep the pointer to the SvxShape all the time, so there's no need to ask for it in getUnoShape. As a consequence, we will later be able to use the pointer in scenarious where performance (potentially) matters 2009-04-02 16:31:13 +0200 fs r270417 : merge changes from CWS dba32a herein 2009-04-02 16:23:16 +0200 fs r270414 : merge changes from CWS dba32a herein 2009-04-02 14:10:35 +0200 fs r270405 : #i10000# 2009-04-02 14:06:26 +0200 fs r270404 : merge changes from CWS dba32a herein 2009-04-02 14:03:03 +0200 fs r270401 : #i10000# 2009-04-02 13:58:13 +0200 fs r270400 : #i10000# 2009-04-02 12:59:44 +0200 fs r270397 : merge changes from CWS dba32a herein 2009-04-02 12:46:30 +0200 fs r270396 : #i99056# let the form page maintain a mapping between control models and control shapes 2009-04-02 12:44:07 +0200 fs r270395 : merge changes from CWS dba32a herein 2009-04-02 12:42:06 +0200 fs r270394 : merge changes from CWS dba32a herein 2009-04-02 12:35:20 +0200 fs r270393 : #i10000# precompiled header 2009-04-02 12:05:31 +0200 fs r270392 : merge changes from CWS dba32a herein 2009-04-02 12:00:42 +0200 fs r270391 : merge changes from CWS dba32a herein 2009-04-02 11:47:26 +0200 fs r270390 : merge changes from CWS dba32a herein 2009-04-02 11:39:15 +0200 oj r270389 : #i94467# foxpro impl several new types 2009-04-02 11:35:58 +0200 fs r270387 : merge changes from CWS dba32a herein 2009-04-01 14:10:51 +0200 fs r270329 : merge changes from CWS dba32a herein 2009-03-31 17:29:50 +0200 fs r270290 : merge changes from CWS dba32a herein 2009-03-30 14:53:56 +0200 fs r270233 : #i100417# don't set grid column widths to 0, but to <void/> 2009-03-30 12:31:03 +0200 oj r270213 : #i100552# wrong orb used 2009-03-30 12:19:20 +0200 oj r270212 : #i98303# convertlike corrected to sal_Unicode 2009-03-30 11:58:25 +0200 fs r270210 : merge changes from CWS dba32a herein 2009-03-30 11:38:16 +0200 oj r270205 : remove duplicate code from merge 2009-03-30 11:02:27 +0200 fs r270202 : merge changes from CWS dba32a herein 2009-03-30 11:02:19 +0200 fs r270201 : merge changes from CWS dba32a herein 2009-03-30 10:31:26 +0200 oj r270200 : #i100665# only throw exception and do not drop table 2009-03-30 09:36:24 +0200 fs r270195 : assertion text 2009-03-28 20:21:58 +0100 fs r270187 : #ii10000# 2009-03-28 20:19:54 +0100 fs r270186 : removed unused help ids 2009-03-28 20:19:40 +0100 fs r270185 : removed unused help ids 2009-03-28 20:19:10 +0100 fs r270184 : #i100237# +DefaultState/XReset 2009-03-28 00:29:29 +0100 fs r270177 : CWS-TOOLING: rebase CWS dba32b to trunk@270033 (milestone: DEV300:m45) 2009-03-27 22:56:46 +0100 fs r270173 : #i100237# DEFAULT_CHECKED -> DEFAULT_STATE 2009-03-27 22:55:52 +0100 fs r270172 : #i100237# DefaultState property for buttons, enabled only when Toggle=Yes 2009-03-27 22:54:15 +0100 fs r270171 : #i100237# DEFAULT_CHECKED -> DEFAULT_STATE 2009-03-27 22:53:54 +0100 fs r270170 : #i100237# introduce a DefaultState property for buttons, which implies buttongs supporting XReset, which needed some refactoring 2009-03-27 13:31:41 +0100 fs r270152 : ignore output paths 2009-03-27 11:23:44 +0100 fs r270139 : tuned behavior with respect to invalid keys/values 2009-03-27 09:57:14 +0100 fs r270136 : don't allow Double.NaN 2009-03-27 09:56:16 +0100 fs r270135 : talk about Double.NaN 2009-03-26 12:14:30 +0100 fs r270067 : removed unused parameter 2009-03-26 12:14:02 +0100 fs r270066 : removed widening conversion when checking keys 2009-03-26 09:17:34 +0100 fs r270053 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-26 09:17:11 +0100 fs r270052 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-26 09:16:49 +0100 fs r270051 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-25 21:55:20 +0100 fs r270044 : #i100541# properly calculat bNeedScrollBox 2009-03-25 12:56:17 +0100 fs r270019 : renamed the previously introduced error condition 2009-03-25 12:11:48 +0100 fs r270015 : #i100095# when the error messages contain non-trivial details (SQLState/ErrorCode), then always display the 'Details' button 2009-03-25 12:10:05 +0100 fs r270012 : renamed the previously introduced error condition 2009-03-25 12:01:04 +0100 fs r270011 : #i100095# when no address book (or respective profile) can be found, then use a dedicated ErrorCondition 2009-03-25 10:29:07 +0100 fs r270003 : add missing localization 2009-03-25 10:23:12 +0100 fs r270001 : in preparation of #i1000095#: rework the error handling, allow using css.sdb.ErrorCondition values, plus allow propagating the nsresult 2009-03-25 10:21:55 +0100 fs r270000 : in preparation of #i1000095#: rework the error handling, allow using css.sdb.ErrorCondition values, plus allow propagating the nsresult 2009-03-20 23:05:38 +0100 fs r269829 : XMap::getSize removed 2009-03-20 23:05:19 +0100 fs r269828 : changes as suggested by sb 2009-03-20 23:04:56 +0100 fs r269827 : enhanced documentation 2009-03-20 15:31:40 +0100 fs r269815 : changes as suggested by sb 2009-03-20 13:23:52 +0100 oj r269804 : #i92538# correct the zorder that fixedtext is infront of control 2009-03-20 12:59:38 +0100 oj r269801 : #i94571# paraadjust now supports BLOCK 2009-03-20 12:58:11 +0100 oj r269800 : #i94571# export style with data style 2009-03-20 12:57:05 +0100 oj r269799 : #i94571# text align is now paraadjust 2009-03-20 12:37:02 +0100 fs r269797 : enum keys only accepted if they have the exact type, not if they have *any* enum type 2009-03-20 12:28:31 +0100 fs r269794 : some changes requested by sb 2009-03-20 08:52:47 +0100 fs r269780 : doc 2009-03-20 07:37:31 +0100 oj r269779 : #i99913# only notifiy when values are different 2009-03-20 07:36:58 +0100 oj r269778 : #i99913# add undoenv as listener at the dataprovider 2009-03-19 22:52:52 +0100 fs r269771 : added comment 2009-03-19 22:40:06 +0100 fs r269770 : +testEnumeration 2009-03-19 22:39:41 +0100 fs r269769 : implemented enumeration, getKeySet, and getValues. Should be finished now. 2009-03-19 14:01:01 +0100 oj r269743 : #i99913# reset the modified state when selecting an object 2009-03-19 12:19:54 +0100 lla r269739 : #i72390# cleanups 2009-03-19 09:25:27 +0100 fs r269727 : #i10000# 2009-03-18 23:37:02 +0100 fs r269708 : extended checks for value type acceptance 2009-03-18 23:36:41 +0100 fs r269707 : fixed value type checks 2009-03-18 14:59:56 +0100 fs r269678 : initial complex test case for the new css.container.Map implementation 2009-03-18 14:59:24 +0100 fs r269677 : verifyExpectedException moved to base class (in complexlib), and renamed to assureException for consistency 2009-03-18 14:58:35 +0100 fs r269676 : removed unused imports 2009-03-18 14:58:03 +0100 fs r269675 : first implementation of the new css.container.Map service (not completed, yet) 2009-03-18 14:57:17 +0100 fs r269674 : base class for UNO components, freeing you from some repeating work 2009-03-18 14:55:53 +0100 fs r269672 : +assureException: call a given method with given parameters on a given object, ensure that a given exception is thrown by the method implementation 2009-03-18 14:54:58 +0100 fs r269671 : +getComponentContext 2009-03-18 14:54:00 +0100 fs r269670 : isEmpty returns a boolean, not a long 2009-03-18 14:14:43 +0100 oj r269663 : #i99743# now text also supports null 2009-03-18 13:54:14 +0100 oj r269660 : #i99223# remove check for 2 params 2009-03-18 13:33:35 +0100 oj r269659 : #i99060# replace text::ParagraphVertAlign with style::VerticalAlignment 2009-03-18 13:32:18 +0100 oj r269658 : #i99060# don't set void property when void isn't allowed 2009-03-18 13:31:11 +0100 oj r269657 : #i99060# handle vertical alignment 2009-03-18 13:28:28 +0100 oj r269656 : #i99060# remove unused elements from sytle 2009-03-18 09:35:42 +0100 lla r269639 : #i72390# cleanups 2009-03-18 09:31:20 +0100 lla r269638 : #i72390# add ButtonList 2009-03-18 09:30:46 +0100 lla r269637 : #i72390# renamed interface 2009-03-18 09:30:15 +0100 lla r269636 : #i72390# use ButtonList instead of ImageList 2009-03-18 09:29:05 +0100 lla r269635 : #i72390# new ButtonList, cleanups 2009-03-18 09:26:34 +0100 lla r269634 : #i72390# cleanups 2009-03-17 12:21:20 +0100 oj r269590 : #i99222# remove assertion 2009-03-17 12:17:22 +0100 oj r269589 : #i98605# impl scale mode 2009-03-17 12:10:42 +0100 oj r269588 : #i98605# impl scale mode 2009-03-17 11:40:15 +0100 oj r269584 : #i96944# doesn't create equation for shapes 2009-03-17 11:33:16 +0100 oj r269583 : #i96423# switch calc from float to long 2009-03-16 15:19:18 +0100 fs r269550 : #i41930# enable zoom for embedded/outplace documents 2009-03-16 14:25:54 +0100 oj r269542 : #i93734# remove ContextSensitive 2009-03-16 14:21:58 +0100 oj r269541 : #i99274# page header before group header 2009-03-16 14:18:23 +0100 oj r269539 : #i99110# fix value type 2009-03-16 14:14:16 +0100 fs r269537 : line ends 2009-03-16 14:11:06 +0100 fs r269535 : line ends 2009-03-16 14:08:34 +0100 fs r269534 : #i100087# (provided my np): allow for polymorphic types with more than one parameter 2009-03-16 12:30:31 +0100 oj r269521 : compile error 2009-03-16 12:19:12 +0100 oj r269519 : compile error 2009-03-16 10:39:28 +0100 oj r269511 : compile error under linux with swap 2009-03-13 10:33:04 +0100 oj r269462 : CWS-TOOLING: rebase CWS dba32b to trunk@269297 (milestone: DEV300:m43) 2009-03-12 14:37:25 +0100 fs r269416 : interface SequenceOutputStreamTest is unneeded, and pollutes the namespace here :) 2009-03-12 14:35:07 +0100 fs r269414 : not needed 2009-03-12 14:34:15 +0100 fs r269413 : preparation for multiple tests in this module 2009-03-12 14:33:02 +0100 fs r269412 : ShowTargets was moved from module integration.forms to module complexlib 2009-03-12 14:32:48 +0100 fs r269411 : helper class for projects containing multiple complex test cases (and following a certain structure) 2009-03-12 14:00:14 +0100 fs r269407 : proper module after the move 2009-03-12 13:59:10 +0100 fs r269406 : superseded by ../makefile.mk 2009-03-12 13:47:38 +0100 fs r269403 : not needed anymore 2009-03-12 13:45:46 +0100 fs r269402 : moved, in preparation of adding more test cases here, with a common infrastructure 2009-03-12 13:45:07 +0100 fs r269401 : moved from ../ 2009-03-12 13:43:59 +0100 fs r269400 : moved to ./comphelper, in preparation of adding more test cases here, with a common infrastructure 2009-03-12 13:29:47 +0100 oj r269396 : #i99914# set parent on dataprovider 2009-03-12 13:10:35 +0100 oj r269393 : #i99832# check thrown exception and show error 2009-03-12 13:08:10 +0100 fs r269392 : reorganizing tests 2009-03-12 12:52:55 +0100 oj r269390 : #i99118# convert formatkey in numberformat 2009-03-12 12:34:53 +0100 fs r269388 : new API tests 2009-03-12 12:29:05 +0100 fs r269386 : Map not yet committed 2009-03-12 12:28:36 +0100 fs r269385 : oops, forgot the SequenceInputStream during the previous refactoring 2009-03-12 12:12:39 +0100 oj r269384 : #i99104# set HasCategories prop 2009-03-12 12:12:08 +0100 oj r269383 : #i99104# check HasCategories even for internal dataprovider 2009-03-12 12:10:40 +0100 oj r269382 : #i99104# set HasCategories prop 2009-03-12 10:51:49 +0100 fs r269373 : #i10000# exception specifications 2009-03-12 10:49:18 +0100 fs r269372 : #i10000# exception specifications 2009-03-12 10:44:02 +0100 fs r269371 : #i10000# exception specifications 2009-03-12 10:30:55 +0100 fs r269368 : refactored the UNO service registration in this module, using the helper classes provided by comphelper itself, so you have less effort when extending the list of to-be-registered components 2009-03-12 10:30:37 +0100 fs r269367 : module-local includes 2009-03-12 07:05:54 +0100 oj r269357 : #i99104# database dataprovider doesn't need dataranges and diagramdata 2009-03-11 10:58:28 +0100 oj r269306 : #i99911# check if name of the report is a valid file name 2009-03-11 10:03:23 +0100 oj r269299 : #i99666# the report is new when the HierarchicalDocumentName is empty 2009-03-10 11:32:45 +0100 oj r269258 : #i99221# use fallback for language 2009-03-10 10:48:40 +0100 oj r269255 : #i99433# now use OStringBuffer 2009-03-10 10:36:21 +0100 fs r269252 : initial version of (X)Map 2009-03-10 09:52:23 +0100 oj r269246 : #i99433# now use OStringBuffer 2009-03-10 08:56:13 +0100 oj r269240 : #i99655# patch applied 2009-03-09 07:35:33 +0100 lla r269058 : #i10000# wrong variable assignment fixed 2009-03-06 17:20:40 +0100 fs r269030 : some explicit defaults 2009-03-06 17:20:30 +0100 fs r269029 : #i98600# 2009-03-06 14:40:34 +0100 fs r269009 : #i87692# during reload, prevent the document being modified just because of some control content changes ... 2009-03-06 12:52:20 +0100 lla r268997 : #i10000# ambigous problem with FontWeight fixed 2009-03-06 11:39:32 +0100 fs r268989 : #i10000# (approved by pl): use --without-t1-library configure option 2009-03-06 10:55:43 +0100 fs r268986 : #i99953# depends on xmlscript module now 2009-03-06 10:54:04 +0100 fs r268985 : #i99953# also adjust the event names found in dialogs embedded in the forms 2009-03-06 09:53:41 +0100 fs r268977 : #i10000# 2009-03-06 09:30:41 +0100 lla r268973 : #i10000# merge problems 2009-03-05 17:52:34 +0100 fs r268932 : #i98593# for sub components which are actually controlled by a DocumentDefinition (aka XComponentSupplier aka XCommandProcessor), close them by executing the 'close' command, not by suspending/closing the controller (which cannot be intercepted) 2009-03-05 11:41:56 +0100 fs r268889 : default the drop down line count for list/combo boxes to 20 2009-03-05 11:39:10 +0100 fs r268887 : do not display empty error messages 2009-03-02 10:13:57 +0100 lla r268639 : #i91541# CWS rebase m41 to m42 2009-03-02 09:06:27 +0100 lla r268635 : #i10000# add ';' to strings 2009-02-26 11:18:00 +0100 fs r268492 : reportdesign depends on REPORTBUILDER, not REPORTDESIGN 2009-02-26 10:11:38 +0100 lla r268489 : CWS-TOOLING: rebase CWS dba32b to trunk@268395 (milestone: DEV300:m42) 2009-02-26 09:04:11 +0100 lla r268488 : CWS-TOOLING: rebase CWS dba32b to trunk@268395 (milestone: DEV300:m42) 2009-02-24 12:09:13 +0100 lla r268392 : #i91541# #i91542# cleanups 2009-02-24 08:08:06 +0100 lla r268382 : merge all dba32a changes into dba32b 2009-02-24 07:14:55 +0100 lla r268381 : merge all dba32a changes into dba32b 2009-02-23 21:44:28 +0100 fs r268377 : oops ... don't tamper with m_aListSourceValues at the end of loadData 2009-02-23 20:57:05 +0100 fs r268376 : #i98162# don't hold the values as strings, but as ORowSetValue, this way preserving their type, and being agnostic to different result/rowset implementations doing different to-string-conversations 2009-02-23 20:55:44 +0100 fs r268375 : getObject: throwFunctionNotSupportedException, instead of silently returning NULL 2009-02-23 20:55:20 +0100 fs r268374 : #i98162# some more supported types 2009-02-23 20:54:43 +0100 fs r268373 : #i98162# +operator != 2009-02-20 09:35:39 +0100 fs r268306 : #i99422# for a font, display the font name, the style, and the size 2009-02-20 09:33:45 +0100 fs r268305 : #i99422# in the property browser, FONT supersedes CHARFONTNAME: the aggregated FormComponentHandler displays them more nicely now 2009-02-19 16:12:06 +0100 fs r268293 : #i99372# recognize DataType::FLOAT as numeric 2009-02-19 15:43:12 +0100 fs r268291 : #i99415# 2009-02-19 15:40:15 +0100 fs r268290 : #i99242# lcl_firstFocussableControl: take disabled controls into account 2009-02-19 15:34:36 +0100 fs r268289 : #i99396# properly decode the base name of the URL when using it as title 2009-02-19 15:19:05 +0100 fs r268287 : #i98247#
2009-06-05 09:47:55 +00:00
if ( m_sCommittingProperty == _rEvent.PropertyName )
return;
if ( !haveView() )
return;
Any aNewValue( _rEvent.NewValue );
if ( impl_hasPropertyHandlerFor_nothrow( _rEvent.PropertyName ) )
{
CWS-TOOLING: integrate CWS dba32b 2009-06-03 14:58:08 +0200 fs r272581 : #i102439# 2009-05-29 13:56:18 +0200 fs r272456 : remove the sub form when the 'add subform' setting changes from <true/> to <false/>, not only its controls 2009-05-29 13:19:27 +0200 fs r272454 : display '(Default)' instead of an empty string when a control has the default font 2009-05-28 20:49:18 +0200 fs r272428 : #i98162# getFirstSelectedValue: do not return reference to a temporary 2009-05-27 15:30:22 +0200 msc r272353 : #102303# 2009-05-26 13:03:06 +0200 fs r272295 : spelling 2009-05-26 12:59:54 +0200 fs r272294 : merge m48 version to get latest cygwin related fixes 2009-05-25 14:02:06 +0200 fs r272239 : remove references to local files, needed for debugging sessions only 2009-05-25 14:01:16 +0200 fs r272238 : #i102021# ensure members such as bNumberFormat are initialized before actually returning them 2009-05-25 13:10:20 +0200 fs r272236 : #i10000# reset ENABLE_EVOAB2 2009-05-22 06:44:45 +0200 oj r272167 : #i99104# add import handler for calc-sett 2009-05-22 06:42:27 +0200 oj r272166 : #i99104# impl NullDate as member 2009-05-22 06:36:22 +0200 oj r272165 : #i99104# handle nulldate from parent model 2009-05-22 06:33:13 +0200 oj r272164 : #i99104# export and import calculation-settings and nulldate 2009-05-22 06:27:50 +0200 oj r272163 : #i99104# export and import calculation-settings and nulldate 2009-05-20 13:29:58 +0200 oj r272118 : #i99911# handle invalid name 2009-05-20 13:28:49 +0200 oj r272117 : #i101261# handle different rowsets 2009-05-20 11:29:55 +0200 msc r272111 : #i100000# 2009-05-20 11:28:27 +0200 msc r272110 : merge in change from dba32a 2009-05-20 11:27:38 +0200 msc r272109 : #102082# CTRL + C does not work 2009-05-20 09:43:36 +0200 oj r272106 : clean up includes 2009-05-20 09:32:15 +0200 oj r272105 : #i99060# merge error resovled now VERTICAL_ALIGN is in both stmt 2009-05-20 08:37:21 +0200 msc r272104 : add workaround for issue #102010# 2009-05-20 08:10:12 +0200 oj r272103 : #i99104# use numberformatkey 2009-05-20 08:07:02 +0200 oj r272102 : #i99104# use column info from rowset 2009-05-20 08:04:43 +0200 oj r272101 : #i102032# use a special column type where prec and scale are the values currently set at the column 2009-05-20 08:03:04 +0200 oj r272100 : #i102032# correct type info, we have to use SQL defined type names 2009-05-19 10:27:02 +0200 oj r272061 : #i99104# export null-date 2009-05-19 08:26:53 +0200 oj r272056 : #i99104# export null-date 2009-05-18 13:15:10 +0200 msc r272014 : add issue #102019# 2009-05-18 11:33:07 +0200 msc r272005 : add issue #102019# 2009-05-18 08:59:45 +0200 msc r271996 : add workaroud for issue #102010# 2009-05-15 10:21:24 +0200 msc r271929 : #101944# 2009-05-11 21:18:30 +0200 fs r271792 : #i99914# 2009-05-08 13:52:06 +0200 oj r271715 : #i96423# remember column span 2009-05-08 11:26:19 +0200 oj r271708 : #i98605# impl new scale mode 2009-05-08 10:33:35 +0200 fs r271706 : SendUserCall: only call into the shape notification routine for UserCall types where this is necessary (performance issue) 2009-05-07 20:52:44 +0200 fs r271698 : outsource ShapeProperty from shapepropertynotifier.hxx 2009-05-07 20:43:33 +0200 fs r271697 : #i99056# use notifyShapePropertyChange, instead of getShapePropertyChangeNotifier - the latter throws if no shape exists, yet 2009-05-07 20:33:58 +0200 fs r271696 : #i99056# +notifyShapePropertyChange: allow notifying chages without checking whether there actually already exists an SvxShape 2009-05-07 16:22:15 +0200 fs r271679 : #i10000# cygwin needs quotes around the classpath 2009-05-07 16:21:37 +0200 fs r271678 : #i10000# cygwin needs quotes around the classpath 2009-05-07 16:01:11 +0200 oj r271677 : #i99914# notify parent handler 2009-05-07 15:54:54 +0200 fs r271676 : #i10000# cygwin needs some quoting 2009-05-07 14:49:48 +0200 oj r271672 : #i99277# quote alias name 2009-05-07 14:48:12 +0200 oj r271671 : #i92538# add ~ in front of type 2009-05-07 14:37:13 +0200 oj r271667 : #i99118# change type from char to varchar 2009-05-07 14:36:23 +0200 oj r271666 : #i99118# clear dest columns when changing to create new table 2009-05-07 13:35:32 +0200 oj r271657 : #i94467# handle type 0 as double as well 2009-05-07 13:20:49 +0200 oj r271655 : i99743# setNull when varchar is no text 2009-05-07 12:58:06 +0200 fs r271651 : initialize the SdrObject's property change notifier after the ctor, if necessary 2009-05-07 11:47:18 +0200 fs r271647 : #i10000# 2009-05-07 10:57:16 +0200 fs r271639 : OPropertyBrowserController::propertyChange: care for the current property state, too, and properly forward it to the UI 2009-05-07 10:18:14 +0200 fs r271636 : onNewComponent: do not ask the map for grid columns, it will throw 2009-05-07 10:09:55 +0200 fs r271634 : #i101623# 2009-05-07 09:53:44 +0200 fs r271631 : #i101622# 2009-05-06 21:55:53 +0200 fs r271615 : #i10000# 2009-05-06 21:10:42 +0200 fs r271611 : #i10000# 2009-05-06 13:11:48 +0200 fs r271583 : #i10000# 2009-05-05 22:29:31 +0200 fs r271559 : proper assertion message 2009-05-05 22:29:03 +0200 fs r271558 : diagnostics 2009-05-05 22:16:16 +0200 fs r271557 : #i10000# 2009-05-05 13:50:32 +0200 fs r271513 : #i10000# 2009-05-05 10:21:50 +0200 fs r271503 : #i10000# 2009-05-05 09:30:26 +0200 fs r271501 : why did those survive the rebase -C step? 2009-05-05 09:18:12 +0200 fs r271500 : #i10000# 2009-05-04 17:08:17 +0200 fs r271475 : CWS-TOOLING: rebase CWS dba32b to trunk@271427 (milestone: DEV300:m47) 2009-05-04 14:51:26 +0200 fs r271456 : line ends 2009-04-30 15:55:27 +0200 fs r271418 : NewURL -> PublicConnectionURL 2009-04-22 21:18:34 +0200 fs r271141 : #i100944# 2009-04-22 09:12:26 +0200 oj r271071 : #i101261# little code change 2009-04-22 09:11:43 +0200 oj r271070 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:11:25 +0200 oj r271069 : #i101261# new grabage container for nodes 2009-04-22 09:11:02 +0200 oj r271068 : #i101261# new grabage container for nodes 2009-04-22 09:10:44 +0200 oj r271067 : #i101261# new grabage container for nodes 2009-04-22 09:10:21 +0200 oj r271066 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:08:24 +0200 oj r271065 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:07:25 +0200 oj r271064 : #i101261# only ask for parameters which aren't set before 2009-04-22 08:49:07 +0200 oj r271062 : #i77501# preview only when needed 2009-04-22 08:45:44 +0200 oj r271061 : #i101261# new prop max rows 2009-04-22 08:44:18 +0200 oj r271060 : #i101261# create dataprovider earlier to avoid the wrong legend in chart 2009-04-22 08:42:48 +0200 oj r271059 : #i101261# handle parameter 2009-04-17 21:00:23 +0200 fs r270954 : #i98350# 2009-04-17 13:54:19 +0200 fs r270942 : #i99565# 2009-04-17 13:51:34 +0200 fs r270940 : #i101153# only localize the (potentially) localizable properties when there really is support at the control model 2009-04-17 11:43:14 +0200 fs r270932 : removed superfluous include 2009-04-17 10:10:15 +0200 fs r270926 : #i10000# 2009-04-17 10:02:36 +0200 fs r270925 : #i10000# 2009-04-17 09:15:13 +0200 fs r270918 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 09:14:56 +0200 fs r270917 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 09:13:25 +0200 fs r270915 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 08:30:34 +0200 fs r270914 : removed unotools/servicehelper.hxx in favour of the (duplicated) comphelper/servicehelper.hxx 2009-04-16 21:05:25 +0200 fs r270903 : #i10000# 2009-04-16 20:43:43 +0200 fs r270902 : #i99056# shape notification outsourced to the SdrObject, this is what all other shape implementations (which only aggregate an SvxShape) have access to, too 2009-04-16 15:57:36 +0200 fs r270891 : #i99056# make SetUnoControlModel virtual 2009-04-16 15:44:02 +0200 fs r270890 : #i99056# let the ScShapeObj notify changes in its Anchor property 2009-04-16 15:36:47 +0200 fs r270889 : #i99056# enable the sheet anchor type property, too 2009-04-16 15:33:45 +0200 fs r270887 : #i99056# shape notification outsourced to the SdrObject, this is what all other shape implementations (which only aggregate an SvxShape) have access to, too 2009-04-15 14:53:13 +0200 fs r270844 : #i10000# 2009-04-15 13:08:29 +0200 fs r270836 : #i10000# 2009-04-15 12:28:14 +0200 fs r270832 : #i10000# 2009-04-15 10:59:14 +0200 fs r270827 : #i10000# 2009-04-15 09:41:08 +0200 oj r270823 : fix issues found with findbugs and pmd 2009-04-14 21:08:04 +0200 fs r270808 : #i99056# implement SheetAnchorType - now the only thing missing to enable it is the proper notification when it is modified 2009-04-14 17:09:00 +0200 fs r270799 : #i99056# implement XServiceInfo for the ScShapeObj 2009-04-14 17:07:55 +0200 fs r270798 : #i99056# implement TextAnchorType, partially implement SheetAnchorType 2009-04-14 15:54:05 +0200 fs r270786 : #i99056# SwXShape: notify changes of the AnchorType property 2009-04-14 15:47:32 +0200 fs r270785 : #i99056# deliver shapepropertynotifier.hxx 2009-04-14 15:46:54 +0200 fs r270784 : diagnostics 2009-04-14 15:08:28 +0200 fs r270781 : #i99056# outsourced the SvxShape's property change notification code into a dedicated class 2009-04-14 14:41:09 +0200 fs r270773 : #i99056# outsourced the SvxShape's property change notification code into a dedicated class 2009-04-14 14:37:23 +0200 fs r270772 : in dtor, remove the properties from the temporary component context 2009-04-14 14:36:34 +0200 fs r270771 : getWeakUnoShape made const 2009-04-14 12:23:08 +0200 oj r270757 : #i101064# add missing braces 2009-04-14 12:21:25 +0200 oj r270756 : #i101065# add braces for gcc 4.3.2 2009-04-14 12:17:45 +0200 oj r270755 : #i101059# add dep for manifest 2009-04-09 12:06:58 +0200 oj r270686 : #i93100# use OptimalSize from control to get height 2009-04-08 09:56:55 +0200 oj r270619 : #i92537# handle calculations in the select columns as well 2009-04-08 09:30:39 +0200 oj r270615 : #i96657# throw error message when the key doesn't have any columns 2009-04-07 12:08:26 +0200 oj r270592 : #i77501# impl preview of the executed report 2009-04-07 12:01:56 +0200 oj r270591 : #i77501# impl preview of the executed report 2009-04-07 11:41:03 +0200 oj r270590 : #i77501# impl preview of the executed report 2009-04-07 11:39:32 +0200 oj r270589 : #i77501# impl preview of the executed report 2009-04-07 11:29:25 +0200 oj r270588 : #i77501# convert dos to unix lineends 2009-04-07 11:28:23 +0200 oj r270587 : #i77501# impl preview of the executed report 2009-04-07 11:16:50 +0200 oj r270586 : #i77501# impl preview of the executed report 2009-04-07 11:16:00 +0200 oj r270585 : #i77501# impl preview of the executed report 2009-04-07 11:15:44 +0200 oj r270584 : #i77501# impl preview of the executed report 2009-04-07 11:15:28 +0200 oj r270583 : #i77501# impl preview of the executed report 2009-04-07 11:15:04 +0200 oj r270582 : #i77501# impl preview of the executed report 2009-04-06 15:38:54 +0200 fs r270559 : merge changes from CWS dba32a herein 2009-04-03 15:56:16 +0200 fs r270494 : ImpSvMEdit::Resize: do multiple iterations, if necessary 2009-04-03 14:35:49 +0200 fs r270487 : #i10000# 2009-04-03 13:17:16 +0200 fs r270476 : #i99056# display geometry information for controls, too 2009-04-03 13:16:37 +0200 fs r270475 : #i99056# better ordering of the geometry properties 2009-04-03 13:16:07 +0200 fs r270473 : #i99056# now that SvxShape supports property change listeners, forward add/remove requests to it 2009-04-03 13:13:18 +0200 fs r270472 : #i99056# at SvxShape, allow for PropertyChangeListeners for Size/Position 2009-04-03 09:29:27 +0200 oj r270456 : #i94571# use correct prop name 2009-04-03 09:14:54 +0200 fs r270451 : merge changes from CWS dba32a herein 2009-04-02 17:00:51 +0200 fs r270424 : better diagnostics 2009-04-02 16:35:19 +0200 fs r270421 : diagnostics 2009-04-02 16:34:50 +0200 fs r270420 : #i99056# mxUnoShape not accessible anymore, use impl_setUnoShape instead 2009-04-02 16:32:48 +0200 fs r270419 : #i99056# make getUnoShape cheaper: keep the pointer to the SvxShape all the time, so there's no need to ask for it in getUnoShape. As a consequence, we will later be able to use the pointer in scenarious where performance (potentially) matters 2009-04-02 16:31:13 +0200 fs r270417 : merge changes from CWS dba32a herein 2009-04-02 16:23:16 +0200 fs r270414 : merge changes from CWS dba32a herein 2009-04-02 14:10:35 +0200 fs r270405 : #i10000# 2009-04-02 14:06:26 +0200 fs r270404 : merge changes from CWS dba32a herein 2009-04-02 14:03:03 +0200 fs r270401 : #i10000# 2009-04-02 13:58:13 +0200 fs r270400 : #i10000# 2009-04-02 12:59:44 +0200 fs r270397 : merge changes from CWS dba32a herein 2009-04-02 12:46:30 +0200 fs r270396 : #i99056# let the form page maintain a mapping between control models and control shapes 2009-04-02 12:44:07 +0200 fs r270395 : merge changes from CWS dba32a herein 2009-04-02 12:42:06 +0200 fs r270394 : merge changes from CWS dba32a herein 2009-04-02 12:35:20 +0200 fs r270393 : #i10000# precompiled header 2009-04-02 12:05:31 +0200 fs r270392 : merge changes from CWS dba32a herein 2009-04-02 12:00:42 +0200 fs r270391 : merge changes from CWS dba32a herein 2009-04-02 11:47:26 +0200 fs r270390 : merge changes from CWS dba32a herein 2009-04-02 11:39:15 +0200 oj r270389 : #i94467# foxpro impl several new types 2009-04-02 11:35:58 +0200 fs r270387 : merge changes from CWS dba32a herein 2009-04-01 14:10:51 +0200 fs r270329 : merge changes from CWS dba32a herein 2009-03-31 17:29:50 +0200 fs r270290 : merge changes from CWS dba32a herein 2009-03-30 14:53:56 +0200 fs r270233 : #i100417# don't set grid column widths to 0, but to <void/> 2009-03-30 12:31:03 +0200 oj r270213 : #i100552# wrong orb used 2009-03-30 12:19:20 +0200 oj r270212 : #i98303# convertlike corrected to sal_Unicode 2009-03-30 11:58:25 +0200 fs r270210 : merge changes from CWS dba32a herein 2009-03-30 11:38:16 +0200 oj r270205 : remove duplicate code from merge 2009-03-30 11:02:27 +0200 fs r270202 : merge changes from CWS dba32a herein 2009-03-30 11:02:19 +0200 fs r270201 : merge changes from CWS dba32a herein 2009-03-30 10:31:26 +0200 oj r270200 : #i100665# only throw exception and do not drop table 2009-03-30 09:36:24 +0200 fs r270195 : assertion text 2009-03-28 20:21:58 +0100 fs r270187 : #ii10000# 2009-03-28 20:19:54 +0100 fs r270186 : removed unused help ids 2009-03-28 20:19:40 +0100 fs r270185 : removed unused help ids 2009-03-28 20:19:10 +0100 fs r270184 : #i100237# +DefaultState/XReset 2009-03-28 00:29:29 +0100 fs r270177 : CWS-TOOLING: rebase CWS dba32b to trunk@270033 (milestone: DEV300:m45) 2009-03-27 22:56:46 +0100 fs r270173 : #i100237# DEFAULT_CHECKED -> DEFAULT_STATE 2009-03-27 22:55:52 +0100 fs r270172 : #i100237# DefaultState property for buttons, enabled only when Toggle=Yes 2009-03-27 22:54:15 +0100 fs r270171 : #i100237# DEFAULT_CHECKED -> DEFAULT_STATE 2009-03-27 22:53:54 +0100 fs r270170 : #i100237# introduce a DefaultState property for buttons, which implies buttongs supporting XReset, which needed some refactoring 2009-03-27 13:31:41 +0100 fs r270152 : ignore output paths 2009-03-27 11:23:44 +0100 fs r270139 : tuned behavior with respect to invalid keys/values 2009-03-27 09:57:14 +0100 fs r270136 : don't allow Double.NaN 2009-03-27 09:56:16 +0100 fs r270135 : talk about Double.NaN 2009-03-26 12:14:30 +0100 fs r270067 : removed unused parameter 2009-03-26 12:14:02 +0100 fs r270066 : removed widening conversion when checking keys 2009-03-26 09:17:34 +0100 fs r270053 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-26 09:17:11 +0100 fs r270052 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-26 09:16:49 +0100 fs r270051 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-25 21:55:20 +0100 fs r270044 : #i100541# properly calculat bNeedScrollBox 2009-03-25 12:56:17 +0100 fs r270019 : renamed the previously introduced error condition 2009-03-25 12:11:48 +0100 fs r270015 : #i100095# when the error messages contain non-trivial details (SQLState/ErrorCode), then always display the 'Details' button 2009-03-25 12:10:05 +0100 fs r270012 : renamed the previously introduced error condition 2009-03-25 12:01:04 +0100 fs r270011 : #i100095# when no address book (or respective profile) can be found, then use a dedicated ErrorCondition 2009-03-25 10:29:07 +0100 fs r270003 : add missing localization 2009-03-25 10:23:12 +0100 fs r270001 : in preparation of #i1000095#: rework the error handling, allow using css.sdb.ErrorCondition values, plus allow propagating the nsresult 2009-03-25 10:21:55 +0100 fs r270000 : in preparation of #i1000095#: rework the error handling, allow using css.sdb.ErrorCondition values, plus allow propagating the nsresult 2009-03-20 23:05:38 +0100 fs r269829 : XMap::getSize removed 2009-03-20 23:05:19 +0100 fs r269828 : changes as suggested by sb 2009-03-20 23:04:56 +0100 fs r269827 : enhanced documentation 2009-03-20 15:31:40 +0100 fs r269815 : changes as suggested by sb 2009-03-20 13:23:52 +0100 oj r269804 : #i92538# correct the zorder that fixedtext is infront of control 2009-03-20 12:59:38 +0100 oj r269801 : #i94571# paraadjust now supports BLOCK 2009-03-20 12:58:11 +0100 oj r269800 : #i94571# export style with data style 2009-03-20 12:57:05 +0100 oj r269799 : #i94571# text align is now paraadjust 2009-03-20 12:37:02 +0100 fs r269797 : enum keys only accepted if they have the exact type, not if they have *any* enum type 2009-03-20 12:28:31 +0100 fs r269794 : some changes requested by sb 2009-03-20 08:52:47 +0100 fs r269780 : doc 2009-03-20 07:37:31 +0100 oj r269779 : #i99913# only notifiy when values are different 2009-03-20 07:36:58 +0100 oj r269778 : #i99913# add undoenv as listener at the dataprovider 2009-03-19 22:52:52 +0100 fs r269771 : added comment 2009-03-19 22:40:06 +0100 fs r269770 : +testEnumeration 2009-03-19 22:39:41 +0100 fs r269769 : implemented enumeration, getKeySet, and getValues. Should be finished now. 2009-03-19 14:01:01 +0100 oj r269743 : #i99913# reset the modified state when selecting an object 2009-03-19 12:19:54 +0100 lla r269739 : #i72390# cleanups 2009-03-19 09:25:27 +0100 fs r269727 : #i10000# 2009-03-18 23:37:02 +0100 fs r269708 : extended checks for value type acceptance 2009-03-18 23:36:41 +0100 fs r269707 : fixed value type checks 2009-03-18 14:59:56 +0100 fs r269678 : initial complex test case for the new css.container.Map implementation 2009-03-18 14:59:24 +0100 fs r269677 : verifyExpectedException moved to base class (in complexlib), and renamed to assureException for consistency 2009-03-18 14:58:35 +0100 fs r269676 : removed unused imports 2009-03-18 14:58:03 +0100 fs r269675 : first implementation of the new css.container.Map service (not completed, yet) 2009-03-18 14:57:17 +0100 fs r269674 : base class for UNO components, freeing you from some repeating work 2009-03-18 14:55:53 +0100 fs r269672 : +assureException: call a given method with given parameters on a given object, ensure that a given exception is thrown by the method implementation 2009-03-18 14:54:58 +0100 fs r269671 : +getComponentContext 2009-03-18 14:54:00 +0100 fs r269670 : isEmpty returns a boolean, not a long 2009-03-18 14:14:43 +0100 oj r269663 : #i99743# now text also supports null 2009-03-18 13:54:14 +0100 oj r269660 : #i99223# remove check for 2 params 2009-03-18 13:33:35 +0100 oj r269659 : #i99060# replace text::ParagraphVertAlign with style::VerticalAlignment 2009-03-18 13:32:18 +0100 oj r269658 : #i99060# don't set void property when void isn't allowed 2009-03-18 13:31:11 +0100 oj r269657 : #i99060# handle vertical alignment 2009-03-18 13:28:28 +0100 oj r269656 : #i99060# remove unused elements from sytle 2009-03-18 09:35:42 +0100 lla r269639 : #i72390# cleanups 2009-03-18 09:31:20 +0100 lla r269638 : #i72390# add ButtonList 2009-03-18 09:30:46 +0100 lla r269637 : #i72390# renamed interface 2009-03-18 09:30:15 +0100 lla r269636 : #i72390# use ButtonList instead of ImageList 2009-03-18 09:29:05 +0100 lla r269635 : #i72390# new ButtonList, cleanups 2009-03-18 09:26:34 +0100 lla r269634 : #i72390# cleanups 2009-03-17 12:21:20 +0100 oj r269590 : #i99222# remove assertion 2009-03-17 12:17:22 +0100 oj r269589 : #i98605# impl scale mode 2009-03-17 12:10:42 +0100 oj r269588 : #i98605# impl scale mode 2009-03-17 11:40:15 +0100 oj r269584 : #i96944# doesn't create equation for shapes 2009-03-17 11:33:16 +0100 oj r269583 : #i96423# switch calc from float to long 2009-03-16 15:19:18 +0100 fs r269550 : #i41930# enable zoom for embedded/outplace documents 2009-03-16 14:25:54 +0100 oj r269542 : #i93734# remove ContextSensitive 2009-03-16 14:21:58 +0100 oj r269541 : #i99274# page header before group header 2009-03-16 14:18:23 +0100 oj r269539 : #i99110# fix value type 2009-03-16 14:14:16 +0100 fs r269537 : line ends 2009-03-16 14:11:06 +0100 fs r269535 : line ends 2009-03-16 14:08:34 +0100 fs r269534 : #i100087# (provided my np): allow for polymorphic types with more than one parameter 2009-03-16 12:30:31 +0100 oj r269521 : compile error 2009-03-16 12:19:12 +0100 oj r269519 : compile error 2009-03-16 10:39:28 +0100 oj r269511 : compile error under linux with swap 2009-03-13 10:33:04 +0100 oj r269462 : CWS-TOOLING: rebase CWS dba32b to trunk@269297 (milestone: DEV300:m43) 2009-03-12 14:37:25 +0100 fs r269416 : interface SequenceOutputStreamTest is unneeded, and pollutes the namespace here :) 2009-03-12 14:35:07 +0100 fs r269414 : not needed 2009-03-12 14:34:15 +0100 fs r269413 : preparation for multiple tests in this module 2009-03-12 14:33:02 +0100 fs r269412 : ShowTargets was moved from module integration.forms to module complexlib 2009-03-12 14:32:48 +0100 fs r269411 : helper class for projects containing multiple complex test cases (and following a certain structure) 2009-03-12 14:00:14 +0100 fs r269407 : proper module after the move 2009-03-12 13:59:10 +0100 fs r269406 : superseded by ../makefile.mk 2009-03-12 13:47:38 +0100 fs r269403 : not needed anymore 2009-03-12 13:45:46 +0100 fs r269402 : moved, in preparation of adding more test cases here, with a common infrastructure 2009-03-12 13:45:07 +0100 fs r269401 : moved from ../ 2009-03-12 13:43:59 +0100 fs r269400 : moved to ./comphelper, in preparation of adding more test cases here, with a common infrastructure 2009-03-12 13:29:47 +0100 oj r269396 : #i99914# set parent on dataprovider 2009-03-12 13:10:35 +0100 oj r269393 : #i99832# check thrown exception and show error 2009-03-12 13:08:10 +0100 fs r269392 : reorganizing tests 2009-03-12 12:52:55 +0100 oj r269390 : #i99118# convert formatkey in numberformat 2009-03-12 12:34:53 +0100 fs r269388 : new API tests 2009-03-12 12:29:05 +0100 fs r269386 : Map not yet committed 2009-03-12 12:28:36 +0100 fs r269385 : oops, forgot the SequenceInputStream during the previous refactoring 2009-03-12 12:12:39 +0100 oj r269384 : #i99104# set HasCategories prop 2009-03-12 12:12:08 +0100 oj r269383 : #i99104# check HasCategories even for internal dataprovider 2009-03-12 12:10:40 +0100 oj r269382 : #i99104# set HasCategories prop 2009-03-12 10:51:49 +0100 fs r269373 : #i10000# exception specifications 2009-03-12 10:49:18 +0100 fs r269372 : #i10000# exception specifications 2009-03-12 10:44:02 +0100 fs r269371 : #i10000# exception specifications 2009-03-12 10:30:55 +0100 fs r269368 : refactored the UNO service registration in this module, using the helper classes provided by comphelper itself, so you have less effort when extending the list of to-be-registered components 2009-03-12 10:30:37 +0100 fs r269367 : module-local includes 2009-03-12 07:05:54 +0100 oj r269357 : #i99104# database dataprovider doesn't need dataranges and diagramdata 2009-03-11 10:58:28 +0100 oj r269306 : #i99911# check if name of the report is a valid file name 2009-03-11 10:03:23 +0100 oj r269299 : #i99666# the report is new when the HierarchicalDocumentName is empty 2009-03-10 11:32:45 +0100 oj r269258 : #i99221# use fallback for language 2009-03-10 10:48:40 +0100 oj r269255 : #i99433# now use OStringBuffer 2009-03-10 10:36:21 +0100 fs r269252 : initial version of (X)Map 2009-03-10 09:52:23 +0100 oj r269246 : #i99433# now use OStringBuffer 2009-03-10 08:56:13 +0100 oj r269240 : #i99655# patch applied 2009-03-09 07:35:33 +0100 lla r269058 : #i10000# wrong variable assignment fixed 2009-03-06 17:20:40 +0100 fs r269030 : some explicit defaults 2009-03-06 17:20:30 +0100 fs r269029 : #i98600# 2009-03-06 14:40:34 +0100 fs r269009 : #i87692# during reload, prevent the document being modified just because of some control content changes ... 2009-03-06 12:52:20 +0100 lla r268997 : #i10000# ambigous problem with FontWeight fixed 2009-03-06 11:39:32 +0100 fs r268989 : #i10000# (approved by pl): use --without-t1-library configure option 2009-03-06 10:55:43 +0100 fs r268986 : #i99953# depends on xmlscript module now 2009-03-06 10:54:04 +0100 fs r268985 : #i99953# also adjust the event names found in dialogs embedded in the forms 2009-03-06 09:53:41 +0100 fs r268977 : #i10000# 2009-03-06 09:30:41 +0100 lla r268973 : #i10000# merge problems 2009-03-05 17:52:34 +0100 fs r268932 : #i98593# for sub components which are actually controlled by a DocumentDefinition (aka XComponentSupplier aka XCommandProcessor), close them by executing the 'close' command, not by suspending/closing the controller (which cannot be intercepted) 2009-03-05 11:41:56 +0100 fs r268889 : default the drop down line count for list/combo boxes to 20 2009-03-05 11:39:10 +0100 fs r268887 : do not display empty error messages 2009-03-02 10:13:57 +0100 lla r268639 : #i91541# CWS rebase m41 to m42 2009-03-02 09:06:27 +0100 lla r268635 : #i10000# add ';' to strings 2009-02-26 11:18:00 +0100 fs r268492 : reportdesign depends on REPORTBUILDER, not REPORTDESIGN 2009-02-26 10:11:38 +0100 lla r268489 : CWS-TOOLING: rebase CWS dba32b to trunk@268395 (milestone: DEV300:m42) 2009-02-26 09:04:11 +0100 lla r268488 : CWS-TOOLING: rebase CWS dba32b to trunk@268395 (milestone: DEV300:m42) 2009-02-24 12:09:13 +0100 lla r268392 : #i91541# #i91542# cleanups 2009-02-24 08:08:06 +0100 lla r268382 : merge all dba32a changes into dba32b 2009-02-24 07:14:55 +0100 lla r268381 : merge all dba32a changes into dba32b 2009-02-23 21:44:28 +0100 fs r268377 : oops ... don't tamper with m_aListSourceValues at the end of loadData 2009-02-23 20:57:05 +0100 fs r268376 : #i98162# don't hold the values as strings, but as ORowSetValue, this way preserving their type, and being agnostic to different result/rowset implementations doing different to-string-conversations 2009-02-23 20:55:44 +0100 fs r268375 : getObject: throwFunctionNotSupportedException, instead of silently returning NULL 2009-02-23 20:55:20 +0100 fs r268374 : #i98162# some more supported types 2009-02-23 20:54:43 +0100 fs r268373 : #i98162# +operator != 2009-02-20 09:35:39 +0100 fs r268306 : #i99422# for a font, display the font name, the style, and the size 2009-02-20 09:33:45 +0100 fs r268305 : #i99422# in the property browser, FONT supersedes CHARFONTNAME: the aggregated FormComponentHandler displays them more nicely now 2009-02-19 16:12:06 +0100 fs r268293 : #i99372# recognize DataType::FLOAT as numeric 2009-02-19 15:43:12 +0100 fs r268291 : #i99415# 2009-02-19 15:40:15 +0100 fs r268290 : #i99242# lcl_firstFocussableControl: take disabled controls into account 2009-02-19 15:34:36 +0100 fs r268289 : #i99396# properly decode the base name of the URL when using it as title 2009-02-19 15:19:05 +0100 fs r268287 : #i98247#
2009-06-05 09:47:55 +00:00
// forward the new value to the property box, to reflect the change in the UI
aNewValue = impl_getPropertyValue_throw( _rEvent.PropertyName );
CWS-TOOLING: integrate CWS dba32b 2009-06-03 14:58:08 +0200 fs r272581 : #i102439# 2009-05-29 13:56:18 +0200 fs r272456 : remove the sub form when the 'add subform' setting changes from <true/> to <false/>, not only its controls 2009-05-29 13:19:27 +0200 fs r272454 : display '(Default)' instead of an empty string when a control has the default font 2009-05-28 20:49:18 +0200 fs r272428 : #i98162# getFirstSelectedValue: do not return reference to a temporary 2009-05-27 15:30:22 +0200 msc r272353 : #102303# 2009-05-26 13:03:06 +0200 fs r272295 : spelling 2009-05-26 12:59:54 +0200 fs r272294 : merge m48 version to get latest cygwin related fixes 2009-05-25 14:02:06 +0200 fs r272239 : remove references to local files, needed for debugging sessions only 2009-05-25 14:01:16 +0200 fs r272238 : #i102021# ensure members such as bNumberFormat are initialized before actually returning them 2009-05-25 13:10:20 +0200 fs r272236 : #i10000# reset ENABLE_EVOAB2 2009-05-22 06:44:45 +0200 oj r272167 : #i99104# add import handler for calc-sett 2009-05-22 06:42:27 +0200 oj r272166 : #i99104# impl NullDate as member 2009-05-22 06:36:22 +0200 oj r272165 : #i99104# handle nulldate from parent model 2009-05-22 06:33:13 +0200 oj r272164 : #i99104# export and import calculation-settings and nulldate 2009-05-22 06:27:50 +0200 oj r272163 : #i99104# export and import calculation-settings and nulldate 2009-05-20 13:29:58 +0200 oj r272118 : #i99911# handle invalid name 2009-05-20 13:28:49 +0200 oj r272117 : #i101261# handle different rowsets 2009-05-20 11:29:55 +0200 msc r272111 : #i100000# 2009-05-20 11:28:27 +0200 msc r272110 : merge in change from dba32a 2009-05-20 11:27:38 +0200 msc r272109 : #102082# CTRL + C does not work 2009-05-20 09:43:36 +0200 oj r272106 : clean up includes 2009-05-20 09:32:15 +0200 oj r272105 : #i99060# merge error resovled now VERTICAL_ALIGN is in both stmt 2009-05-20 08:37:21 +0200 msc r272104 : add workaround for issue #102010# 2009-05-20 08:10:12 +0200 oj r272103 : #i99104# use numberformatkey 2009-05-20 08:07:02 +0200 oj r272102 : #i99104# use column info from rowset 2009-05-20 08:04:43 +0200 oj r272101 : #i102032# use a special column type where prec and scale are the values currently set at the column 2009-05-20 08:03:04 +0200 oj r272100 : #i102032# correct type info, we have to use SQL defined type names 2009-05-19 10:27:02 +0200 oj r272061 : #i99104# export null-date 2009-05-19 08:26:53 +0200 oj r272056 : #i99104# export null-date 2009-05-18 13:15:10 +0200 msc r272014 : add issue #102019# 2009-05-18 11:33:07 +0200 msc r272005 : add issue #102019# 2009-05-18 08:59:45 +0200 msc r271996 : add workaroud for issue #102010# 2009-05-15 10:21:24 +0200 msc r271929 : #101944# 2009-05-11 21:18:30 +0200 fs r271792 : #i99914# 2009-05-08 13:52:06 +0200 oj r271715 : #i96423# remember column span 2009-05-08 11:26:19 +0200 oj r271708 : #i98605# impl new scale mode 2009-05-08 10:33:35 +0200 fs r271706 : SendUserCall: only call into the shape notification routine for UserCall types where this is necessary (performance issue) 2009-05-07 20:52:44 +0200 fs r271698 : outsource ShapeProperty from shapepropertynotifier.hxx 2009-05-07 20:43:33 +0200 fs r271697 : #i99056# use notifyShapePropertyChange, instead of getShapePropertyChangeNotifier - the latter throws if no shape exists, yet 2009-05-07 20:33:58 +0200 fs r271696 : #i99056# +notifyShapePropertyChange: allow notifying chages without checking whether there actually already exists an SvxShape 2009-05-07 16:22:15 +0200 fs r271679 : #i10000# cygwin needs quotes around the classpath 2009-05-07 16:21:37 +0200 fs r271678 : #i10000# cygwin needs quotes around the classpath 2009-05-07 16:01:11 +0200 oj r271677 : #i99914# notify parent handler 2009-05-07 15:54:54 +0200 fs r271676 : #i10000# cygwin needs some quoting 2009-05-07 14:49:48 +0200 oj r271672 : #i99277# quote alias name 2009-05-07 14:48:12 +0200 oj r271671 : #i92538# add ~ in front of type 2009-05-07 14:37:13 +0200 oj r271667 : #i99118# change type from char to varchar 2009-05-07 14:36:23 +0200 oj r271666 : #i99118# clear dest columns when changing to create new table 2009-05-07 13:35:32 +0200 oj r271657 : #i94467# handle type 0 as double as well 2009-05-07 13:20:49 +0200 oj r271655 : i99743# setNull when varchar is no text 2009-05-07 12:58:06 +0200 fs r271651 : initialize the SdrObject's property change notifier after the ctor, if necessary 2009-05-07 11:47:18 +0200 fs r271647 : #i10000# 2009-05-07 10:57:16 +0200 fs r271639 : OPropertyBrowserController::propertyChange: care for the current property state, too, and properly forward it to the UI 2009-05-07 10:18:14 +0200 fs r271636 : onNewComponent: do not ask the map for grid columns, it will throw 2009-05-07 10:09:55 +0200 fs r271634 : #i101623# 2009-05-07 09:53:44 +0200 fs r271631 : #i101622# 2009-05-06 21:55:53 +0200 fs r271615 : #i10000# 2009-05-06 21:10:42 +0200 fs r271611 : #i10000# 2009-05-06 13:11:48 +0200 fs r271583 : #i10000# 2009-05-05 22:29:31 +0200 fs r271559 : proper assertion message 2009-05-05 22:29:03 +0200 fs r271558 : diagnostics 2009-05-05 22:16:16 +0200 fs r271557 : #i10000# 2009-05-05 13:50:32 +0200 fs r271513 : #i10000# 2009-05-05 10:21:50 +0200 fs r271503 : #i10000# 2009-05-05 09:30:26 +0200 fs r271501 : why did those survive the rebase -C step? 2009-05-05 09:18:12 +0200 fs r271500 : #i10000# 2009-05-04 17:08:17 +0200 fs r271475 : CWS-TOOLING: rebase CWS dba32b to trunk@271427 (milestone: DEV300:m47) 2009-05-04 14:51:26 +0200 fs r271456 : line ends 2009-04-30 15:55:27 +0200 fs r271418 : NewURL -> PublicConnectionURL 2009-04-22 21:18:34 +0200 fs r271141 : #i100944# 2009-04-22 09:12:26 +0200 oj r271071 : #i101261# little code change 2009-04-22 09:11:43 +0200 oj r271070 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:11:25 +0200 oj r271069 : #i101261# new grabage container for nodes 2009-04-22 09:11:02 +0200 oj r271068 : #i101261# new grabage container for nodes 2009-04-22 09:10:44 +0200 oj r271067 : #i101261# new grabage container for nodes 2009-04-22 09:10:21 +0200 oj r271066 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:08:24 +0200 oj r271065 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:07:25 +0200 oj r271064 : #i101261# only ask for parameters which aren't set before 2009-04-22 08:49:07 +0200 oj r271062 : #i77501# preview only when needed 2009-04-22 08:45:44 +0200 oj r271061 : #i101261# new prop max rows 2009-04-22 08:44:18 +0200 oj r271060 : #i101261# create dataprovider earlier to avoid the wrong legend in chart 2009-04-22 08:42:48 +0200 oj r271059 : #i101261# handle parameter 2009-04-17 21:00:23 +0200 fs r270954 : #i98350# 2009-04-17 13:54:19 +0200 fs r270942 : #i99565# 2009-04-17 13:51:34 +0200 fs r270940 : #i101153# only localize the (potentially) localizable properties when there really is support at the control model 2009-04-17 11:43:14 +0200 fs r270932 : removed superfluous include 2009-04-17 10:10:15 +0200 fs r270926 : #i10000# 2009-04-17 10:02:36 +0200 fs r270925 : #i10000# 2009-04-17 09:15:13 +0200 fs r270918 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 09:14:56 +0200 fs r270917 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 09:13:25 +0200 fs r270915 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 08:30:34 +0200 fs r270914 : removed unotools/servicehelper.hxx in favour of the (duplicated) comphelper/servicehelper.hxx 2009-04-16 21:05:25 +0200 fs r270903 : #i10000# 2009-04-16 20:43:43 +0200 fs r270902 : #i99056# shape notification outsourced to the SdrObject, this is what all other shape implementations (which only aggregate an SvxShape) have access to, too 2009-04-16 15:57:36 +0200 fs r270891 : #i99056# make SetUnoControlModel virtual 2009-04-16 15:44:02 +0200 fs r270890 : #i99056# let the ScShapeObj notify changes in its Anchor property 2009-04-16 15:36:47 +0200 fs r270889 : #i99056# enable the sheet anchor type property, too 2009-04-16 15:33:45 +0200 fs r270887 : #i99056# shape notification outsourced to the SdrObject, this is what all other shape implementations (which only aggregate an SvxShape) have access to, too 2009-04-15 14:53:13 +0200 fs r270844 : #i10000# 2009-04-15 13:08:29 +0200 fs r270836 : #i10000# 2009-04-15 12:28:14 +0200 fs r270832 : #i10000# 2009-04-15 10:59:14 +0200 fs r270827 : #i10000# 2009-04-15 09:41:08 +0200 oj r270823 : fix issues found with findbugs and pmd 2009-04-14 21:08:04 +0200 fs r270808 : #i99056# implement SheetAnchorType - now the only thing missing to enable it is the proper notification when it is modified 2009-04-14 17:09:00 +0200 fs r270799 : #i99056# implement XServiceInfo for the ScShapeObj 2009-04-14 17:07:55 +0200 fs r270798 : #i99056# implement TextAnchorType, partially implement SheetAnchorType 2009-04-14 15:54:05 +0200 fs r270786 : #i99056# SwXShape: notify changes of the AnchorType property 2009-04-14 15:47:32 +0200 fs r270785 : #i99056# deliver shapepropertynotifier.hxx 2009-04-14 15:46:54 +0200 fs r270784 : diagnostics 2009-04-14 15:08:28 +0200 fs r270781 : #i99056# outsourced the SvxShape's property change notification code into a dedicated class 2009-04-14 14:41:09 +0200 fs r270773 : #i99056# outsourced the SvxShape's property change notification code into a dedicated class 2009-04-14 14:37:23 +0200 fs r270772 : in dtor, remove the properties from the temporary component context 2009-04-14 14:36:34 +0200 fs r270771 : getWeakUnoShape made const 2009-04-14 12:23:08 +0200 oj r270757 : #i101064# add missing braces 2009-04-14 12:21:25 +0200 oj r270756 : #i101065# add braces for gcc 4.3.2 2009-04-14 12:17:45 +0200 oj r270755 : #i101059# add dep for manifest 2009-04-09 12:06:58 +0200 oj r270686 : #i93100# use OptimalSize from control to get height 2009-04-08 09:56:55 +0200 oj r270619 : #i92537# handle calculations in the select columns as well 2009-04-08 09:30:39 +0200 oj r270615 : #i96657# throw error message when the key doesn't have any columns 2009-04-07 12:08:26 +0200 oj r270592 : #i77501# impl preview of the executed report 2009-04-07 12:01:56 +0200 oj r270591 : #i77501# impl preview of the executed report 2009-04-07 11:41:03 +0200 oj r270590 : #i77501# impl preview of the executed report 2009-04-07 11:39:32 +0200 oj r270589 : #i77501# impl preview of the executed report 2009-04-07 11:29:25 +0200 oj r270588 : #i77501# convert dos to unix lineends 2009-04-07 11:28:23 +0200 oj r270587 : #i77501# impl preview of the executed report 2009-04-07 11:16:50 +0200 oj r270586 : #i77501# impl preview of the executed report 2009-04-07 11:16:00 +0200 oj r270585 : #i77501# impl preview of the executed report 2009-04-07 11:15:44 +0200 oj r270584 : #i77501# impl preview of the executed report 2009-04-07 11:15:28 +0200 oj r270583 : #i77501# impl preview of the executed report 2009-04-07 11:15:04 +0200 oj r270582 : #i77501# impl preview of the executed report 2009-04-06 15:38:54 +0200 fs r270559 : merge changes from CWS dba32a herein 2009-04-03 15:56:16 +0200 fs r270494 : ImpSvMEdit::Resize: do multiple iterations, if necessary 2009-04-03 14:35:49 +0200 fs r270487 : #i10000# 2009-04-03 13:17:16 +0200 fs r270476 : #i99056# display geometry information for controls, too 2009-04-03 13:16:37 +0200 fs r270475 : #i99056# better ordering of the geometry properties 2009-04-03 13:16:07 +0200 fs r270473 : #i99056# now that SvxShape supports property change listeners, forward add/remove requests to it 2009-04-03 13:13:18 +0200 fs r270472 : #i99056# at SvxShape, allow for PropertyChangeListeners for Size/Position 2009-04-03 09:29:27 +0200 oj r270456 : #i94571# use correct prop name 2009-04-03 09:14:54 +0200 fs r270451 : merge changes from CWS dba32a herein 2009-04-02 17:00:51 +0200 fs r270424 : better diagnostics 2009-04-02 16:35:19 +0200 fs r270421 : diagnostics 2009-04-02 16:34:50 +0200 fs r270420 : #i99056# mxUnoShape not accessible anymore, use impl_setUnoShape instead 2009-04-02 16:32:48 +0200 fs r270419 : #i99056# make getUnoShape cheaper: keep the pointer to the SvxShape all the time, so there's no need to ask for it in getUnoShape. As a consequence, we will later be able to use the pointer in scenarious where performance (potentially) matters 2009-04-02 16:31:13 +0200 fs r270417 : merge changes from CWS dba32a herein 2009-04-02 16:23:16 +0200 fs r270414 : merge changes from CWS dba32a herein 2009-04-02 14:10:35 +0200 fs r270405 : #i10000# 2009-04-02 14:06:26 +0200 fs r270404 : merge changes from CWS dba32a herein 2009-04-02 14:03:03 +0200 fs r270401 : #i10000# 2009-04-02 13:58:13 +0200 fs r270400 : #i10000# 2009-04-02 12:59:44 +0200 fs r270397 : merge changes from CWS dba32a herein 2009-04-02 12:46:30 +0200 fs r270396 : #i99056# let the form page maintain a mapping between control models and control shapes 2009-04-02 12:44:07 +0200 fs r270395 : merge changes from CWS dba32a herein 2009-04-02 12:42:06 +0200 fs r270394 : merge changes from CWS dba32a herein 2009-04-02 12:35:20 +0200 fs r270393 : #i10000# precompiled header 2009-04-02 12:05:31 +0200 fs r270392 : merge changes from CWS dba32a herein 2009-04-02 12:00:42 +0200 fs r270391 : merge changes from CWS dba32a herein 2009-04-02 11:47:26 +0200 fs r270390 : merge changes from CWS dba32a herein 2009-04-02 11:39:15 +0200 oj r270389 : #i94467# foxpro impl several new types 2009-04-02 11:35:58 +0200 fs r270387 : merge changes from CWS dba32a herein 2009-04-01 14:10:51 +0200 fs r270329 : merge changes from CWS dba32a herein 2009-03-31 17:29:50 +0200 fs r270290 : merge changes from CWS dba32a herein 2009-03-30 14:53:56 +0200 fs r270233 : #i100417# don't set grid column widths to 0, but to <void/> 2009-03-30 12:31:03 +0200 oj r270213 : #i100552# wrong orb used 2009-03-30 12:19:20 +0200 oj r270212 : #i98303# convertlike corrected to sal_Unicode 2009-03-30 11:58:25 +0200 fs r270210 : merge changes from CWS dba32a herein 2009-03-30 11:38:16 +0200 oj r270205 : remove duplicate code from merge 2009-03-30 11:02:27 +0200 fs r270202 : merge changes from CWS dba32a herein 2009-03-30 11:02:19 +0200 fs r270201 : merge changes from CWS dba32a herein 2009-03-30 10:31:26 +0200 oj r270200 : #i100665# only throw exception and do not drop table 2009-03-30 09:36:24 +0200 fs r270195 : assertion text 2009-03-28 20:21:58 +0100 fs r270187 : #ii10000# 2009-03-28 20:19:54 +0100 fs r270186 : removed unused help ids 2009-03-28 20:19:40 +0100 fs r270185 : removed unused help ids 2009-03-28 20:19:10 +0100 fs r270184 : #i100237# +DefaultState/XReset 2009-03-28 00:29:29 +0100 fs r270177 : CWS-TOOLING: rebase CWS dba32b to trunk@270033 (milestone: DEV300:m45) 2009-03-27 22:56:46 +0100 fs r270173 : #i100237# DEFAULT_CHECKED -> DEFAULT_STATE 2009-03-27 22:55:52 +0100 fs r270172 : #i100237# DefaultState property for buttons, enabled only when Toggle=Yes 2009-03-27 22:54:15 +0100 fs r270171 : #i100237# DEFAULT_CHECKED -> DEFAULT_STATE 2009-03-27 22:53:54 +0100 fs r270170 : #i100237# introduce a DefaultState property for buttons, which implies buttongs supporting XReset, which needed some refactoring 2009-03-27 13:31:41 +0100 fs r270152 : ignore output paths 2009-03-27 11:23:44 +0100 fs r270139 : tuned behavior with respect to invalid keys/values 2009-03-27 09:57:14 +0100 fs r270136 : don't allow Double.NaN 2009-03-27 09:56:16 +0100 fs r270135 : talk about Double.NaN 2009-03-26 12:14:30 +0100 fs r270067 : removed unused parameter 2009-03-26 12:14:02 +0100 fs r270066 : removed widening conversion when checking keys 2009-03-26 09:17:34 +0100 fs r270053 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-26 09:17:11 +0100 fs r270052 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-26 09:16:49 +0100 fs r270051 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-25 21:55:20 +0100 fs r270044 : #i100541# properly calculat bNeedScrollBox 2009-03-25 12:56:17 +0100 fs r270019 : renamed the previously introduced error condition 2009-03-25 12:11:48 +0100 fs r270015 : #i100095# when the error messages contain non-trivial details (SQLState/ErrorCode), then always display the 'Details' button 2009-03-25 12:10:05 +0100 fs r270012 : renamed the previously introduced error condition 2009-03-25 12:01:04 +0100 fs r270011 : #i100095# when no address book (or respective profile) can be found, then use a dedicated ErrorCondition 2009-03-25 10:29:07 +0100 fs r270003 : add missing localization 2009-03-25 10:23:12 +0100 fs r270001 : in preparation of #i1000095#: rework the error handling, allow using css.sdb.ErrorCondition values, plus allow propagating the nsresult 2009-03-25 10:21:55 +0100 fs r270000 : in preparation of #i1000095#: rework the error handling, allow using css.sdb.ErrorCondition values, plus allow propagating the nsresult 2009-03-20 23:05:38 +0100 fs r269829 : XMap::getSize removed 2009-03-20 23:05:19 +0100 fs r269828 : changes as suggested by sb 2009-03-20 23:04:56 +0100 fs r269827 : enhanced documentation 2009-03-20 15:31:40 +0100 fs r269815 : changes as suggested by sb 2009-03-20 13:23:52 +0100 oj r269804 : #i92538# correct the zorder that fixedtext is infront of control 2009-03-20 12:59:38 +0100 oj r269801 : #i94571# paraadjust now supports BLOCK 2009-03-20 12:58:11 +0100 oj r269800 : #i94571# export style with data style 2009-03-20 12:57:05 +0100 oj r269799 : #i94571# text align is now paraadjust 2009-03-20 12:37:02 +0100 fs r269797 : enum keys only accepted if they have the exact type, not if they have *any* enum type 2009-03-20 12:28:31 +0100 fs r269794 : some changes requested by sb 2009-03-20 08:52:47 +0100 fs r269780 : doc 2009-03-20 07:37:31 +0100 oj r269779 : #i99913# only notifiy when values are different 2009-03-20 07:36:58 +0100 oj r269778 : #i99913# add undoenv as listener at the dataprovider 2009-03-19 22:52:52 +0100 fs r269771 : added comment 2009-03-19 22:40:06 +0100 fs r269770 : +testEnumeration 2009-03-19 22:39:41 +0100 fs r269769 : implemented enumeration, getKeySet, and getValues. Should be finished now. 2009-03-19 14:01:01 +0100 oj r269743 : #i99913# reset the modified state when selecting an object 2009-03-19 12:19:54 +0100 lla r269739 : #i72390# cleanups 2009-03-19 09:25:27 +0100 fs r269727 : #i10000# 2009-03-18 23:37:02 +0100 fs r269708 : extended checks for value type acceptance 2009-03-18 23:36:41 +0100 fs r269707 : fixed value type checks 2009-03-18 14:59:56 +0100 fs r269678 : initial complex test case for the new css.container.Map implementation 2009-03-18 14:59:24 +0100 fs r269677 : verifyExpectedException moved to base class (in complexlib), and renamed to assureException for consistency 2009-03-18 14:58:35 +0100 fs r269676 : removed unused imports 2009-03-18 14:58:03 +0100 fs r269675 : first implementation of the new css.container.Map service (not completed, yet) 2009-03-18 14:57:17 +0100 fs r269674 : base class for UNO components, freeing you from some repeating work 2009-03-18 14:55:53 +0100 fs r269672 : +assureException: call a given method with given parameters on a given object, ensure that a given exception is thrown by the method implementation 2009-03-18 14:54:58 +0100 fs r269671 : +getComponentContext 2009-03-18 14:54:00 +0100 fs r269670 : isEmpty returns a boolean, not a long 2009-03-18 14:14:43 +0100 oj r269663 : #i99743# now text also supports null 2009-03-18 13:54:14 +0100 oj r269660 : #i99223# remove check for 2 params 2009-03-18 13:33:35 +0100 oj r269659 : #i99060# replace text::ParagraphVertAlign with style::VerticalAlignment 2009-03-18 13:32:18 +0100 oj r269658 : #i99060# don't set void property when void isn't allowed 2009-03-18 13:31:11 +0100 oj r269657 : #i99060# handle vertical alignment 2009-03-18 13:28:28 +0100 oj r269656 : #i99060# remove unused elements from sytle 2009-03-18 09:35:42 +0100 lla r269639 : #i72390# cleanups 2009-03-18 09:31:20 +0100 lla r269638 : #i72390# add ButtonList 2009-03-18 09:30:46 +0100 lla r269637 : #i72390# renamed interface 2009-03-18 09:30:15 +0100 lla r269636 : #i72390# use ButtonList instead of ImageList 2009-03-18 09:29:05 +0100 lla r269635 : #i72390# new ButtonList, cleanups 2009-03-18 09:26:34 +0100 lla r269634 : #i72390# cleanups 2009-03-17 12:21:20 +0100 oj r269590 : #i99222# remove assertion 2009-03-17 12:17:22 +0100 oj r269589 : #i98605# impl scale mode 2009-03-17 12:10:42 +0100 oj r269588 : #i98605# impl scale mode 2009-03-17 11:40:15 +0100 oj r269584 : #i96944# doesn't create equation for shapes 2009-03-17 11:33:16 +0100 oj r269583 : #i96423# switch calc from float to long 2009-03-16 15:19:18 +0100 fs r269550 : #i41930# enable zoom for embedded/outplace documents 2009-03-16 14:25:54 +0100 oj r269542 : #i93734# remove ContextSensitive 2009-03-16 14:21:58 +0100 oj r269541 : #i99274# page header before group header 2009-03-16 14:18:23 +0100 oj r269539 : #i99110# fix value type 2009-03-16 14:14:16 +0100 fs r269537 : line ends 2009-03-16 14:11:06 +0100 fs r269535 : line ends 2009-03-16 14:08:34 +0100 fs r269534 : #i100087# (provided my np): allow for polymorphic types with more than one parameter 2009-03-16 12:30:31 +0100 oj r269521 : compile error 2009-03-16 12:19:12 +0100 oj r269519 : compile error 2009-03-16 10:39:28 +0100 oj r269511 : compile error under linux with swap 2009-03-13 10:33:04 +0100 oj r269462 : CWS-TOOLING: rebase CWS dba32b to trunk@269297 (milestone: DEV300:m43) 2009-03-12 14:37:25 +0100 fs r269416 : interface SequenceOutputStreamTest is unneeded, and pollutes the namespace here :) 2009-03-12 14:35:07 +0100 fs r269414 : not needed 2009-03-12 14:34:15 +0100 fs r269413 : preparation for multiple tests in this module 2009-03-12 14:33:02 +0100 fs r269412 : ShowTargets was moved from module integration.forms to module complexlib 2009-03-12 14:32:48 +0100 fs r269411 : helper class for projects containing multiple complex test cases (and following a certain structure) 2009-03-12 14:00:14 +0100 fs r269407 : proper module after the move 2009-03-12 13:59:10 +0100 fs r269406 : superseded by ../makefile.mk 2009-03-12 13:47:38 +0100 fs r269403 : not needed anymore 2009-03-12 13:45:46 +0100 fs r269402 : moved, in preparation of adding more test cases here, with a common infrastructure 2009-03-12 13:45:07 +0100 fs r269401 : moved from ../ 2009-03-12 13:43:59 +0100 fs r269400 : moved to ./comphelper, in preparation of adding more test cases here, with a common infrastructure 2009-03-12 13:29:47 +0100 oj r269396 : #i99914# set parent on dataprovider 2009-03-12 13:10:35 +0100 oj r269393 : #i99832# check thrown exception and show error 2009-03-12 13:08:10 +0100 fs r269392 : reorganizing tests 2009-03-12 12:52:55 +0100 oj r269390 : #i99118# convert formatkey in numberformat 2009-03-12 12:34:53 +0100 fs r269388 : new API tests 2009-03-12 12:29:05 +0100 fs r269386 : Map not yet committed 2009-03-12 12:28:36 +0100 fs r269385 : oops, forgot the SequenceInputStream during the previous refactoring 2009-03-12 12:12:39 +0100 oj r269384 : #i99104# set HasCategories prop 2009-03-12 12:12:08 +0100 oj r269383 : #i99104# check HasCategories even for internal dataprovider 2009-03-12 12:10:40 +0100 oj r269382 : #i99104# set HasCategories prop 2009-03-12 10:51:49 +0100 fs r269373 : #i10000# exception specifications 2009-03-12 10:49:18 +0100 fs r269372 : #i10000# exception specifications 2009-03-12 10:44:02 +0100 fs r269371 : #i10000# exception specifications 2009-03-12 10:30:55 +0100 fs r269368 : refactored the UNO service registration in this module, using the helper classes provided by comphelper itself, so you have less effort when extending the list of to-be-registered components 2009-03-12 10:30:37 +0100 fs r269367 : module-local includes 2009-03-12 07:05:54 +0100 oj r269357 : #i99104# database dataprovider doesn't need dataranges and diagramdata 2009-03-11 10:58:28 +0100 oj r269306 : #i99911# check if name of the report is a valid file name 2009-03-11 10:03:23 +0100 oj r269299 : #i99666# the report is new when the HierarchicalDocumentName is empty 2009-03-10 11:32:45 +0100 oj r269258 : #i99221# use fallback for language 2009-03-10 10:48:40 +0100 oj r269255 : #i99433# now use OStringBuffer 2009-03-10 10:36:21 +0100 fs r269252 : initial version of (X)Map 2009-03-10 09:52:23 +0100 oj r269246 : #i99433# now use OStringBuffer 2009-03-10 08:56:13 +0100 oj r269240 : #i99655# patch applied 2009-03-09 07:35:33 +0100 lla r269058 : #i10000# wrong variable assignment fixed 2009-03-06 17:20:40 +0100 fs r269030 : some explicit defaults 2009-03-06 17:20:30 +0100 fs r269029 : #i98600# 2009-03-06 14:40:34 +0100 fs r269009 : #i87692# during reload, prevent the document being modified just because of some control content changes ... 2009-03-06 12:52:20 +0100 lla r268997 : #i10000# ambigous problem with FontWeight fixed 2009-03-06 11:39:32 +0100 fs r268989 : #i10000# (approved by pl): use --without-t1-library configure option 2009-03-06 10:55:43 +0100 fs r268986 : #i99953# depends on xmlscript module now 2009-03-06 10:54:04 +0100 fs r268985 : #i99953# also adjust the event names found in dialogs embedded in the forms 2009-03-06 09:53:41 +0100 fs r268977 : #i10000# 2009-03-06 09:30:41 +0100 lla r268973 : #i10000# merge problems 2009-03-05 17:52:34 +0100 fs r268932 : #i98593# for sub components which are actually controlled by a DocumentDefinition (aka XComponentSupplier aka XCommandProcessor), close them by executing the 'close' command, not by suspending/closing the controller (which cannot be intercepted) 2009-03-05 11:41:56 +0100 fs r268889 : default the drop down line count for list/combo boxes to 20 2009-03-05 11:39:10 +0100 fs r268887 : do not display empty error messages 2009-03-02 10:13:57 +0100 lla r268639 : #i91541# CWS rebase m41 to m42 2009-03-02 09:06:27 +0100 lla r268635 : #i10000# add ';' to strings 2009-02-26 11:18:00 +0100 fs r268492 : reportdesign depends on REPORTBUILDER, not REPORTDESIGN 2009-02-26 10:11:38 +0100 lla r268489 : CWS-TOOLING: rebase CWS dba32b to trunk@268395 (milestone: DEV300:m42) 2009-02-26 09:04:11 +0100 lla r268488 : CWS-TOOLING: rebase CWS dba32b to trunk@268395 (milestone: DEV300:m42) 2009-02-24 12:09:13 +0100 lla r268392 : #i91541# #i91542# cleanups 2009-02-24 08:08:06 +0100 lla r268382 : merge all dba32a changes into dba32b 2009-02-24 07:14:55 +0100 lla r268381 : merge all dba32a changes into dba32b 2009-02-23 21:44:28 +0100 fs r268377 : oops ... don't tamper with m_aListSourceValues at the end of loadData 2009-02-23 20:57:05 +0100 fs r268376 : #i98162# don't hold the values as strings, but as ORowSetValue, this way preserving their type, and being agnostic to different result/rowset implementations doing different to-string-conversations 2009-02-23 20:55:44 +0100 fs r268375 : getObject: throwFunctionNotSupportedException, instead of silently returning NULL 2009-02-23 20:55:20 +0100 fs r268374 : #i98162# some more supported types 2009-02-23 20:54:43 +0100 fs r268373 : #i98162# +operator != 2009-02-20 09:35:39 +0100 fs r268306 : #i99422# for a font, display the font name, the style, and the size 2009-02-20 09:33:45 +0100 fs r268305 : #i99422# in the property browser, FONT supersedes CHARFONTNAME: the aggregated FormComponentHandler displays them more nicely now 2009-02-19 16:12:06 +0100 fs r268293 : #i99372# recognize DataType::FLOAT as numeric 2009-02-19 15:43:12 +0100 fs r268291 : #i99415# 2009-02-19 15:40:15 +0100 fs r268290 : #i99242# lcl_firstFocussableControl: take disabled controls into account 2009-02-19 15:34:36 +0100 fs r268289 : #i99396# properly decode the base name of the URL when using it as title 2009-02-19 15:19:05 +0100 fs r268287 : #i98247#
2009-06-05 09:47:55 +00:00
// check whether the state is ambiguous. This is interesting in case we display the properties
// for multiple objects at once: In this case, we'll get a notification from one of the objects,
// but need to care for the "composed" value, which can be "ambiguous".
PropertyHandlerRef xHandler( impl_getHandlerForProperty_throw( _rEvent.PropertyName ), UNO_SET_THROW );
PropertyState ePropertyState( xHandler->getPropertyState( _rEvent.PropertyName ) );
bool bAmbiguousValue = ( PropertyState_AMBIGUOUS_VALUE == ePropertyState );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
CWS-TOOLING: integrate CWS dba32b 2009-06-03 14:58:08 +0200 fs r272581 : #i102439# 2009-05-29 13:56:18 +0200 fs r272456 : remove the sub form when the 'add subform' setting changes from <true/> to <false/>, not only its controls 2009-05-29 13:19:27 +0200 fs r272454 : display '(Default)' instead of an empty string when a control has the default font 2009-05-28 20:49:18 +0200 fs r272428 : #i98162# getFirstSelectedValue: do not return reference to a temporary 2009-05-27 15:30:22 +0200 msc r272353 : #102303# 2009-05-26 13:03:06 +0200 fs r272295 : spelling 2009-05-26 12:59:54 +0200 fs r272294 : merge m48 version to get latest cygwin related fixes 2009-05-25 14:02:06 +0200 fs r272239 : remove references to local files, needed for debugging sessions only 2009-05-25 14:01:16 +0200 fs r272238 : #i102021# ensure members such as bNumberFormat are initialized before actually returning them 2009-05-25 13:10:20 +0200 fs r272236 : #i10000# reset ENABLE_EVOAB2 2009-05-22 06:44:45 +0200 oj r272167 : #i99104# add import handler for calc-sett 2009-05-22 06:42:27 +0200 oj r272166 : #i99104# impl NullDate as member 2009-05-22 06:36:22 +0200 oj r272165 : #i99104# handle nulldate from parent model 2009-05-22 06:33:13 +0200 oj r272164 : #i99104# export and import calculation-settings and nulldate 2009-05-22 06:27:50 +0200 oj r272163 : #i99104# export and import calculation-settings and nulldate 2009-05-20 13:29:58 +0200 oj r272118 : #i99911# handle invalid name 2009-05-20 13:28:49 +0200 oj r272117 : #i101261# handle different rowsets 2009-05-20 11:29:55 +0200 msc r272111 : #i100000# 2009-05-20 11:28:27 +0200 msc r272110 : merge in change from dba32a 2009-05-20 11:27:38 +0200 msc r272109 : #102082# CTRL + C does not work 2009-05-20 09:43:36 +0200 oj r272106 : clean up includes 2009-05-20 09:32:15 +0200 oj r272105 : #i99060# merge error resovled now VERTICAL_ALIGN is in both stmt 2009-05-20 08:37:21 +0200 msc r272104 : add workaround for issue #102010# 2009-05-20 08:10:12 +0200 oj r272103 : #i99104# use numberformatkey 2009-05-20 08:07:02 +0200 oj r272102 : #i99104# use column info from rowset 2009-05-20 08:04:43 +0200 oj r272101 : #i102032# use a special column type where prec and scale are the values currently set at the column 2009-05-20 08:03:04 +0200 oj r272100 : #i102032# correct type info, we have to use SQL defined type names 2009-05-19 10:27:02 +0200 oj r272061 : #i99104# export null-date 2009-05-19 08:26:53 +0200 oj r272056 : #i99104# export null-date 2009-05-18 13:15:10 +0200 msc r272014 : add issue #102019# 2009-05-18 11:33:07 +0200 msc r272005 : add issue #102019# 2009-05-18 08:59:45 +0200 msc r271996 : add workaroud for issue #102010# 2009-05-15 10:21:24 +0200 msc r271929 : #101944# 2009-05-11 21:18:30 +0200 fs r271792 : #i99914# 2009-05-08 13:52:06 +0200 oj r271715 : #i96423# remember column span 2009-05-08 11:26:19 +0200 oj r271708 : #i98605# impl new scale mode 2009-05-08 10:33:35 +0200 fs r271706 : SendUserCall: only call into the shape notification routine for UserCall types where this is necessary (performance issue) 2009-05-07 20:52:44 +0200 fs r271698 : outsource ShapeProperty from shapepropertynotifier.hxx 2009-05-07 20:43:33 +0200 fs r271697 : #i99056# use notifyShapePropertyChange, instead of getShapePropertyChangeNotifier - the latter throws if no shape exists, yet 2009-05-07 20:33:58 +0200 fs r271696 : #i99056# +notifyShapePropertyChange: allow notifying chages without checking whether there actually already exists an SvxShape 2009-05-07 16:22:15 +0200 fs r271679 : #i10000# cygwin needs quotes around the classpath 2009-05-07 16:21:37 +0200 fs r271678 : #i10000# cygwin needs quotes around the classpath 2009-05-07 16:01:11 +0200 oj r271677 : #i99914# notify parent handler 2009-05-07 15:54:54 +0200 fs r271676 : #i10000# cygwin needs some quoting 2009-05-07 14:49:48 +0200 oj r271672 : #i99277# quote alias name 2009-05-07 14:48:12 +0200 oj r271671 : #i92538# add ~ in front of type 2009-05-07 14:37:13 +0200 oj r271667 : #i99118# change type from char to varchar 2009-05-07 14:36:23 +0200 oj r271666 : #i99118# clear dest columns when changing to create new table 2009-05-07 13:35:32 +0200 oj r271657 : #i94467# handle type 0 as double as well 2009-05-07 13:20:49 +0200 oj r271655 : i99743# setNull when varchar is no text 2009-05-07 12:58:06 +0200 fs r271651 : initialize the SdrObject's property change notifier after the ctor, if necessary 2009-05-07 11:47:18 +0200 fs r271647 : #i10000# 2009-05-07 10:57:16 +0200 fs r271639 : OPropertyBrowserController::propertyChange: care for the current property state, too, and properly forward it to the UI 2009-05-07 10:18:14 +0200 fs r271636 : onNewComponent: do not ask the map for grid columns, it will throw 2009-05-07 10:09:55 +0200 fs r271634 : #i101623# 2009-05-07 09:53:44 +0200 fs r271631 : #i101622# 2009-05-06 21:55:53 +0200 fs r271615 : #i10000# 2009-05-06 21:10:42 +0200 fs r271611 : #i10000# 2009-05-06 13:11:48 +0200 fs r271583 : #i10000# 2009-05-05 22:29:31 +0200 fs r271559 : proper assertion message 2009-05-05 22:29:03 +0200 fs r271558 : diagnostics 2009-05-05 22:16:16 +0200 fs r271557 : #i10000# 2009-05-05 13:50:32 +0200 fs r271513 : #i10000# 2009-05-05 10:21:50 +0200 fs r271503 : #i10000# 2009-05-05 09:30:26 +0200 fs r271501 : why did those survive the rebase -C step? 2009-05-05 09:18:12 +0200 fs r271500 : #i10000# 2009-05-04 17:08:17 +0200 fs r271475 : CWS-TOOLING: rebase CWS dba32b to trunk@271427 (milestone: DEV300:m47) 2009-05-04 14:51:26 +0200 fs r271456 : line ends 2009-04-30 15:55:27 +0200 fs r271418 : NewURL -> PublicConnectionURL 2009-04-22 21:18:34 +0200 fs r271141 : #i100944# 2009-04-22 09:12:26 +0200 oj r271071 : #i101261# little code change 2009-04-22 09:11:43 +0200 oj r271070 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:11:25 +0200 oj r271069 : #i101261# new grabage container for nodes 2009-04-22 09:11:02 +0200 oj r271068 : #i101261# new grabage container for nodes 2009-04-22 09:10:44 +0200 oj r271067 : #i101261# new grabage container for nodes 2009-04-22 09:10:21 +0200 oj r271066 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:08:24 +0200 oj r271065 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:07:25 +0200 oj r271064 : #i101261# only ask for parameters which aren't set before 2009-04-22 08:49:07 +0200 oj r271062 : #i77501# preview only when needed 2009-04-22 08:45:44 +0200 oj r271061 : #i101261# new prop max rows 2009-04-22 08:44:18 +0200 oj r271060 : #i101261# create dataprovider earlier to avoid the wrong legend in chart 2009-04-22 08:42:48 +0200 oj r271059 : #i101261# handle parameter 2009-04-17 21:00:23 +0200 fs r270954 : #i98350# 2009-04-17 13:54:19 +0200 fs r270942 : #i99565# 2009-04-17 13:51:34 +0200 fs r270940 : #i101153# only localize the (potentially) localizable properties when there really is support at the control model 2009-04-17 11:43:14 +0200 fs r270932 : removed superfluous include 2009-04-17 10:10:15 +0200 fs r270926 : #i10000# 2009-04-17 10:02:36 +0200 fs r270925 : #i10000# 2009-04-17 09:15:13 +0200 fs r270918 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 09:14:56 +0200 fs r270917 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 09:13:25 +0200 fs r270915 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 08:30:34 +0200 fs r270914 : removed unotools/servicehelper.hxx in favour of the (duplicated) comphelper/servicehelper.hxx 2009-04-16 21:05:25 +0200 fs r270903 : #i10000# 2009-04-16 20:43:43 +0200 fs r270902 : #i99056# shape notification outsourced to the SdrObject, this is what all other shape implementations (which only aggregate an SvxShape) have access to, too 2009-04-16 15:57:36 +0200 fs r270891 : #i99056# make SetUnoControlModel virtual 2009-04-16 15:44:02 +0200 fs r270890 : #i99056# let the ScShapeObj notify changes in its Anchor property 2009-04-16 15:36:47 +0200 fs r270889 : #i99056# enable the sheet anchor type property, too 2009-04-16 15:33:45 +0200 fs r270887 : #i99056# shape notification outsourced to the SdrObject, this is what all other shape implementations (which only aggregate an SvxShape) have access to, too 2009-04-15 14:53:13 +0200 fs r270844 : #i10000# 2009-04-15 13:08:29 +0200 fs r270836 : #i10000# 2009-04-15 12:28:14 +0200 fs r270832 : #i10000# 2009-04-15 10:59:14 +0200 fs r270827 : #i10000# 2009-04-15 09:41:08 +0200 oj r270823 : fix issues found with findbugs and pmd 2009-04-14 21:08:04 +0200 fs r270808 : #i99056# implement SheetAnchorType - now the only thing missing to enable it is the proper notification when it is modified 2009-04-14 17:09:00 +0200 fs r270799 : #i99056# implement XServiceInfo for the ScShapeObj 2009-04-14 17:07:55 +0200 fs r270798 : #i99056# implement TextAnchorType, partially implement SheetAnchorType 2009-04-14 15:54:05 +0200 fs r270786 : #i99056# SwXShape: notify changes of the AnchorType property 2009-04-14 15:47:32 +0200 fs r270785 : #i99056# deliver shapepropertynotifier.hxx 2009-04-14 15:46:54 +0200 fs r270784 : diagnostics 2009-04-14 15:08:28 +0200 fs r270781 : #i99056# outsourced the SvxShape's property change notification code into a dedicated class 2009-04-14 14:41:09 +0200 fs r270773 : #i99056# outsourced the SvxShape's property change notification code into a dedicated class 2009-04-14 14:37:23 +0200 fs r270772 : in dtor, remove the properties from the temporary component context 2009-04-14 14:36:34 +0200 fs r270771 : getWeakUnoShape made const 2009-04-14 12:23:08 +0200 oj r270757 : #i101064# add missing braces 2009-04-14 12:21:25 +0200 oj r270756 : #i101065# add braces for gcc 4.3.2 2009-04-14 12:17:45 +0200 oj r270755 : #i101059# add dep for manifest 2009-04-09 12:06:58 +0200 oj r270686 : #i93100# use OptimalSize from control to get height 2009-04-08 09:56:55 +0200 oj r270619 : #i92537# handle calculations in the select columns as well 2009-04-08 09:30:39 +0200 oj r270615 : #i96657# throw error message when the key doesn't have any columns 2009-04-07 12:08:26 +0200 oj r270592 : #i77501# impl preview of the executed report 2009-04-07 12:01:56 +0200 oj r270591 : #i77501# impl preview of the executed report 2009-04-07 11:41:03 +0200 oj r270590 : #i77501# impl preview of the executed report 2009-04-07 11:39:32 +0200 oj r270589 : #i77501# impl preview of the executed report 2009-04-07 11:29:25 +0200 oj r270588 : #i77501# convert dos to unix lineends 2009-04-07 11:28:23 +0200 oj r270587 : #i77501# impl preview of the executed report 2009-04-07 11:16:50 +0200 oj r270586 : #i77501# impl preview of the executed report 2009-04-07 11:16:00 +0200 oj r270585 : #i77501# impl preview of the executed report 2009-04-07 11:15:44 +0200 oj r270584 : #i77501# impl preview of the executed report 2009-04-07 11:15:28 +0200 oj r270583 : #i77501# impl preview of the executed report 2009-04-07 11:15:04 +0200 oj r270582 : #i77501# impl preview of the executed report 2009-04-06 15:38:54 +0200 fs r270559 : merge changes from CWS dba32a herein 2009-04-03 15:56:16 +0200 fs r270494 : ImpSvMEdit::Resize: do multiple iterations, if necessary 2009-04-03 14:35:49 +0200 fs r270487 : #i10000# 2009-04-03 13:17:16 +0200 fs r270476 : #i99056# display geometry information for controls, too 2009-04-03 13:16:37 +0200 fs r270475 : #i99056# better ordering of the geometry properties 2009-04-03 13:16:07 +0200 fs r270473 : #i99056# now that SvxShape supports property change listeners, forward add/remove requests to it 2009-04-03 13:13:18 +0200 fs r270472 : #i99056# at SvxShape, allow for PropertyChangeListeners for Size/Position 2009-04-03 09:29:27 +0200 oj r270456 : #i94571# use correct prop name 2009-04-03 09:14:54 +0200 fs r270451 : merge changes from CWS dba32a herein 2009-04-02 17:00:51 +0200 fs r270424 : better diagnostics 2009-04-02 16:35:19 +0200 fs r270421 : diagnostics 2009-04-02 16:34:50 +0200 fs r270420 : #i99056# mxUnoShape not accessible anymore, use impl_setUnoShape instead 2009-04-02 16:32:48 +0200 fs r270419 : #i99056# make getUnoShape cheaper: keep the pointer to the SvxShape all the time, so there's no need to ask for it in getUnoShape. As a consequence, we will later be able to use the pointer in scenarious where performance (potentially) matters 2009-04-02 16:31:13 +0200 fs r270417 : merge changes from CWS dba32a herein 2009-04-02 16:23:16 +0200 fs r270414 : merge changes from CWS dba32a herein 2009-04-02 14:10:35 +0200 fs r270405 : #i10000# 2009-04-02 14:06:26 +0200 fs r270404 : merge changes from CWS dba32a herein 2009-04-02 14:03:03 +0200 fs r270401 : #i10000# 2009-04-02 13:58:13 +0200 fs r270400 : #i10000# 2009-04-02 12:59:44 +0200 fs r270397 : merge changes from CWS dba32a herein 2009-04-02 12:46:30 +0200 fs r270396 : #i99056# let the form page maintain a mapping between control models and control shapes 2009-04-02 12:44:07 +0200 fs r270395 : merge changes from CWS dba32a herein 2009-04-02 12:42:06 +0200 fs r270394 : merge changes from CWS dba32a herein 2009-04-02 12:35:20 +0200 fs r270393 : #i10000# precompiled header 2009-04-02 12:05:31 +0200 fs r270392 : merge changes from CWS dba32a herein 2009-04-02 12:00:42 +0200 fs r270391 : merge changes from CWS dba32a herein 2009-04-02 11:47:26 +0200 fs r270390 : merge changes from CWS dba32a herein 2009-04-02 11:39:15 +0200 oj r270389 : #i94467# foxpro impl several new types 2009-04-02 11:35:58 +0200 fs r270387 : merge changes from CWS dba32a herein 2009-04-01 14:10:51 +0200 fs r270329 : merge changes from CWS dba32a herein 2009-03-31 17:29:50 +0200 fs r270290 : merge changes from CWS dba32a herein 2009-03-30 14:53:56 +0200 fs r270233 : #i100417# don't set grid column widths to 0, but to <void/> 2009-03-30 12:31:03 +0200 oj r270213 : #i100552# wrong orb used 2009-03-30 12:19:20 +0200 oj r270212 : #i98303# convertlike corrected to sal_Unicode 2009-03-30 11:58:25 +0200 fs r270210 : merge changes from CWS dba32a herein 2009-03-30 11:38:16 +0200 oj r270205 : remove duplicate code from merge 2009-03-30 11:02:27 +0200 fs r270202 : merge changes from CWS dba32a herein 2009-03-30 11:02:19 +0200 fs r270201 : merge changes from CWS dba32a herein 2009-03-30 10:31:26 +0200 oj r270200 : #i100665# only throw exception and do not drop table 2009-03-30 09:36:24 +0200 fs r270195 : assertion text 2009-03-28 20:21:58 +0100 fs r270187 : #ii10000# 2009-03-28 20:19:54 +0100 fs r270186 : removed unused help ids 2009-03-28 20:19:40 +0100 fs r270185 : removed unused help ids 2009-03-28 20:19:10 +0100 fs r270184 : #i100237# +DefaultState/XReset 2009-03-28 00:29:29 +0100 fs r270177 : CWS-TOOLING: rebase CWS dba32b to trunk@270033 (milestone: DEV300:m45) 2009-03-27 22:56:46 +0100 fs r270173 : #i100237# DEFAULT_CHECKED -> DEFAULT_STATE 2009-03-27 22:55:52 +0100 fs r270172 : #i100237# DefaultState property for buttons, enabled only when Toggle=Yes 2009-03-27 22:54:15 +0100 fs r270171 : #i100237# DEFAULT_CHECKED -> DEFAULT_STATE 2009-03-27 22:53:54 +0100 fs r270170 : #i100237# introduce a DefaultState property for buttons, which implies buttongs supporting XReset, which needed some refactoring 2009-03-27 13:31:41 +0100 fs r270152 : ignore output paths 2009-03-27 11:23:44 +0100 fs r270139 : tuned behavior with respect to invalid keys/values 2009-03-27 09:57:14 +0100 fs r270136 : don't allow Double.NaN 2009-03-27 09:56:16 +0100 fs r270135 : talk about Double.NaN 2009-03-26 12:14:30 +0100 fs r270067 : removed unused parameter 2009-03-26 12:14:02 +0100 fs r270066 : removed widening conversion when checking keys 2009-03-26 09:17:34 +0100 fs r270053 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-26 09:17:11 +0100 fs r270052 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-26 09:16:49 +0100 fs r270051 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-25 21:55:20 +0100 fs r270044 : #i100541# properly calculat bNeedScrollBox 2009-03-25 12:56:17 +0100 fs r270019 : renamed the previously introduced error condition 2009-03-25 12:11:48 +0100 fs r270015 : #i100095# when the error messages contain non-trivial details (SQLState/ErrorCode), then always display the 'Details' button 2009-03-25 12:10:05 +0100 fs r270012 : renamed the previously introduced error condition 2009-03-25 12:01:04 +0100 fs r270011 : #i100095# when no address book (or respective profile) can be found, then use a dedicated ErrorCondition 2009-03-25 10:29:07 +0100 fs r270003 : add missing localization 2009-03-25 10:23:12 +0100 fs r270001 : in preparation of #i1000095#: rework the error handling, allow using css.sdb.ErrorCondition values, plus allow propagating the nsresult 2009-03-25 10:21:55 +0100 fs r270000 : in preparation of #i1000095#: rework the error handling, allow using css.sdb.ErrorCondition values, plus allow propagating the nsresult 2009-03-20 23:05:38 +0100 fs r269829 : XMap::getSize removed 2009-03-20 23:05:19 +0100 fs r269828 : changes as suggested by sb 2009-03-20 23:04:56 +0100 fs r269827 : enhanced documentation 2009-03-20 15:31:40 +0100 fs r269815 : changes as suggested by sb 2009-03-20 13:23:52 +0100 oj r269804 : #i92538# correct the zorder that fixedtext is infront of control 2009-03-20 12:59:38 +0100 oj r269801 : #i94571# paraadjust now supports BLOCK 2009-03-20 12:58:11 +0100 oj r269800 : #i94571# export style with data style 2009-03-20 12:57:05 +0100 oj r269799 : #i94571# text align is now paraadjust 2009-03-20 12:37:02 +0100 fs r269797 : enum keys only accepted if they have the exact type, not if they have *any* enum type 2009-03-20 12:28:31 +0100 fs r269794 : some changes requested by sb 2009-03-20 08:52:47 +0100 fs r269780 : doc 2009-03-20 07:37:31 +0100 oj r269779 : #i99913# only notifiy when values are different 2009-03-20 07:36:58 +0100 oj r269778 : #i99913# add undoenv as listener at the dataprovider 2009-03-19 22:52:52 +0100 fs r269771 : added comment 2009-03-19 22:40:06 +0100 fs r269770 : +testEnumeration 2009-03-19 22:39:41 +0100 fs r269769 : implemented enumeration, getKeySet, and getValues. Should be finished now. 2009-03-19 14:01:01 +0100 oj r269743 : #i99913# reset the modified state when selecting an object 2009-03-19 12:19:54 +0100 lla r269739 : #i72390# cleanups 2009-03-19 09:25:27 +0100 fs r269727 : #i10000# 2009-03-18 23:37:02 +0100 fs r269708 : extended checks for value type acceptance 2009-03-18 23:36:41 +0100 fs r269707 : fixed value type checks 2009-03-18 14:59:56 +0100 fs r269678 : initial complex test case for the new css.container.Map implementation 2009-03-18 14:59:24 +0100 fs r269677 : verifyExpectedException moved to base class (in complexlib), and renamed to assureException for consistency 2009-03-18 14:58:35 +0100 fs r269676 : removed unused imports 2009-03-18 14:58:03 +0100 fs r269675 : first implementation of the new css.container.Map service (not completed, yet) 2009-03-18 14:57:17 +0100 fs r269674 : base class for UNO components, freeing you from some repeating work 2009-03-18 14:55:53 +0100 fs r269672 : +assureException: call a given method with given parameters on a given object, ensure that a given exception is thrown by the method implementation 2009-03-18 14:54:58 +0100 fs r269671 : +getComponentContext 2009-03-18 14:54:00 +0100 fs r269670 : isEmpty returns a boolean, not a long 2009-03-18 14:14:43 +0100 oj r269663 : #i99743# now text also supports null 2009-03-18 13:54:14 +0100 oj r269660 : #i99223# remove check for 2 params 2009-03-18 13:33:35 +0100 oj r269659 : #i99060# replace text::ParagraphVertAlign with style::VerticalAlignment 2009-03-18 13:32:18 +0100 oj r269658 : #i99060# don't set void property when void isn't allowed 2009-03-18 13:31:11 +0100 oj r269657 : #i99060# handle vertical alignment 2009-03-18 13:28:28 +0100 oj r269656 : #i99060# remove unused elements from sytle 2009-03-18 09:35:42 +0100 lla r269639 : #i72390# cleanups 2009-03-18 09:31:20 +0100 lla r269638 : #i72390# add ButtonList 2009-03-18 09:30:46 +0100 lla r269637 : #i72390# renamed interface 2009-03-18 09:30:15 +0100 lla r269636 : #i72390# use ButtonList instead of ImageList 2009-03-18 09:29:05 +0100 lla r269635 : #i72390# new ButtonList, cleanups 2009-03-18 09:26:34 +0100 lla r269634 : #i72390# cleanups 2009-03-17 12:21:20 +0100 oj r269590 : #i99222# remove assertion 2009-03-17 12:17:22 +0100 oj r269589 : #i98605# impl scale mode 2009-03-17 12:10:42 +0100 oj r269588 : #i98605# impl scale mode 2009-03-17 11:40:15 +0100 oj r269584 : #i96944# doesn't create equation for shapes 2009-03-17 11:33:16 +0100 oj r269583 : #i96423# switch calc from float to long 2009-03-16 15:19:18 +0100 fs r269550 : #i41930# enable zoom for embedded/outplace documents 2009-03-16 14:25:54 +0100 oj r269542 : #i93734# remove ContextSensitive 2009-03-16 14:21:58 +0100 oj r269541 : #i99274# page header before group header 2009-03-16 14:18:23 +0100 oj r269539 : #i99110# fix value type 2009-03-16 14:14:16 +0100 fs r269537 : line ends 2009-03-16 14:11:06 +0100 fs r269535 : line ends 2009-03-16 14:08:34 +0100 fs r269534 : #i100087# (provided my np): allow for polymorphic types with more than one parameter 2009-03-16 12:30:31 +0100 oj r269521 : compile error 2009-03-16 12:19:12 +0100 oj r269519 : compile error 2009-03-16 10:39:28 +0100 oj r269511 : compile error under linux with swap 2009-03-13 10:33:04 +0100 oj r269462 : CWS-TOOLING: rebase CWS dba32b to trunk@269297 (milestone: DEV300:m43) 2009-03-12 14:37:25 +0100 fs r269416 : interface SequenceOutputStreamTest is unneeded, and pollutes the namespace here :) 2009-03-12 14:35:07 +0100 fs r269414 : not needed 2009-03-12 14:34:15 +0100 fs r269413 : preparation for multiple tests in this module 2009-03-12 14:33:02 +0100 fs r269412 : ShowTargets was moved from module integration.forms to module complexlib 2009-03-12 14:32:48 +0100 fs r269411 : helper class for projects containing multiple complex test cases (and following a certain structure) 2009-03-12 14:00:14 +0100 fs r269407 : proper module after the move 2009-03-12 13:59:10 +0100 fs r269406 : superseded by ../makefile.mk 2009-03-12 13:47:38 +0100 fs r269403 : not needed anymore 2009-03-12 13:45:46 +0100 fs r269402 : moved, in preparation of adding more test cases here, with a common infrastructure 2009-03-12 13:45:07 +0100 fs r269401 : moved from ../ 2009-03-12 13:43:59 +0100 fs r269400 : moved to ./comphelper, in preparation of adding more test cases here, with a common infrastructure 2009-03-12 13:29:47 +0100 oj r269396 : #i99914# set parent on dataprovider 2009-03-12 13:10:35 +0100 oj r269393 : #i99832# check thrown exception and show error 2009-03-12 13:08:10 +0100 fs r269392 : reorganizing tests 2009-03-12 12:52:55 +0100 oj r269390 : #i99118# convert formatkey in numberformat 2009-03-12 12:34:53 +0100 fs r269388 : new API tests 2009-03-12 12:29:05 +0100 fs r269386 : Map not yet committed 2009-03-12 12:28:36 +0100 fs r269385 : oops, forgot the SequenceInputStream during the previous refactoring 2009-03-12 12:12:39 +0100 oj r269384 : #i99104# set HasCategories prop 2009-03-12 12:12:08 +0100 oj r269383 : #i99104# check HasCategories even for internal dataprovider 2009-03-12 12:10:40 +0100 oj r269382 : #i99104# set HasCategories prop 2009-03-12 10:51:49 +0100 fs r269373 : #i10000# exception specifications 2009-03-12 10:49:18 +0100 fs r269372 : #i10000# exception specifications 2009-03-12 10:44:02 +0100 fs r269371 : #i10000# exception specifications 2009-03-12 10:30:55 +0100 fs r269368 : refactored the UNO service registration in this module, using the helper classes provided by comphelper itself, so you have less effort when extending the list of to-be-registered components 2009-03-12 10:30:37 +0100 fs r269367 : module-local includes 2009-03-12 07:05:54 +0100 oj r269357 : #i99104# database dataprovider doesn't need dataranges and diagramdata 2009-03-11 10:58:28 +0100 oj r269306 : #i99911# check if name of the report is a valid file name 2009-03-11 10:03:23 +0100 oj r269299 : #i99666# the report is new when the HierarchicalDocumentName is empty 2009-03-10 11:32:45 +0100 oj r269258 : #i99221# use fallback for language 2009-03-10 10:48:40 +0100 oj r269255 : #i99433# now use OStringBuffer 2009-03-10 10:36:21 +0100 fs r269252 : initial version of (X)Map 2009-03-10 09:52:23 +0100 oj r269246 : #i99433# now use OStringBuffer 2009-03-10 08:56:13 +0100 oj r269240 : #i99655# patch applied 2009-03-09 07:35:33 +0100 lla r269058 : #i10000# wrong variable assignment fixed 2009-03-06 17:20:40 +0100 fs r269030 : some explicit defaults 2009-03-06 17:20:30 +0100 fs r269029 : #i98600# 2009-03-06 14:40:34 +0100 fs r269009 : #i87692# during reload, prevent the document being modified just because of some control content changes ... 2009-03-06 12:52:20 +0100 lla r268997 : #i10000# ambigous problem with FontWeight fixed 2009-03-06 11:39:32 +0100 fs r268989 : #i10000# (approved by pl): use --without-t1-library configure option 2009-03-06 10:55:43 +0100 fs r268986 : #i99953# depends on xmlscript module now 2009-03-06 10:54:04 +0100 fs r268985 : #i99953# also adjust the event names found in dialogs embedded in the forms 2009-03-06 09:53:41 +0100 fs r268977 : #i10000# 2009-03-06 09:30:41 +0100 lla r268973 : #i10000# merge problems 2009-03-05 17:52:34 +0100 fs r268932 : #i98593# for sub components which are actually controlled by a DocumentDefinition (aka XComponentSupplier aka XCommandProcessor), close them by executing the 'close' command, not by suspending/closing the controller (which cannot be intercepted) 2009-03-05 11:41:56 +0100 fs r268889 : default the drop down line count for list/combo boxes to 20 2009-03-05 11:39:10 +0100 fs r268887 : do not display empty error messages 2009-03-02 10:13:57 +0100 lla r268639 : #i91541# CWS rebase m41 to m42 2009-03-02 09:06:27 +0100 lla r268635 : #i10000# add ';' to strings 2009-02-26 11:18:00 +0100 fs r268492 : reportdesign depends on REPORTBUILDER, not REPORTDESIGN 2009-02-26 10:11:38 +0100 lla r268489 : CWS-TOOLING: rebase CWS dba32b to trunk@268395 (milestone: DEV300:m42) 2009-02-26 09:04:11 +0100 lla r268488 : CWS-TOOLING: rebase CWS dba32b to trunk@268395 (milestone: DEV300:m42) 2009-02-24 12:09:13 +0100 lla r268392 : #i91541# #i91542# cleanups 2009-02-24 08:08:06 +0100 lla r268382 : merge all dba32a changes into dba32b 2009-02-24 07:14:55 +0100 lla r268381 : merge all dba32a changes into dba32b 2009-02-23 21:44:28 +0100 fs r268377 : oops ... don't tamper with m_aListSourceValues at the end of loadData 2009-02-23 20:57:05 +0100 fs r268376 : #i98162# don't hold the values as strings, but as ORowSetValue, this way preserving their type, and being agnostic to different result/rowset implementations doing different to-string-conversations 2009-02-23 20:55:44 +0100 fs r268375 : getObject: throwFunctionNotSupportedException, instead of silently returning NULL 2009-02-23 20:55:20 +0100 fs r268374 : #i98162# some more supported types 2009-02-23 20:54:43 +0100 fs r268373 : #i98162# +operator != 2009-02-20 09:35:39 +0100 fs r268306 : #i99422# for a font, display the font name, the style, and the size 2009-02-20 09:33:45 +0100 fs r268305 : #i99422# in the property browser, FONT supersedes CHARFONTNAME: the aggregated FormComponentHandler displays them more nicely now 2009-02-19 16:12:06 +0100 fs r268293 : #i99372# recognize DataType::FLOAT as numeric 2009-02-19 15:43:12 +0100 fs r268291 : #i99415# 2009-02-19 15:40:15 +0100 fs r268290 : #i99242# lcl_firstFocussableControl: take disabled controls into account 2009-02-19 15:34:36 +0100 fs r268289 : #i99396# properly decode the base name of the URL when using it as title 2009-02-19 15:19:05 +0100 fs r268287 : #i98247#
2009-06-05 09:47:55 +00:00
getPropertyBox().SetPropertyValue( _rEvent.PropertyName, aNewValue, bAmbiguousValue );
}
CWS-TOOLING: integrate CWS dba32b 2009-06-03 14:58:08 +0200 fs r272581 : #i102439# 2009-05-29 13:56:18 +0200 fs r272456 : remove the sub form when the 'add subform' setting changes from <true/> to <false/>, not only its controls 2009-05-29 13:19:27 +0200 fs r272454 : display '(Default)' instead of an empty string when a control has the default font 2009-05-28 20:49:18 +0200 fs r272428 : #i98162# getFirstSelectedValue: do not return reference to a temporary 2009-05-27 15:30:22 +0200 msc r272353 : #102303# 2009-05-26 13:03:06 +0200 fs r272295 : spelling 2009-05-26 12:59:54 +0200 fs r272294 : merge m48 version to get latest cygwin related fixes 2009-05-25 14:02:06 +0200 fs r272239 : remove references to local files, needed for debugging sessions only 2009-05-25 14:01:16 +0200 fs r272238 : #i102021# ensure members such as bNumberFormat are initialized before actually returning them 2009-05-25 13:10:20 +0200 fs r272236 : #i10000# reset ENABLE_EVOAB2 2009-05-22 06:44:45 +0200 oj r272167 : #i99104# add import handler for calc-sett 2009-05-22 06:42:27 +0200 oj r272166 : #i99104# impl NullDate as member 2009-05-22 06:36:22 +0200 oj r272165 : #i99104# handle nulldate from parent model 2009-05-22 06:33:13 +0200 oj r272164 : #i99104# export and import calculation-settings and nulldate 2009-05-22 06:27:50 +0200 oj r272163 : #i99104# export and import calculation-settings and nulldate 2009-05-20 13:29:58 +0200 oj r272118 : #i99911# handle invalid name 2009-05-20 13:28:49 +0200 oj r272117 : #i101261# handle different rowsets 2009-05-20 11:29:55 +0200 msc r272111 : #i100000# 2009-05-20 11:28:27 +0200 msc r272110 : merge in change from dba32a 2009-05-20 11:27:38 +0200 msc r272109 : #102082# CTRL + C does not work 2009-05-20 09:43:36 +0200 oj r272106 : clean up includes 2009-05-20 09:32:15 +0200 oj r272105 : #i99060# merge error resovled now VERTICAL_ALIGN is in both stmt 2009-05-20 08:37:21 +0200 msc r272104 : add workaround for issue #102010# 2009-05-20 08:10:12 +0200 oj r272103 : #i99104# use numberformatkey 2009-05-20 08:07:02 +0200 oj r272102 : #i99104# use column info from rowset 2009-05-20 08:04:43 +0200 oj r272101 : #i102032# use a special column type where prec and scale are the values currently set at the column 2009-05-20 08:03:04 +0200 oj r272100 : #i102032# correct type info, we have to use SQL defined type names 2009-05-19 10:27:02 +0200 oj r272061 : #i99104# export null-date 2009-05-19 08:26:53 +0200 oj r272056 : #i99104# export null-date 2009-05-18 13:15:10 +0200 msc r272014 : add issue #102019# 2009-05-18 11:33:07 +0200 msc r272005 : add issue #102019# 2009-05-18 08:59:45 +0200 msc r271996 : add workaroud for issue #102010# 2009-05-15 10:21:24 +0200 msc r271929 : #101944# 2009-05-11 21:18:30 +0200 fs r271792 : #i99914# 2009-05-08 13:52:06 +0200 oj r271715 : #i96423# remember column span 2009-05-08 11:26:19 +0200 oj r271708 : #i98605# impl new scale mode 2009-05-08 10:33:35 +0200 fs r271706 : SendUserCall: only call into the shape notification routine for UserCall types where this is necessary (performance issue) 2009-05-07 20:52:44 +0200 fs r271698 : outsource ShapeProperty from shapepropertynotifier.hxx 2009-05-07 20:43:33 +0200 fs r271697 : #i99056# use notifyShapePropertyChange, instead of getShapePropertyChangeNotifier - the latter throws if no shape exists, yet 2009-05-07 20:33:58 +0200 fs r271696 : #i99056# +notifyShapePropertyChange: allow notifying chages without checking whether there actually already exists an SvxShape 2009-05-07 16:22:15 +0200 fs r271679 : #i10000# cygwin needs quotes around the classpath 2009-05-07 16:21:37 +0200 fs r271678 : #i10000# cygwin needs quotes around the classpath 2009-05-07 16:01:11 +0200 oj r271677 : #i99914# notify parent handler 2009-05-07 15:54:54 +0200 fs r271676 : #i10000# cygwin needs some quoting 2009-05-07 14:49:48 +0200 oj r271672 : #i99277# quote alias name 2009-05-07 14:48:12 +0200 oj r271671 : #i92538# add ~ in front of type 2009-05-07 14:37:13 +0200 oj r271667 : #i99118# change type from char to varchar 2009-05-07 14:36:23 +0200 oj r271666 : #i99118# clear dest columns when changing to create new table 2009-05-07 13:35:32 +0200 oj r271657 : #i94467# handle type 0 as double as well 2009-05-07 13:20:49 +0200 oj r271655 : i99743# setNull when varchar is no text 2009-05-07 12:58:06 +0200 fs r271651 : initialize the SdrObject's property change notifier after the ctor, if necessary 2009-05-07 11:47:18 +0200 fs r271647 : #i10000# 2009-05-07 10:57:16 +0200 fs r271639 : OPropertyBrowserController::propertyChange: care for the current property state, too, and properly forward it to the UI 2009-05-07 10:18:14 +0200 fs r271636 : onNewComponent: do not ask the map for grid columns, it will throw 2009-05-07 10:09:55 +0200 fs r271634 : #i101623# 2009-05-07 09:53:44 +0200 fs r271631 : #i101622# 2009-05-06 21:55:53 +0200 fs r271615 : #i10000# 2009-05-06 21:10:42 +0200 fs r271611 : #i10000# 2009-05-06 13:11:48 +0200 fs r271583 : #i10000# 2009-05-05 22:29:31 +0200 fs r271559 : proper assertion message 2009-05-05 22:29:03 +0200 fs r271558 : diagnostics 2009-05-05 22:16:16 +0200 fs r271557 : #i10000# 2009-05-05 13:50:32 +0200 fs r271513 : #i10000# 2009-05-05 10:21:50 +0200 fs r271503 : #i10000# 2009-05-05 09:30:26 +0200 fs r271501 : why did those survive the rebase -C step? 2009-05-05 09:18:12 +0200 fs r271500 : #i10000# 2009-05-04 17:08:17 +0200 fs r271475 : CWS-TOOLING: rebase CWS dba32b to trunk@271427 (milestone: DEV300:m47) 2009-05-04 14:51:26 +0200 fs r271456 : line ends 2009-04-30 15:55:27 +0200 fs r271418 : NewURL -> PublicConnectionURL 2009-04-22 21:18:34 +0200 fs r271141 : #i100944# 2009-04-22 09:12:26 +0200 oj r271071 : #i101261# little code change 2009-04-22 09:11:43 +0200 oj r271070 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:11:25 +0200 oj r271069 : #i101261# new grabage container for nodes 2009-04-22 09:11:02 +0200 oj r271068 : #i101261# new grabage container for nodes 2009-04-22 09:10:44 +0200 oj r271067 : #i101261# new grabage container for nodes 2009-04-22 09:10:21 +0200 oj r271066 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:08:24 +0200 oj r271065 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:07:25 +0200 oj r271064 : #i101261# only ask for parameters which aren't set before 2009-04-22 08:49:07 +0200 oj r271062 : #i77501# preview only when needed 2009-04-22 08:45:44 +0200 oj r271061 : #i101261# new prop max rows 2009-04-22 08:44:18 +0200 oj r271060 : #i101261# create dataprovider earlier to avoid the wrong legend in chart 2009-04-22 08:42:48 +0200 oj r271059 : #i101261# handle parameter 2009-04-17 21:00:23 +0200 fs r270954 : #i98350# 2009-04-17 13:54:19 +0200 fs r270942 : #i99565# 2009-04-17 13:51:34 +0200 fs r270940 : #i101153# only localize the (potentially) localizable properties when there really is support at the control model 2009-04-17 11:43:14 +0200 fs r270932 : removed superfluous include 2009-04-17 10:10:15 +0200 fs r270926 : #i10000# 2009-04-17 10:02:36 +0200 fs r270925 : #i10000# 2009-04-17 09:15:13 +0200 fs r270918 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 09:14:56 +0200 fs r270917 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 09:13:25 +0200 fs r270915 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 08:30:34 +0200 fs r270914 : removed unotools/servicehelper.hxx in favour of the (duplicated) comphelper/servicehelper.hxx 2009-04-16 21:05:25 +0200 fs r270903 : #i10000# 2009-04-16 20:43:43 +0200 fs r270902 : #i99056# shape notification outsourced to the SdrObject, this is what all other shape implementations (which only aggregate an SvxShape) have access to, too 2009-04-16 15:57:36 +0200 fs r270891 : #i99056# make SetUnoControlModel virtual 2009-04-16 15:44:02 +0200 fs r270890 : #i99056# let the ScShapeObj notify changes in its Anchor property 2009-04-16 15:36:47 +0200 fs r270889 : #i99056# enable the sheet anchor type property, too 2009-04-16 15:33:45 +0200 fs r270887 : #i99056# shape notification outsourced to the SdrObject, this is what all other shape implementations (which only aggregate an SvxShape) have access to, too 2009-04-15 14:53:13 +0200 fs r270844 : #i10000# 2009-04-15 13:08:29 +0200 fs r270836 : #i10000# 2009-04-15 12:28:14 +0200 fs r270832 : #i10000# 2009-04-15 10:59:14 +0200 fs r270827 : #i10000# 2009-04-15 09:41:08 +0200 oj r270823 : fix issues found with findbugs and pmd 2009-04-14 21:08:04 +0200 fs r270808 : #i99056# implement SheetAnchorType - now the only thing missing to enable it is the proper notification when it is modified 2009-04-14 17:09:00 +0200 fs r270799 : #i99056# implement XServiceInfo for the ScShapeObj 2009-04-14 17:07:55 +0200 fs r270798 : #i99056# implement TextAnchorType, partially implement SheetAnchorType 2009-04-14 15:54:05 +0200 fs r270786 : #i99056# SwXShape: notify changes of the AnchorType property 2009-04-14 15:47:32 +0200 fs r270785 : #i99056# deliver shapepropertynotifier.hxx 2009-04-14 15:46:54 +0200 fs r270784 : diagnostics 2009-04-14 15:08:28 +0200 fs r270781 : #i99056# outsourced the SvxShape's property change notification code into a dedicated class 2009-04-14 14:41:09 +0200 fs r270773 : #i99056# outsourced the SvxShape's property change notification code into a dedicated class 2009-04-14 14:37:23 +0200 fs r270772 : in dtor, remove the properties from the temporary component context 2009-04-14 14:36:34 +0200 fs r270771 : getWeakUnoShape made const 2009-04-14 12:23:08 +0200 oj r270757 : #i101064# add missing braces 2009-04-14 12:21:25 +0200 oj r270756 : #i101065# add braces for gcc 4.3.2 2009-04-14 12:17:45 +0200 oj r270755 : #i101059# add dep for manifest 2009-04-09 12:06:58 +0200 oj r270686 : #i93100# use OptimalSize from control to get height 2009-04-08 09:56:55 +0200 oj r270619 : #i92537# handle calculations in the select columns as well 2009-04-08 09:30:39 +0200 oj r270615 : #i96657# throw error message when the key doesn't have any columns 2009-04-07 12:08:26 +0200 oj r270592 : #i77501# impl preview of the executed report 2009-04-07 12:01:56 +0200 oj r270591 : #i77501# impl preview of the executed report 2009-04-07 11:41:03 +0200 oj r270590 : #i77501# impl preview of the executed report 2009-04-07 11:39:32 +0200 oj r270589 : #i77501# impl preview of the executed report 2009-04-07 11:29:25 +0200 oj r270588 : #i77501# convert dos to unix lineends 2009-04-07 11:28:23 +0200 oj r270587 : #i77501# impl preview of the executed report 2009-04-07 11:16:50 +0200 oj r270586 : #i77501# impl preview of the executed report 2009-04-07 11:16:00 +0200 oj r270585 : #i77501# impl preview of the executed report 2009-04-07 11:15:44 +0200 oj r270584 : #i77501# impl preview of the executed report 2009-04-07 11:15:28 +0200 oj r270583 : #i77501# impl preview of the executed report 2009-04-07 11:15:04 +0200 oj r270582 : #i77501# impl preview of the executed report 2009-04-06 15:38:54 +0200 fs r270559 : merge changes from CWS dba32a herein 2009-04-03 15:56:16 +0200 fs r270494 : ImpSvMEdit::Resize: do multiple iterations, if necessary 2009-04-03 14:35:49 +0200 fs r270487 : #i10000# 2009-04-03 13:17:16 +0200 fs r270476 : #i99056# display geometry information for controls, too 2009-04-03 13:16:37 +0200 fs r270475 : #i99056# better ordering of the geometry properties 2009-04-03 13:16:07 +0200 fs r270473 : #i99056# now that SvxShape supports property change listeners, forward add/remove requests to it 2009-04-03 13:13:18 +0200 fs r270472 : #i99056# at SvxShape, allow for PropertyChangeListeners for Size/Position 2009-04-03 09:29:27 +0200 oj r270456 : #i94571# use correct prop name 2009-04-03 09:14:54 +0200 fs r270451 : merge changes from CWS dba32a herein 2009-04-02 17:00:51 +0200 fs r270424 : better diagnostics 2009-04-02 16:35:19 +0200 fs r270421 : diagnostics 2009-04-02 16:34:50 +0200 fs r270420 : #i99056# mxUnoShape not accessible anymore, use impl_setUnoShape instead 2009-04-02 16:32:48 +0200 fs r270419 : #i99056# make getUnoShape cheaper: keep the pointer to the SvxShape all the time, so there's no need to ask for it in getUnoShape. As a consequence, we will later be able to use the pointer in scenarious where performance (potentially) matters 2009-04-02 16:31:13 +0200 fs r270417 : merge changes from CWS dba32a herein 2009-04-02 16:23:16 +0200 fs r270414 : merge changes from CWS dba32a herein 2009-04-02 14:10:35 +0200 fs r270405 : #i10000# 2009-04-02 14:06:26 +0200 fs r270404 : merge changes from CWS dba32a herein 2009-04-02 14:03:03 +0200 fs r270401 : #i10000# 2009-04-02 13:58:13 +0200 fs r270400 : #i10000# 2009-04-02 12:59:44 +0200 fs r270397 : merge changes from CWS dba32a herein 2009-04-02 12:46:30 +0200 fs r270396 : #i99056# let the form page maintain a mapping between control models and control shapes 2009-04-02 12:44:07 +0200 fs r270395 : merge changes from CWS dba32a herein 2009-04-02 12:42:06 +0200 fs r270394 : merge changes from CWS dba32a herein 2009-04-02 12:35:20 +0200 fs r270393 : #i10000# precompiled header 2009-04-02 12:05:31 +0200 fs r270392 : merge changes from CWS dba32a herein 2009-04-02 12:00:42 +0200 fs r270391 : merge changes from CWS dba32a herein 2009-04-02 11:47:26 +0200 fs r270390 : merge changes from CWS dba32a herein 2009-04-02 11:39:15 +0200 oj r270389 : #i94467# foxpro impl several new types 2009-04-02 11:35:58 +0200 fs r270387 : merge changes from CWS dba32a herein 2009-04-01 14:10:51 +0200 fs r270329 : merge changes from CWS dba32a herein 2009-03-31 17:29:50 +0200 fs r270290 : merge changes from CWS dba32a herein 2009-03-30 14:53:56 +0200 fs r270233 : #i100417# don't set grid column widths to 0, but to <void/> 2009-03-30 12:31:03 +0200 oj r270213 : #i100552# wrong orb used 2009-03-30 12:19:20 +0200 oj r270212 : #i98303# convertlike corrected to sal_Unicode 2009-03-30 11:58:25 +0200 fs r270210 : merge changes from CWS dba32a herein 2009-03-30 11:38:16 +0200 oj r270205 : remove duplicate code from merge 2009-03-30 11:02:27 +0200 fs r270202 : merge changes from CWS dba32a herein 2009-03-30 11:02:19 +0200 fs r270201 : merge changes from CWS dba32a herein 2009-03-30 10:31:26 +0200 oj r270200 : #i100665# only throw exception and do not drop table 2009-03-30 09:36:24 +0200 fs r270195 : assertion text 2009-03-28 20:21:58 +0100 fs r270187 : #ii10000# 2009-03-28 20:19:54 +0100 fs r270186 : removed unused help ids 2009-03-28 20:19:40 +0100 fs r270185 : removed unused help ids 2009-03-28 20:19:10 +0100 fs r270184 : #i100237# +DefaultState/XReset 2009-03-28 00:29:29 +0100 fs r270177 : CWS-TOOLING: rebase CWS dba32b to trunk@270033 (milestone: DEV300:m45) 2009-03-27 22:56:46 +0100 fs r270173 : #i100237# DEFAULT_CHECKED -> DEFAULT_STATE 2009-03-27 22:55:52 +0100 fs r270172 : #i100237# DefaultState property for buttons, enabled only when Toggle=Yes 2009-03-27 22:54:15 +0100 fs r270171 : #i100237# DEFAULT_CHECKED -> DEFAULT_STATE 2009-03-27 22:53:54 +0100 fs r270170 : #i100237# introduce a DefaultState property for buttons, which implies buttongs supporting XReset, which needed some refactoring 2009-03-27 13:31:41 +0100 fs r270152 : ignore output paths 2009-03-27 11:23:44 +0100 fs r270139 : tuned behavior with respect to invalid keys/values 2009-03-27 09:57:14 +0100 fs r270136 : don't allow Double.NaN 2009-03-27 09:56:16 +0100 fs r270135 : talk about Double.NaN 2009-03-26 12:14:30 +0100 fs r270067 : removed unused parameter 2009-03-26 12:14:02 +0100 fs r270066 : removed widening conversion when checking keys 2009-03-26 09:17:34 +0100 fs r270053 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-26 09:17:11 +0100 fs r270052 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-26 09:16:49 +0100 fs r270051 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-25 21:55:20 +0100 fs r270044 : #i100541# properly calculat bNeedScrollBox 2009-03-25 12:56:17 +0100 fs r270019 : renamed the previously introduced error condition 2009-03-25 12:11:48 +0100 fs r270015 : #i100095# when the error messages contain non-trivial details (SQLState/ErrorCode), then always display the 'Details' button 2009-03-25 12:10:05 +0100 fs r270012 : renamed the previously introduced error condition 2009-03-25 12:01:04 +0100 fs r270011 : #i100095# when no address book (or respective profile) can be found, then use a dedicated ErrorCondition 2009-03-25 10:29:07 +0100 fs r270003 : add missing localization 2009-03-25 10:23:12 +0100 fs r270001 : in preparation of #i1000095#: rework the error handling, allow using css.sdb.ErrorCondition values, plus allow propagating the nsresult 2009-03-25 10:21:55 +0100 fs r270000 : in preparation of #i1000095#: rework the error handling, allow using css.sdb.ErrorCondition values, plus allow propagating the nsresult 2009-03-20 23:05:38 +0100 fs r269829 : XMap::getSize removed 2009-03-20 23:05:19 +0100 fs r269828 : changes as suggested by sb 2009-03-20 23:04:56 +0100 fs r269827 : enhanced documentation 2009-03-20 15:31:40 +0100 fs r269815 : changes as suggested by sb 2009-03-20 13:23:52 +0100 oj r269804 : #i92538# correct the zorder that fixedtext is infront of control 2009-03-20 12:59:38 +0100 oj r269801 : #i94571# paraadjust now supports BLOCK 2009-03-20 12:58:11 +0100 oj r269800 : #i94571# export style with data style 2009-03-20 12:57:05 +0100 oj r269799 : #i94571# text align is now paraadjust 2009-03-20 12:37:02 +0100 fs r269797 : enum keys only accepted if they have the exact type, not if they have *any* enum type 2009-03-20 12:28:31 +0100 fs r269794 : some changes requested by sb 2009-03-20 08:52:47 +0100 fs r269780 : doc 2009-03-20 07:37:31 +0100 oj r269779 : #i99913# only notifiy when values are different 2009-03-20 07:36:58 +0100 oj r269778 : #i99913# add undoenv as listener at the dataprovider 2009-03-19 22:52:52 +0100 fs r269771 : added comment 2009-03-19 22:40:06 +0100 fs r269770 : +testEnumeration 2009-03-19 22:39:41 +0100 fs r269769 : implemented enumeration, getKeySet, and getValues. Should be finished now. 2009-03-19 14:01:01 +0100 oj r269743 : #i99913# reset the modified state when selecting an object 2009-03-19 12:19:54 +0100 lla r269739 : #i72390# cleanups 2009-03-19 09:25:27 +0100 fs r269727 : #i10000# 2009-03-18 23:37:02 +0100 fs r269708 : extended checks for value type acceptance 2009-03-18 23:36:41 +0100 fs r269707 : fixed value type checks 2009-03-18 14:59:56 +0100 fs r269678 : initial complex test case for the new css.container.Map implementation 2009-03-18 14:59:24 +0100 fs r269677 : verifyExpectedException moved to base class (in complexlib), and renamed to assureException for consistency 2009-03-18 14:58:35 +0100 fs r269676 : removed unused imports 2009-03-18 14:58:03 +0100 fs r269675 : first implementation of the new css.container.Map service (not completed, yet) 2009-03-18 14:57:17 +0100 fs r269674 : base class for UNO components, freeing you from some repeating work 2009-03-18 14:55:53 +0100 fs r269672 : +assureException: call a given method with given parameters on a given object, ensure that a given exception is thrown by the method implementation 2009-03-18 14:54:58 +0100 fs r269671 : +getComponentContext 2009-03-18 14:54:00 +0100 fs r269670 : isEmpty returns a boolean, not a long 2009-03-18 14:14:43 +0100 oj r269663 : #i99743# now text also supports null 2009-03-18 13:54:14 +0100 oj r269660 : #i99223# remove check for 2 params 2009-03-18 13:33:35 +0100 oj r269659 : #i99060# replace text::ParagraphVertAlign with style::VerticalAlignment 2009-03-18 13:32:18 +0100 oj r269658 : #i99060# don't set void property when void isn't allowed 2009-03-18 13:31:11 +0100 oj r269657 : #i99060# handle vertical alignment 2009-03-18 13:28:28 +0100 oj r269656 : #i99060# remove unused elements from sytle 2009-03-18 09:35:42 +0100 lla r269639 : #i72390# cleanups 2009-03-18 09:31:20 +0100 lla r269638 : #i72390# add ButtonList 2009-03-18 09:30:46 +0100 lla r269637 : #i72390# renamed interface 2009-03-18 09:30:15 +0100 lla r269636 : #i72390# use ButtonList instead of ImageList 2009-03-18 09:29:05 +0100 lla r269635 : #i72390# new ButtonList, cleanups 2009-03-18 09:26:34 +0100 lla r269634 : #i72390# cleanups 2009-03-17 12:21:20 +0100 oj r269590 : #i99222# remove assertion 2009-03-17 12:17:22 +0100 oj r269589 : #i98605# impl scale mode 2009-03-17 12:10:42 +0100 oj r269588 : #i98605# impl scale mode 2009-03-17 11:40:15 +0100 oj r269584 : #i96944# doesn't create equation for shapes 2009-03-17 11:33:16 +0100 oj r269583 : #i96423# switch calc from float to long 2009-03-16 15:19:18 +0100 fs r269550 : #i41930# enable zoom for embedded/outplace documents 2009-03-16 14:25:54 +0100 oj r269542 : #i93734# remove ContextSensitive 2009-03-16 14:21:58 +0100 oj r269541 : #i99274# page header before group header 2009-03-16 14:18:23 +0100 oj r269539 : #i99110# fix value type 2009-03-16 14:14:16 +0100 fs r269537 : line ends 2009-03-16 14:11:06 +0100 fs r269535 : line ends 2009-03-16 14:08:34 +0100 fs r269534 : #i100087# (provided my np): allow for polymorphic types with more than one parameter 2009-03-16 12:30:31 +0100 oj r269521 : compile error 2009-03-16 12:19:12 +0100 oj r269519 : compile error 2009-03-16 10:39:28 +0100 oj r269511 : compile error under linux with swap 2009-03-13 10:33:04 +0100 oj r269462 : CWS-TOOLING: rebase CWS dba32b to trunk@269297 (milestone: DEV300:m43) 2009-03-12 14:37:25 +0100 fs r269416 : interface SequenceOutputStreamTest is unneeded, and pollutes the namespace here :) 2009-03-12 14:35:07 +0100 fs r269414 : not needed 2009-03-12 14:34:15 +0100 fs r269413 : preparation for multiple tests in this module 2009-03-12 14:33:02 +0100 fs r269412 : ShowTargets was moved from module integration.forms to module complexlib 2009-03-12 14:32:48 +0100 fs r269411 : helper class for projects containing multiple complex test cases (and following a certain structure) 2009-03-12 14:00:14 +0100 fs r269407 : proper module after the move 2009-03-12 13:59:10 +0100 fs r269406 : superseded by ../makefile.mk 2009-03-12 13:47:38 +0100 fs r269403 : not needed anymore 2009-03-12 13:45:46 +0100 fs r269402 : moved, in preparation of adding more test cases here, with a common infrastructure 2009-03-12 13:45:07 +0100 fs r269401 : moved from ../ 2009-03-12 13:43:59 +0100 fs r269400 : moved to ./comphelper, in preparation of adding more test cases here, with a common infrastructure 2009-03-12 13:29:47 +0100 oj r269396 : #i99914# set parent on dataprovider 2009-03-12 13:10:35 +0100 oj r269393 : #i99832# check thrown exception and show error 2009-03-12 13:08:10 +0100 fs r269392 : reorganizing tests 2009-03-12 12:52:55 +0100 oj r269390 : #i99118# convert formatkey in numberformat 2009-03-12 12:34:53 +0100 fs r269388 : new API tests 2009-03-12 12:29:05 +0100 fs r269386 : Map not yet committed 2009-03-12 12:28:36 +0100 fs r269385 : oops, forgot the SequenceInputStream during the previous refactoring 2009-03-12 12:12:39 +0100 oj r269384 : #i99104# set HasCategories prop 2009-03-12 12:12:08 +0100 oj r269383 : #i99104# check HasCategories even for internal dataprovider 2009-03-12 12:10:40 +0100 oj r269382 : #i99104# set HasCategories prop 2009-03-12 10:51:49 +0100 fs r269373 : #i10000# exception specifications 2009-03-12 10:49:18 +0100 fs r269372 : #i10000# exception specifications 2009-03-12 10:44:02 +0100 fs r269371 : #i10000# exception specifications 2009-03-12 10:30:55 +0100 fs r269368 : refactored the UNO service registration in this module, using the helper classes provided by comphelper itself, so you have less effort when extending the list of to-be-registered components 2009-03-12 10:30:37 +0100 fs r269367 : module-local includes 2009-03-12 07:05:54 +0100 oj r269357 : #i99104# database dataprovider doesn't need dataranges and diagramdata 2009-03-11 10:58:28 +0100 oj r269306 : #i99911# check if name of the report is a valid file name 2009-03-11 10:03:23 +0100 oj r269299 : #i99666# the report is new when the HierarchicalDocumentName is empty 2009-03-10 11:32:45 +0100 oj r269258 : #i99221# use fallback for language 2009-03-10 10:48:40 +0100 oj r269255 : #i99433# now use OStringBuffer 2009-03-10 10:36:21 +0100 fs r269252 : initial version of (X)Map 2009-03-10 09:52:23 +0100 oj r269246 : #i99433# now use OStringBuffer 2009-03-10 08:56:13 +0100 oj r269240 : #i99655# patch applied 2009-03-09 07:35:33 +0100 lla r269058 : #i10000# wrong variable assignment fixed 2009-03-06 17:20:40 +0100 fs r269030 : some explicit defaults 2009-03-06 17:20:30 +0100 fs r269029 : #i98600# 2009-03-06 14:40:34 +0100 fs r269009 : #i87692# during reload, prevent the document being modified just because of some control content changes ... 2009-03-06 12:52:20 +0100 lla r268997 : #i10000# ambigous problem with FontWeight fixed 2009-03-06 11:39:32 +0100 fs r268989 : #i10000# (approved by pl): use --without-t1-library configure option 2009-03-06 10:55:43 +0100 fs r268986 : #i99953# depends on xmlscript module now 2009-03-06 10:54:04 +0100 fs r268985 : #i99953# also adjust the event names found in dialogs embedded in the forms 2009-03-06 09:53:41 +0100 fs r268977 : #i10000# 2009-03-06 09:30:41 +0100 lla r268973 : #i10000# merge problems 2009-03-05 17:52:34 +0100 fs r268932 : #i98593# for sub components which are actually controlled by a DocumentDefinition (aka XComponentSupplier aka XCommandProcessor), close them by executing the 'close' command, not by suspending/closing the controller (which cannot be intercepted) 2009-03-05 11:41:56 +0100 fs r268889 : default the drop down line count for list/combo boxes to 20 2009-03-05 11:39:10 +0100 fs r268887 : do not display empty error messages 2009-03-02 10:13:57 +0100 lla r268639 : #i91541# CWS rebase m41 to m42 2009-03-02 09:06:27 +0100 lla r268635 : #i10000# add ';' to strings 2009-02-26 11:18:00 +0100 fs r268492 : reportdesign depends on REPORTBUILDER, not REPORTDESIGN 2009-02-26 10:11:38 +0100 lla r268489 : CWS-TOOLING: rebase CWS dba32b to trunk@268395 (milestone: DEV300:m42) 2009-02-26 09:04:11 +0100 lla r268488 : CWS-TOOLING: rebase CWS dba32b to trunk@268395 (milestone: DEV300:m42) 2009-02-24 12:09:13 +0100 lla r268392 : #i91541# #i91542# cleanups 2009-02-24 08:08:06 +0100 lla r268382 : merge all dba32a changes into dba32b 2009-02-24 07:14:55 +0100 lla r268381 : merge all dba32a changes into dba32b 2009-02-23 21:44:28 +0100 fs r268377 : oops ... don't tamper with m_aListSourceValues at the end of loadData 2009-02-23 20:57:05 +0100 fs r268376 : #i98162# don't hold the values as strings, but as ORowSetValue, this way preserving their type, and being agnostic to different result/rowset implementations doing different to-string-conversations 2009-02-23 20:55:44 +0100 fs r268375 : getObject: throwFunctionNotSupportedException, instead of silently returning NULL 2009-02-23 20:55:20 +0100 fs r268374 : #i98162# some more supported types 2009-02-23 20:54:43 +0100 fs r268373 : #i98162# +operator != 2009-02-20 09:35:39 +0100 fs r268306 : #i99422# for a font, display the font name, the style, and the size 2009-02-20 09:33:45 +0100 fs r268305 : #i99422# in the property browser, FONT supersedes CHARFONTNAME: the aggregated FormComponentHandler displays them more nicely now 2009-02-19 16:12:06 +0100 fs r268293 : #i99372# recognize DataType::FLOAT as numeric 2009-02-19 15:43:12 +0100 fs r268291 : #i99415# 2009-02-19 15:40:15 +0100 fs r268290 : #i99242# lcl_firstFocussableControl: take disabled controls into account 2009-02-19 15:34:36 +0100 fs r268289 : #i99396# properly decode the base name of the URL when using it as title 2009-02-19 15:19:05 +0100 fs r268287 : #i98247#
2009-06-05 09:47:55 +00:00
// if it's a actuating property, then update the UI for any dependent
// properties
if ( impl_isActuatingProperty_nothrow( _rEvent.PropertyName ) )
impl_broadcastPropertyChange_nothrow( _rEvent.PropertyName, aNewValue, _rEvent.OldValue, false );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
//------------------------------------------------------------------------
Reference< XPropertyControl > SAL_CALL OPropertyBrowserController::createPropertyControl( ::sal_Int16 ControlType, ::sal_Bool _CreateReadOnly ) throw (IllegalArgumentException, RuntimeException)
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
{
::osl::MutexGuard aGuard( m_aMutex );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
Reference< XPropertyControl > xControl;
// default winbits: a border only
WinBits nWinBits = WB_BORDER;
// read-only-ness
_CreateReadOnly |= (sal_Bool)impl_isReadOnlyModel_throw();
if ( _CreateReadOnly )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
nWinBits |= WB_READONLY;
switch ( ControlType )
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
case PropertyControlType::StringListField:
xControl = new OMultilineEditControl( &getPropertyBox(), eStringList, nWinBits | WB_DROPDOWN | WB_TABSTOP );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
break;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
case PropertyControlType::MultiLineTextField:
xControl = new OMultilineEditControl( &getPropertyBox(), eMultiLineText, nWinBits | WB_DROPDOWN | WB_TABSTOP );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
break;
case PropertyControlType::ListBox:
xControl = new OListboxControl( &getPropertyBox(), nWinBits | WB_TABSTOP | WB_DROPDOWN);
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
break;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
case PropertyControlType::ComboBox:
xControl = new OComboboxControl( &getPropertyBox(), nWinBits | WB_TABSTOP | WB_DROPDOWN);
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
break;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
case PropertyControlType::TextField:
xControl = new OEditControl( &getPropertyBox(), sal_False, nWinBits | WB_TABSTOP );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
break;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
case PropertyControlType::CharacterField:
xControl = new OEditControl( &getPropertyBox(), sal_True, nWinBits | WB_TABSTOP );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
break;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
case PropertyControlType::NumericField:
xControl = new ONumericControl( &getPropertyBox(), nWinBits | WB_TABSTOP | WB_SPIN | WB_REPEAT );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
break;
case PropertyControlType::DateTimeField:
xControl = new ODateTimeControl( &getPropertyBox(), nWinBits | WB_TABSTOP );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
break;
case PropertyControlType::DateField:
xControl = new ODateControl( &getPropertyBox(), nWinBits | WB_TABSTOP | WB_SPIN | WB_REPEAT );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
break;
case PropertyControlType::TimeField:
xControl = new OTimeControl( &getPropertyBox(), nWinBits | WB_TABSTOP | WB_SPIN | WB_REPEAT );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
break;
case PropertyControlType::ColorListBox:
xControl = new OColorControl( &getPropertyBox(), nWinBits | WB_TABSTOP | WB_DROPDOWN );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
break;
case PropertyControlType::HyperlinkField:
xControl = new OHyperlinkControl( &getPropertyBox(), nWinBits | WB_TABSTOP | WB_DROPDOWN );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
break;
default:
throw IllegalArgumentException( ::rtl::OUString(), *this, 1 );
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
return xControl;
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
void OPropertyBrowserController::impl_toggleInspecteeListening_nothrow( bool _bOn )
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
for ( InterfaceArray::const_iterator loop = m_aInspectedObjects.begin();
loop != m_aInspectedObjects.end();
++loop
)
{
try
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
Reference< XComponent > xComp( *loop, UNO_QUERY );
if ( xComp.is() )
CWS-TOOLING: integrate CWS cmcfixes51 2008-12-08 10:12:55 +0100 cmc r264975 : #i96203# protect with ifdefs to avoid unused symbol on mac 2008-12-05 12:23:47 +0100 cmc r264898 : CWS-TOOLING: rebase CWS cmcfixes51 to trunk@264807 (milestone: DEV300:m37) 2008-12-01 14:45:17 +0100 cmc r264606 : #i76655# ehlos apparently required 2008-11-28 17:49:30 +0100 cmc r264567 : #i96655# remove newly unused method 2008-11-28 10:41:28 +0100 cmc r264531 : #i96647# better ppc-bridges flushCode impl 2008-11-27 12:58:40 +0100 cmc r264478 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 12:32:49 +0100 cmc r264476 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 12:26:02 +0100 cmc r264475 : #i96655# redundant old table export helpers 2008-11-27 11:49:06 +0100 cmc r264473 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 11:38:35 +0100 cmc r264471 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 11:14:21 +0100 cmc r264467 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 11:06:22 +0100 cmc r264464 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:58:18 +0100 cmc r264462 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:41:44 +0100 cmc r264461 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:19:24 +0100 cmc r264460 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:13:39 +0100 cmc r264459 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:06:14 +0100 cmc r264458 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:59:54 +0100 cmc r264457 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:52:51 +0100 cmc r264456 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:48:26 +0100 cmc r264454 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:40:20 +0100 cmc r264452 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:35:26 +0100 cmc r264451 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:31:00 +0100 cmc r264450 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:24:08 +0100 cmc r264449 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 00:26:15 +0100 cmc r264443 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 00:21:01 +0100 cmc r264442 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 00:09:40 +0100 cmc r264441 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 23:51:56 +0100 cmc r264440 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 23:49:09 +0100 cmc r264439 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 18:09:54 +0100 cmc r264432 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 18:07:40 +0100 cmc r264431 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 17:28:02 +0100 cmc r264429 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 17:27:39 +0100 cmc r264428 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 17:18:36 +0100 cmc r264426 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 16:22:16 +0100 cmc r264415 : #i96624# make implicit braces and brackets explicit to avoid warnings 2008-11-26 16:00:23 +0100 cmc r264409 : #i90426# remove warnings from svtools 2008-11-26 15:59:17 +0100 cmc r264408 : #i90426# remove warnings 2008-11-26 15:47:32 +0100 cmc r264404 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 14:46:57 +0100 cmc r264394 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 14:19:50 +0100 cmc r264387 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 14:15:26 +0100 cmc r264386 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 14:11:26 +0100 cmc r264384 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 13:44:23 +0100 cmc r264380 : #i96084# comfirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 13:12:24 +0100 cmc r264372 : #i96604# silence new warnings 2008-11-26 12:35:02 +0100 cmc r264369 : #i96203# make qstarter work in 3-layer land 2008-11-26 12:33:04 +0100 cmc r264368 : #i96170# ensure gtypes are up and running
2008-12-11 07:05:03 +00:00
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
if ( _bOn )
xComp->addEventListener( static_cast< XPropertyChangeListener* >( this ) );
else
xComp->removeEventListener( static_cast< XPropertyChangeListener* >( this ) );
CWS-TOOLING: integrate CWS cmcfixes51 2008-12-08 10:12:55 +0100 cmc r264975 : #i96203# protect with ifdefs to avoid unused symbol on mac 2008-12-05 12:23:47 +0100 cmc r264898 : CWS-TOOLING: rebase CWS cmcfixes51 to trunk@264807 (milestone: DEV300:m37) 2008-12-01 14:45:17 +0100 cmc r264606 : #i76655# ehlos apparently required 2008-11-28 17:49:30 +0100 cmc r264567 : #i96655# remove newly unused method 2008-11-28 10:41:28 +0100 cmc r264531 : #i96647# better ppc-bridges flushCode impl 2008-11-27 12:58:40 +0100 cmc r264478 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 12:32:49 +0100 cmc r264476 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 12:26:02 +0100 cmc r264475 : #i96655# redundant old table export helpers 2008-11-27 11:49:06 +0100 cmc r264473 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 11:38:35 +0100 cmc r264471 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 11:14:21 +0100 cmc r264467 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 11:06:22 +0100 cmc r264464 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:58:18 +0100 cmc r264462 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:41:44 +0100 cmc r264461 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:19:24 +0100 cmc r264460 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:13:39 +0100 cmc r264459 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:06:14 +0100 cmc r264458 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:59:54 +0100 cmc r264457 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:52:51 +0100 cmc r264456 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:48:26 +0100 cmc r264454 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:40:20 +0100 cmc r264452 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:35:26 +0100 cmc r264451 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:31:00 +0100 cmc r264450 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:24:08 +0100 cmc r264449 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 00:26:15 +0100 cmc r264443 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 00:21:01 +0100 cmc r264442 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 00:09:40 +0100 cmc r264441 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 23:51:56 +0100 cmc r264440 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 23:49:09 +0100 cmc r264439 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 18:09:54 +0100 cmc r264432 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 18:07:40 +0100 cmc r264431 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 17:28:02 +0100 cmc r264429 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 17:27:39 +0100 cmc r264428 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 17:18:36 +0100 cmc r264426 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 16:22:16 +0100 cmc r264415 : #i96624# make implicit braces and brackets explicit to avoid warnings 2008-11-26 16:00:23 +0100 cmc r264409 : #i90426# remove warnings from svtools 2008-11-26 15:59:17 +0100 cmc r264408 : #i90426# remove warnings 2008-11-26 15:47:32 +0100 cmc r264404 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 14:46:57 +0100 cmc r264394 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 14:19:50 +0100 cmc r264387 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 14:15:26 +0100 cmc r264386 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 14:11:26 +0100 cmc r264384 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 13:44:23 +0100 cmc r264380 : #i96084# comfirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 13:12:24 +0100 cmc r264372 : #i96604# silence new warnings 2008-11-26 12:35:02 +0100 cmc r264369 : #i96203# make qstarter work in 3-layer land 2008-11-26 12:33:04 +0100 cmc r264368 : #i96170# ensure gtypes are up and running
2008-12-11 07:05:03 +00:00
}
}
catch( const Exception& )
{
DBG_UNHANDLED_EXCEPTION();
}
}
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
void OPropertyBrowserController::stopInspection( bool _bCommitModified )
{
if ( haveView() )
{
if ( _bCommitModified )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// commit the editor's content
getPropertyBox().CommitModified();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// hide the property box so that it does not flicker
getPropertyBox().Hide();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// clear the property box
getPropertyBox().ClearAll();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// destroy the view first
if ( haveView() )
{
// remove the pages
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
for ( HashString2Int16::const_iterator erase = m_aPageIds.begin();
erase != m_aPageIds.end();
++erase
)
getPropertyBox().RemovePage( erase->second );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
clearContainer( m_aPageIds );
}
2001-02-05 07:58:27 +00:00
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
clearContainer( m_aProperties );
2001-02-05 07:58:27 +00:00
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// de-register as dispose-listener from our inspected objects
impl_toggleInspecteeListening_nothrow( false );
// handlers are obsolete, so is our "composer" for their UI requests
if ( m_pUIRequestComposer.get() )
m_pUIRequestComposer->dispose();
m_pUIRequestComposer.reset( NULL );
// clean up the property handlers
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
PropertyHandlerArray aAllHandlers; // will contain every handler exactly once
for ( PropertyHandlerRepository::const_iterator aHandler = m_aPropertyHandlers.begin();
aHandler != m_aPropertyHandlers.end();
++aHandler
)
if ( ::std::find( aAllHandlers.begin(), aAllHandlers.end(), aHandler->second ) == aAllHandlers.end() )
aAllHandlers.push_back( aHandler->second );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
for ( PropertyHandlerArray::iterator loop = aAllHandlers.begin();
loop != aAllHandlers.end();
++loop
)
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
{
try
{
(*loop)->removePropertyChangeListener( this );
(*loop)->dispose();
}
catch( const DisposedException& )
{
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
catch( const Exception& )
{
DBG_UNHANDLED_EXCEPTION();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
clearContainer( m_aPropertyHandlers );
clearContainer( m_aDependencyHandlers );
}
//------------------------------------------------------------------------
bool OPropertyBrowserController::impl_hasPropertyHandlerFor_nothrow( const ::rtl::OUString& _rPropertyName ) const
{
PropertyHandlerRepository::const_iterator handlerPos = m_aPropertyHandlers.find( _rPropertyName );
return ( handlerPos != m_aPropertyHandlers.end() );
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
OPropertyBrowserController::PropertyHandlerRef OPropertyBrowserController::impl_getHandlerForProperty_throw( const ::rtl::OUString& _rPropertyName ) const
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
PropertyHandlerRepository::const_iterator handlerPos = m_aPropertyHandlers.find( _rPropertyName );
if ( handlerPos == m_aPropertyHandlers.end() )
throw RuntimeException();
return handlerPos->second;
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
//------------------------------------------------------------------------
Any OPropertyBrowserController::impl_getPropertyValue_throw( const ::rtl::OUString& _rPropertyName )
{
PropertyHandlerRef handler = impl_getHandlerForProperty_throw( _rPropertyName );
return handler->getPropertyValue( _rPropertyName );
}
//------------------------------------------------------------------------
void OPropertyBrowserController::impl_rebindToInspectee_nothrow( const InterfaceArray& _rObjects )
{
try
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// stop inspecting the old object(s)
stopInspection( true );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// inspect the new object(s)
m_aInspectedObjects = _rObjects;
doInspection();
// update the user interface
UpdateUI();
}
2011-12-10 22:14:57 +09:00
catch(const Exception&)
{
2011-03-01 17:55:09 +01:00
OSL_FAIL("OPropertyBrowserController::impl_rebindToInspectee_nothrow: caught an exception !");
}
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
void OPropertyBrowserController::doInspection()
{
try
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
//////////////////////////////////////////////////////////////////////
// obtain the properties of the object
::std::vector< Property > aProperties;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
PropertyHandlerArray aPropertyHandlers;
getPropertyHandlers( m_aInspectedObjects, aPropertyHandlers );
PropertyHandlerArray::iterator aHandler( aPropertyHandlers.begin() );
while ( aHandler != aPropertyHandlers.end() )
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
DBG_ASSERT( aHandler->get(), "OPropertyBrowserController::doInspection: invalid handler!" );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
StlSyntaxSequence< Property > aThisHandlersProperties = (*aHandler)->getSupportedProperties();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
if ( aThisHandlersProperties.empty() )
{
// this handler doesn't know anything about the current inspectee -> ignore it
(*aHandler)->dispose();
aHandler = aPropertyHandlers.erase( aHandler );
continue;
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// append these properties to our "all properties" array
aProperties.reserve( aProperties.size() + aThisHandlersProperties.size() );
for ( StlSyntaxSequence< Property >::const_iterator copyProperty = aThisHandlersProperties.begin();
copyProperty != aThisHandlersProperties.end();
++copyProperty
)
{
::std::vector< Property >::const_iterator previous = ::std::find_if(
aProperties.begin(),
aProperties.end(),
FindPropertyByName( copyProperty->Name )
);
if ( previous == aProperties.end() )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
{
aProperties.push_back( *copyProperty );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
continue;
}
// there already was another (previous) handler which supported this property.
// Don't add it to aProperties, again.
// Also, ensure that handlers which previously expressed interest in *changes*
// of this property are not notified.
// This is 'cause we have a new handler which is responsible for this property,
// which means it can give it a completely different meaning than the previous
// handler for this property is prepared for.
::std::pair< PropertyHandlerMultiRepository::iterator, PropertyHandlerMultiRepository::iterator >
aDepHandlers = m_aDependencyHandlers.equal_range( copyProperty->Name );
m_aDependencyHandlers.erase( aDepHandlers.first, aDepHandlers.second );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// determine the superseded properties
StlSyntaxSequence< ::rtl::OUString > aSupersededByThisHandler = (*aHandler)->getSupersededProperties();
for ( StlSyntaxSequence< ::rtl::OUString >::const_iterator superseded = aSupersededByThisHandler.begin();
superseded != aSupersededByThisHandler.end();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
++superseded
)
{
::std::vector< Property >::iterator existent = ::std::find_if(
aProperties.begin(),
aProperties.end(),
FindPropertyByName( *superseded )
);
if ( existent != aProperties.end() )
// one of the properties superseded by this handler was supported by a previous
// one -> erase
aProperties.erase( existent );
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// be notified of changes which this handler is responsible for
(*aHandler)->addPropertyChangeListener( this );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// remember this handler for every of the properties which it is responsible
// for
for ( StlSyntaxSequence< Property >::const_iterator remember = aThisHandlersProperties.begin();
remember != aThisHandlersProperties.end();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
++remember
)
{
m_aPropertyHandlers[ remember->Name ] = *aHandler;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// note that this implies that if two handlers support the same property,
// the latter wins
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// see if the handler expresses interest in any actuating properties
StlSyntaxSequence< ::rtl::OUString > aInterestingActuations = (*aHandler)->getActuatingProperties();
for ( StlSyntaxSequence< ::rtl::OUString >::const_iterator aLoop = aInterestingActuations.begin();
aLoop != aInterestingActuations.end();
++aLoop
)
{
m_aDependencyHandlers.insert( PropertyHandlerMultiRepository::value_type(
*aLoop, *aHandler ) );
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
++aHandler;
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// create a new composer for UI requests coming from the handlers
m_pUIRequestComposer.reset( new ComposedPropertyUIUpdate( getInspectorUI(), this ) );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// sort the properties by relative position, as indicated by the model
for ( ::std::vector< Property >::const_iterator sourceProps = aProperties.begin();
sourceProps != aProperties.end();
++sourceProps
)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
sal_Int32 nRelativePropertyOrder = sourceProps - aProperties.begin();
if ( m_xModel.is() )
nRelativePropertyOrder = m_xModel->getPropertyOrderIndex( sourceProps->Name );
while ( m_aProperties.find( nRelativePropertyOrder ) != m_aProperties.end() )
++nRelativePropertyOrder;
m_aProperties[ nRelativePropertyOrder ] = *sourceProps;
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// be notified when one of our inspectees dies
impl_toggleInspecteeListening_nothrow( true );
}
2011-12-10 22:14:57 +09:00
catch(const Exception&)
{
2011-03-01 17:55:09 +01:00
OSL_FAIL("OPropertyBrowserController::doInspection : caught an exception !");
}
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
::com::sun::star::awt::Size SAL_CALL OPropertyBrowserController::getMinimumSize() throw (::com::sun::star::uno::RuntimeException)
{
::com::sun::star::awt::Size aSize;
if( m_pView )
return m_pView->getMinimumSize();
else
return aSize;
}
//------------------------------------------------------------------------
::com::sun::star::awt::Size SAL_CALL OPropertyBrowserController::getPreferredSize() throw (::com::sun::star::uno::RuntimeException)
{
return getMinimumSize();
}
//------------------------------------------------------------------------
::com::sun::star::awt::Size SAL_CALL OPropertyBrowserController::calcAdjustedSize( const ::com::sun::star::awt::Size& _rNewSize ) throw (::com::sun::star::uno::RuntimeException)
{
awt::Size aMinSize = getMinimumSize( );
awt::Size aAdjustedSize( _rNewSize );
if ( aAdjustedSize.Width < aMinSize.Width )
aAdjustedSize.Width = aMinSize.Width;
if ( aAdjustedSize.Height < aMinSize.Height )
aAdjustedSize.Height = aMinSize.Height;
return aAdjustedSize;
}
//------------------------------------------------------------------------
void OPropertyBrowserController::describePropertyLine( const Property& _rProperty, OLineDescriptor& _rDescriptor ) SAL_THROW((Exception))
{
try
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
PropertyHandlerRepository::const_iterator handler = m_aPropertyHandlers.find( _rProperty.Name );
if ( handler == m_aPropertyHandlers.end() )
throw RuntimeException(); // caught below
_rDescriptor.assignFrom( handler->second->describePropertyLine( _rProperty.Name, this ) );
//////////////////////////////////////////////////////////////////////
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
_rDescriptor.xPropertyHandler = handler->second;
_rDescriptor.sName = _rProperty.Name;
_rDescriptor.aValue = _rDescriptor.xPropertyHandler->getPropertyValue( _rProperty.Name );
if ( _rDescriptor.DisplayName.isEmpty() )
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
#ifdef DBG_UTIL
::rtl::OString sMessage( "OPropertyBrowserController::describePropertyLine: handler did not provide a display name for '" );
sMessage += ::rtl::OString( _rProperty.Name.getStr(), _rProperty.Name.getLength(), RTL_TEXTENCODING_ASCII_US );
sMessage += ::rtl::OString( "'!" );
DBG_ASSERT( !_rDescriptor.DisplayName.isEmpty(), sMessage.getStr() );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
#endif
_rDescriptor.DisplayName = _rProperty.Name;
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
PropertyState ePropertyState( _rDescriptor.xPropertyHandler->getPropertyState( _rProperty.Name ) );
if ( PropertyState_AMBIGUOUS_VALUE == ePropertyState )
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
_rDescriptor.bUnknownValue = true;
_rDescriptor.aValue.clear();
}
_rDescriptor.bReadOnly = impl_isReadOnlyModel_throw();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
catch( const Exception& )
{
OSL_FAIL( "OPropertyBrowserController::describePropertyLine: caught an exception!" );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
//------------------------------------------------------------------------
void OPropertyBrowserController::impl_buildCategories_throw()
{
OSL_PRECOND( m_aPageIds.empty(), "OPropertyBrowserController::impl_buildCategories_throw: duplicate call!" );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
StlSyntaxSequence< PropertyCategoryDescriptor > aCategories;
if ( m_xModel.is() )
aCategories = m_xModel->describeCategories();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
for ( StlSyntaxSequence< PropertyCategoryDescriptor >::const_iterator category = aCategories.begin();
category != aCategories.end();
++category
)
{
OSL_ENSURE( m_aPageIds.find( category->ProgrammaticName ) == m_aPageIds.end(),
"OPropertyBrowserController::impl_buildCategories_throw: duplicate programmatic name!" );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
m_aPageIds[ category->ProgrammaticName ] =
getPropertyBox().AppendPage( category->UIName, HelpIdUrl::getHelpId( category->HelpURL ) );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
//------------------------------------------------------------------------
void OPropertyBrowserController::UpdateUI()
{
try
{
if ( !haveView() )
// too early, will return later
return;
getPropertyBox().DisableUpdate();
sal_Bool bHaveFocus = getPropertyBox().HasChildPathFocus();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// create our tab pages
impl_buildCategories_throw();
// (and allow for pages to be actually unused)
::std::set< sal_uInt16 > aUsedPages;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// when building the UI below, remember which properties are actuating,
// to allow for a initial actuatinPropertyChanged call
::std::vector< ::rtl::OUString > aActuatingProperties;
::std::vector< Any > aActuatingPropertyValues;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// ask the handlers to describe the property UI, and insert the resulting
// entries into our list boxes
OrderedPropertyMap::const_iterator property( m_aProperties.begin() );
for ( ; property != m_aProperties.end(); ++property )
{
OLineDescriptor aDescriptor;
describePropertyLine( property->second, aDescriptor );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
bool bIsActuatingProperty = impl_isActuatingProperty_nothrow( property->second.Name );
#if OSL_DEBUG_LEVEL > 0
if ( aDescriptor.Category.isEmpty() )
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
::rtl::OString sMessage( "OPropertyBrowserController::UpdateUI: empty category provided for property '" );
sMessage += ::rtl::OString( property->second.Name.getStr(), property->second.Name.getLength(), osl_getThreadTextEncoding() );
sMessage += "'!";
OSL_FAIL( sMessage.getStr() );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
#endif
// finally insert this property control
sal_uInt16 nTargetPageId = impl_getPageIdForCategory_nothrow( aDescriptor.Category );
if ( nTargetPageId == (sal_uInt16)-1 )
{
// this category does not yet exist. This is allowed, as an inspector model might be lazy, and not provide
// any category information of its own. In this case, we have a fallback ...
m_aPageIds[ aDescriptor.Category ] =
getPropertyBox().AppendPage( aDescriptor.Category, rtl::OString() );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
nTargetPageId = impl_getPageIdForCategory_nothrow( aDescriptor.Category );
}
getPropertyBox().InsertEntry( aDescriptor, nTargetPageId );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
aUsedPages.insert( nTargetPageId );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// if it's an actuating property, remember it
if ( bIsActuatingProperty )
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
aActuatingProperties.push_back( property->second.Name );
aActuatingPropertyValues.push_back( impl_getPropertyValue_throw( property->second.Name ) );
}
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// update any dependencies for the actuating properties which we encountered
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
::std::vector< ::rtl::OUString >::const_iterator aProperty = aActuatingProperties.begin();
::std::vector< Any >::const_iterator aPropertyValue = aActuatingPropertyValues.begin();
for ( ; aProperty != aActuatingProperties.end(); ++aProperty, ++aPropertyValue )
impl_broadcastPropertyChange_nothrow( *aProperty, *aPropertyValue, *aPropertyValue, true );
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// remove any unused pages (which we did not encounter properties for)
HashString2Int16 aSurvivingPageIds;
for ( HashString2Int16::iterator pageId = m_aPageIds.begin();
pageId != m_aPageIds.end();
++pageId
)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
if ( aUsedPages.find( pageId->second ) == aUsedPages.end() )
getPropertyBox().RemovePage( pageId->second );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
else
aSurvivingPageIds.insert( *pageId );
}
m_aPageIds.swap( aSurvivingPageIds );
getPropertyBox().Show();
getPropertyBox().EnableUpdate();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
if ( bHaveFocus )
getPropertyBox().GrabFocus();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// activate the first page
if ( !m_aPageIds.empty() )
{
Sequence< PropertyCategoryDescriptor > aCategories( m_xModel->describeCategories() );
if ( aCategories.getLength() )
m_pView->activatePage( m_aPageIds[ aCategories[0].ProgrammaticName ] );
else
// allowed: if we default-created the pages ...
m_pView->activatePage( m_aPageIds.begin()->second );
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// activate the previously active page (if possible)
if ( !m_sLastValidPageSelection.isEmpty() )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
m_sPageSelection = m_sLastValidPageSelection;
selectPageFromViewData();
}
catch( const Exception& )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
{
DBG_UNHANDLED_EXCEPTION();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
//------------------------------------------------------------------------
void OPropertyBrowserController::Clicked( const ::rtl::OUString& _rName, sal_Bool _bPrimary )
{
try
{
// since the browse buttons do not get the focus when clicked with the mouse,
// we need to commit the changes in the current property field
getPropertyBox().CommitModified();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
PropertyHandlerRepository::const_iterator handler = m_aPropertyHandlers.find( _rName );
DBG_ASSERT( handler != m_aPropertyHandlers.end(), "OPropertyBrowserController::Clicked: a property without handler? This will crash!" );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
ComposedUIAutoFireGuard aAutoFireGuard( *m_pUIRequestComposer );
Any aData;
m_xInteractiveHandler = handler->second;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
InteractiveSelectionResult eResult =
handler->second->onInteractivePropertySelection( _rName, _bPrimary, aData,
m_pUIRequestComposer->getUIForPropertyHandler( handler->second ) );
switch ( eResult )
{
case InteractiveSelectionResult_Cancelled:
case InteractiveSelectionResult_Success:
// okay, nothing to do
break;
case InteractiveSelectionResult_ObtainedValue:
handler->second->setPropertyValue( _rName, aData );
break;
case InteractiveSelectionResult_Pending:
// also okay, we expect that the handler has disabled the UI as necessary
break;
default:
OSL_FAIL( "OPropertyBrowserController::Clicked: unknown result value!" );
break;
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
2011-12-10 22:14:57 +09:00
catch (const Exception&)
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
{
2008-10-16 06:57:26 +00:00
DBG_UNHANDLED_EXCEPTION();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
m_xInteractiveHandler = NULL;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
//------------------------------------------------------------------------
sal_Bool SAL_CALL OPropertyBrowserController::hasPropertyByName( const ::rtl::OUString& _rName ) throw (RuntimeException)
{
for ( OrderedPropertyMap::const_iterator search = m_aProperties.begin();
search != m_aProperties.end();
++search
)
if ( search->second.Name == _rName )
return true;
return false;
}
//------------------------------------------------------------------------
void OPropertyBrowserController::Commit( const ::rtl::OUString& rName, const Any& _rValue )
{
try
{
CWS-TOOLING: integrate CWS dba31e 2008-11-19 12:36:23 +0100 msc r263980 : i96104 2008-11-19 12:31:19 +0100 msc r263979 : i96104 2008-11-19 12:21:55 +0100 msc r263977 : i96104 2008-11-19 12:18:53 +0100 msc r263976 : i96104 2008-11-18 09:09:45 +0100 oj r263746 : disable color entry when area is set 2008-11-18 08:37:52 +0100 oj r263741 : #remove sub report entry 2008-11-17 11:20:25 +0100 fs r263708 : #i10000# 2008-11-17 11:06:52 +0100 fs r263706 : minimal version now is 3.1 2008-11-12 22:25:59 +0100 fs r263621 : #i96150# 2008-11-12 22:20:02 +0100 fs r263620 : rebased to m34 2008-11-12 21:39:41 +0100 fs r263618 : MANUAL REBASE: rebase CWS dba31d to DEV300_m34 2008-11-12 13:54:58 +0100 fs r263597 : #i96134# MediaDescriptor.URL is to be preferred over MediaDescriptor.FileName. Nonetheless, ensure both are handled 2008-11-12 13:53:40 +0100 fs r263596 : #i96134# re-enabled the code for #i41897#, a better fix is to come 2008-11-12 12:48:21 +0100 fs r263585 : #i96134# disable saving URLs of file-base databases relatively 2008-11-11 16:11:11 +0100 msc r263566 : #i96104# 2008-11-05 09:09:47 +0100 oj r263342 : #i88727# color noe added 2008-11-05 08:41:43 +0100 oj r263341 : #i77916# zoom added 2008-11-04 21:24:15 +0100 fs r263339 : disposing: call disposeAndClear without own mutex locked - some of our listeners insist on locking the SolarMutex, which sometimes led to deadlocks on the complex test cases 2008-11-04 21:23:15 +0100 fs r263338 : remove SolarMutex locking - this happned in CWS dba31c (in the CVS version), which this CWS was created from, but seems to got lost during resync 2008-11-04 20:49:50 +0100 fs r263335 : docu formatting 2008-11-04 20:06:39 +0100 fs r263334 : #i95826# use m_aMutex, not a DocumentGuard (wrongly resolved merge conflicts) 2008-11-04 17:36:29 +0100 fs r263332 : #i92688# properly revoke as XEventListener from m_xActiveController when disposing 2008-11-04 14:49:34 +0100 fs r263324 : #i92322# enable Input Required if EmptyIsNULL does not exist at the control 2008-10-31 11:10:04 +0100 oj r262857 : merge from cvs to svn 2008-10-31 09:46:45 +0100 oj r262853 : merge from cvs to svn 2008-10-31 08:46:37 +0100 oj r262849 : merge from cvs to svn 2008-10-31 08:44:24 +0100 oj r262848 : merge from cvs to svn 2008-10-31 08:43:33 +0100 oj r262847 : merge from cvs to svn 2008-10-31 08:42:28 +0100 oj r262846 : merge from cvs to svn 2008-10-31 08:41:58 +0100 oj r262845 : merge from cvs to svn 2008-10-31 08:41:32 +0100 oj r262844 : merge from cvs to svn 2008-10-28 12:19:50 +0100 oj r262733 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:42 +0100 oj r262732 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:36 +0100 oj r262731 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:31 +0100 oj r262730 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:22 +0100 oj r262729 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:18 +0100 oj r262728 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:10 +0100 oj r262727 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:06 +0100 oj r262726 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:05 +0100 oj r262725 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:01 +0100 oj r262724 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:50 +0100 oj r262723 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:41 +0100 oj r262722 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:40 +0100 oj r262721 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:27 +0100 oj r262720 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:10 +0100 oj r262719 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:01 +0100 oj r262718 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:17:39 +0100 oj r262717 : #iXXXXX#: migrate CWS dba31e to SVN
2008-12-01 12:31:27 +00:00
rtl::OUString sPlcHolder = String( PcrRes( RID_EMBED_IMAGE_PLACEHOLDER ) );
bool bIsPlaceHolderValue = false;
if ( rName.equals( PROPERTY_IMAGE_URL ) )
{
// if the prop value is the PlaceHolder
// can ignore it
rtl::OUString sVal;
_rValue >>= sVal;
if ( sVal.equals( sPlcHolder ) )
bIsPlaceHolderValue = true;
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
m_sCommittingProperty = rName;
bool bIsActuatingProperty = impl_isActuatingProperty_nothrow( rName );
Any aOldValue;
if ( bIsActuatingProperty )
aOldValue = impl_getPropertyValue_throw( rName );
// do we have a dedicated handler for this property, which we can delegate some tasks to?
PropertyHandlerRef handler = impl_getHandlerForProperty_throw( rName );
//////////////////////////////////////////////////////////////////////
CWS-TOOLING: integrate CWS dba31e 2008-11-19 12:36:23 +0100 msc r263980 : i96104 2008-11-19 12:31:19 +0100 msc r263979 : i96104 2008-11-19 12:21:55 +0100 msc r263977 : i96104 2008-11-19 12:18:53 +0100 msc r263976 : i96104 2008-11-18 09:09:45 +0100 oj r263746 : disable color entry when area is set 2008-11-18 08:37:52 +0100 oj r263741 : #remove sub report entry 2008-11-17 11:20:25 +0100 fs r263708 : #i10000# 2008-11-17 11:06:52 +0100 fs r263706 : minimal version now is 3.1 2008-11-12 22:25:59 +0100 fs r263621 : #i96150# 2008-11-12 22:20:02 +0100 fs r263620 : rebased to m34 2008-11-12 21:39:41 +0100 fs r263618 : MANUAL REBASE: rebase CWS dba31d to DEV300_m34 2008-11-12 13:54:58 +0100 fs r263597 : #i96134# MediaDescriptor.URL is to be preferred over MediaDescriptor.FileName. Nonetheless, ensure both are handled 2008-11-12 13:53:40 +0100 fs r263596 : #i96134# re-enabled the code for #i41897#, a better fix is to come 2008-11-12 12:48:21 +0100 fs r263585 : #i96134# disable saving URLs of file-base databases relatively 2008-11-11 16:11:11 +0100 msc r263566 : #i96104# 2008-11-05 09:09:47 +0100 oj r263342 : #i88727# color noe added 2008-11-05 08:41:43 +0100 oj r263341 : #i77916# zoom added 2008-11-04 21:24:15 +0100 fs r263339 : disposing: call disposeAndClear without own mutex locked - some of our listeners insist on locking the SolarMutex, which sometimes led to deadlocks on the complex test cases 2008-11-04 21:23:15 +0100 fs r263338 : remove SolarMutex locking - this happned in CWS dba31c (in the CVS version), which this CWS was created from, but seems to got lost during resync 2008-11-04 20:49:50 +0100 fs r263335 : docu formatting 2008-11-04 20:06:39 +0100 fs r263334 : #i95826# use m_aMutex, not a DocumentGuard (wrongly resolved merge conflicts) 2008-11-04 17:36:29 +0100 fs r263332 : #i92688# properly revoke as XEventListener from m_xActiveController when disposing 2008-11-04 14:49:34 +0100 fs r263324 : #i92322# enable Input Required if EmptyIsNULL does not exist at the control 2008-10-31 11:10:04 +0100 oj r262857 : merge from cvs to svn 2008-10-31 09:46:45 +0100 oj r262853 : merge from cvs to svn 2008-10-31 08:46:37 +0100 oj r262849 : merge from cvs to svn 2008-10-31 08:44:24 +0100 oj r262848 : merge from cvs to svn 2008-10-31 08:43:33 +0100 oj r262847 : merge from cvs to svn 2008-10-31 08:42:28 +0100 oj r262846 : merge from cvs to svn 2008-10-31 08:41:58 +0100 oj r262845 : merge from cvs to svn 2008-10-31 08:41:32 +0100 oj r262844 : merge from cvs to svn 2008-10-28 12:19:50 +0100 oj r262733 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:42 +0100 oj r262732 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:36 +0100 oj r262731 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:31 +0100 oj r262730 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:22 +0100 oj r262729 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:18 +0100 oj r262728 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:10 +0100 oj r262727 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:06 +0100 oj r262726 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:05 +0100 oj r262725 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:01 +0100 oj r262724 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:50 +0100 oj r262723 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:41 +0100 oj r262722 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:40 +0100 oj r262721 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:27 +0100 oj r262720 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:10 +0100 oj r262719 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:01 +0100 oj r262718 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:17:39 +0100 oj r262717 : #iXXXXX#: migrate CWS dba31e to SVN
2008-12-01 12:31:27 +00:00
// set the value ( only if it's not a placeholder )
if ( !bIsPlaceHolderValue )
handler->setPropertyValue( rName, _rValue );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
//////////////////////////////////////////////////////////////////////
// re-retrieve the value
Any aNormalizedValue = handler->getPropertyValue( rName );
// care for any inter-property dependencies
if ( bIsActuatingProperty )
impl_broadcastPropertyChange_nothrow( rName, aNormalizedValue, aOldValue, false );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// and display it again. This ensures proper formatting
CWS-TOOLING: integrate CWS dba32b 2009-06-03 14:58:08 +0200 fs r272581 : #i102439# 2009-05-29 13:56:18 +0200 fs r272456 : remove the sub form when the 'add subform' setting changes from <true/> to <false/>, not only its controls 2009-05-29 13:19:27 +0200 fs r272454 : display '(Default)' instead of an empty string when a control has the default font 2009-05-28 20:49:18 +0200 fs r272428 : #i98162# getFirstSelectedValue: do not return reference to a temporary 2009-05-27 15:30:22 +0200 msc r272353 : #102303# 2009-05-26 13:03:06 +0200 fs r272295 : spelling 2009-05-26 12:59:54 +0200 fs r272294 : merge m48 version to get latest cygwin related fixes 2009-05-25 14:02:06 +0200 fs r272239 : remove references to local files, needed for debugging sessions only 2009-05-25 14:01:16 +0200 fs r272238 : #i102021# ensure members such as bNumberFormat are initialized before actually returning them 2009-05-25 13:10:20 +0200 fs r272236 : #i10000# reset ENABLE_EVOAB2 2009-05-22 06:44:45 +0200 oj r272167 : #i99104# add import handler for calc-sett 2009-05-22 06:42:27 +0200 oj r272166 : #i99104# impl NullDate as member 2009-05-22 06:36:22 +0200 oj r272165 : #i99104# handle nulldate from parent model 2009-05-22 06:33:13 +0200 oj r272164 : #i99104# export and import calculation-settings and nulldate 2009-05-22 06:27:50 +0200 oj r272163 : #i99104# export and import calculation-settings and nulldate 2009-05-20 13:29:58 +0200 oj r272118 : #i99911# handle invalid name 2009-05-20 13:28:49 +0200 oj r272117 : #i101261# handle different rowsets 2009-05-20 11:29:55 +0200 msc r272111 : #i100000# 2009-05-20 11:28:27 +0200 msc r272110 : merge in change from dba32a 2009-05-20 11:27:38 +0200 msc r272109 : #102082# CTRL + C does not work 2009-05-20 09:43:36 +0200 oj r272106 : clean up includes 2009-05-20 09:32:15 +0200 oj r272105 : #i99060# merge error resovled now VERTICAL_ALIGN is in both stmt 2009-05-20 08:37:21 +0200 msc r272104 : add workaround for issue #102010# 2009-05-20 08:10:12 +0200 oj r272103 : #i99104# use numberformatkey 2009-05-20 08:07:02 +0200 oj r272102 : #i99104# use column info from rowset 2009-05-20 08:04:43 +0200 oj r272101 : #i102032# use a special column type where prec and scale are the values currently set at the column 2009-05-20 08:03:04 +0200 oj r272100 : #i102032# correct type info, we have to use SQL defined type names 2009-05-19 10:27:02 +0200 oj r272061 : #i99104# export null-date 2009-05-19 08:26:53 +0200 oj r272056 : #i99104# export null-date 2009-05-18 13:15:10 +0200 msc r272014 : add issue #102019# 2009-05-18 11:33:07 +0200 msc r272005 : add issue #102019# 2009-05-18 08:59:45 +0200 msc r271996 : add workaroud for issue #102010# 2009-05-15 10:21:24 +0200 msc r271929 : #101944# 2009-05-11 21:18:30 +0200 fs r271792 : #i99914# 2009-05-08 13:52:06 +0200 oj r271715 : #i96423# remember column span 2009-05-08 11:26:19 +0200 oj r271708 : #i98605# impl new scale mode 2009-05-08 10:33:35 +0200 fs r271706 : SendUserCall: only call into the shape notification routine for UserCall types where this is necessary (performance issue) 2009-05-07 20:52:44 +0200 fs r271698 : outsource ShapeProperty from shapepropertynotifier.hxx 2009-05-07 20:43:33 +0200 fs r271697 : #i99056# use notifyShapePropertyChange, instead of getShapePropertyChangeNotifier - the latter throws if no shape exists, yet 2009-05-07 20:33:58 +0200 fs r271696 : #i99056# +notifyShapePropertyChange: allow notifying chages without checking whether there actually already exists an SvxShape 2009-05-07 16:22:15 +0200 fs r271679 : #i10000# cygwin needs quotes around the classpath 2009-05-07 16:21:37 +0200 fs r271678 : #i10000# cygwin needs quotes around the classpath 2009-05-07 16:01:11 +0200 oj r271677 : #i99914# notify parent handler 2009-05-07 15:54:54 +0200 fs r271676 : #i10000# cygwin needs some quoting 2009-05-07 14:49:48 +0200 oj r271672 : #i99277# quote alias name 2009-05-07 14:48:12 +0200 oj r271671 : #i92538# add ~ in front of type 2009-05-07 14:37:13 +0200 oj r271667 : #i99118# change type from char to varchar 2009-05-07 14:36:23 +0200 oj r271666 : #i99118# clear dest columns when changing to create new table 2009-05-07 13:35:32 +0200 oj r271657 : #i94467# handle type 0 as double as well 2009-05-07 13:20:49 +0200 oj r271655 : i99743# setNull when varchar is no text 2009-05-07 12:58:06 +0200 fs r271651 : initialize the SdrObject's property change notifier after the ctor, if necessary 2009-05-07 11:47:18 +0200 fs r271647 : #i10000# 2009-05-07 10:57:16 +0200 fs r271639 : OPropertyBrowserController::propertyChange: care for the current property state, too, and properly forward it to the UI 2009-05-07 10:18:14 +0200 fs r271636 : onNewComponent: do not ask the map for grid columns, it will throw 2009-05-07 10:09:55 +0200 fs r271634 : #i101623# 2009-05-07 09:53:44 +0200 fs r271631 : #i101622# 2009-05-06 21:55:53 +0200 fs r271615 : #i10000# 2009-05-06 21:10:42 +0200 fs r271611 : #i10000# 2009-05-06 13:11:48 +0200 fs r271583 : #i10000# 2009-05-05 22:29:31 +0200 fs r271559 : proper assertion message 2009-05-05 22:29:03 +0200 fs r271558 : diagnostics 2009-05-05 22:16:16 +0200 fs r271557 : #i10000# 2009-05-05 13:50:32 +0200 fs r271513 : #i10000# 2009-05-05 10:21:50 +0200 fs r271503 : #i10000# 2009-05-05 09:30:26 +0200 fs r271501 : why did those survive the rebase -C step? 2009-05-05 09:18:12 +0200 fs r271500 : #i10000# 2009-05-04 17:08:17 +0200 fs r271475 : CWS-TOOLING: rebase CWS dba32b to trunk@271427 (milestone: DEV300:m47) 2009-05-04 14:51:26 +0200 fs r271456 : line ends 2009-04-30 15:55:27 +0200 fs r271418 : NewURL -> PublicConnectionURL 2009-04-22 21:18:34 +0200 fs r271141 : #i100944# 2009-04-22 09:12:26 +0200 oj r271071 : #i101261# little code change 2009-04-22 09:11:43 +0200 oj r271070 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:11:25 +0200 oj r271069 : #i101261# new grabage container for nodes 2009-04-22 09:11:02 +0200 oj r271068 : #i101261# new grabage container for nodes 2009-04-22 09:10:44 +0200 oj r271067 : #i101261# new grabage container for nodes 2009-04-22 09:10:21 +0200 oj r271066 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:08:24 +0200 oj r271065 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:07:25 +0200 oj r271064 : #i101261# only ask for parameters which aren't set before 2009-04-22 08:49:07 +0200 oj r271062 : #i77501# preview only when needed 2009-04-22 08:45:44 +0200 oj r271061 : #i101261# new prop max rows 2009-04-22 08:44:18 +0200 oj r271060 : #i101261# create dataprovider earlier to avoid the wrong legend in chart 2009-04-22 08:42:48 +0200 oj r271059 : #i101261# handle parameter 2009-04-17 21:00:23 +0200 fs r270954 : #i98350# 2009-04-17 13:54:19 +0200 fs r270942 : #i99565# 2009-04-17 13:51:34 +0200 fs r270940 : #i101153# only localize the (potentially) localizable properties when there really is support at the control model 2009-04-17 11:43:14 +0200 fs r270932 : removed superfluous include 2009-04-17 10:10:15 +0200 fs r270926 : #i10000# 2009-04-17 10:02:36 +0200 fs r270925 : #i10000# 2009-04-17 09:15:13 +0200 fs r270918 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 09:14:56 +0200 fs r270917 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 09:13:25 +0200 fs r270915 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 08:30:34 +0200 fs r270914 : removed unotools/servicehelper.hxx in favour of the (duplicated) comphelper/servicehelper.hxx 2009-04-16 21:05:25 +0200 fs r270903 : #i10000# 2009-04-16 20:43:43 +0200 fs r270902 : #i99056# shape notification outsourced to the SdrObject, this is what all other shape implementations (which only aggregate an SvxShape) have access to, too 2009-04-16 15:57:36 +0200 fs r270891 : #i99056# make SetUnoControlModel virtual 2009-04-16 15:44:02 +0200 fs r270890 : #i99056# let the ScShapeObj notify changes in its Anchor property 2009-04-16 15:36:47 +0200 fs r270889 : #i99056# enable the sheet anchor type property, too 2009-04-16 15:33:45 +0200 fs r270887 : #i99056# shape notification outsourced to the SdrObject, this is what all other shape implementations (which only aggregate an SvxShape) have access to, too 2009-04-15 14:53:13 +0200 fs r270844 : #i10000# 2009-04-15 13:08:29 +0200 fs r270836 : #i10000# 2009-04-15 12:28:14 +0200 fs r270832 : #i10000# 2009-04-15 10:59:14 +0200 fs r270827 : #i10000# 2009-04-15 09:41:08 +0200 oj r270823 : fix issues found with findbugs and pmd 2009-04-14 21:08:04 +0200 fs r270808 : #i99056# implement SheetAnchorType - now the only thing missing to enable it is the proper notification when it is modified 2009-04-14 17:09:00 +0200 fs r270799 : #i99056# implement XServiceInfo for the ScShapeObj 2009-04-14 17:07:55 +0200 fs r270798 : #i99056# implement TextAnchorType, partially implement SheetAnchorType 2009-04-14 15:54:05 +0200 fs r270786 : #i99056# SwXShape: notify changes of the AnchorType property 2009-04-14 15:47:32 +0200 fs r270785 : #i99056# deliver shapepropertynotifier.hxx 2009-04-14 15:46:54 +0200 fs r270784 : diagnostics 2009-04-14 15:08:28 +0200 fs r270781 : #i99056# outsourced the SvxShape's property change notification code into a dedicated class 2009-04-14 14:41:09 +0200 fs r270773 : #i99056# outsourced the SvxShape's property change notification code into a dedicated class 2009-04-14 14:37:23 +0200 fs r270772 : in dtor, remove the properties from the temporary component context 2009-04-14 14:36:34 +0200 fs r270771 : getWeakUnoShape made const 2009-04-14 12:23:08 +0200 oj r270757 : #i101064# add missing braces 2009-04-14 12:21:25 +0200 oj r270756 : #i101065# add braces for gcc 4.3.2 2009-04-14 12:17:45 +0200 oj r270755 : #i101059# add dep for manifest 2009-04-09 12:06:58 +0200 oj r270686 : #i93100# use OptimalSize from control to get height 2009-04-08 09:56:55 +0200 oj r270619 : #i92537# handle calculations in the select columns as well 2009-04-08 09:30:39 +0200 oj r270615 : #i96657# throw error message when the key doesn't have any columns 2009-04-07 12:08:26 +0200 oj r270592 : #i77501# impl preview of the executed report 2009-04-07 12:01:56 +0200 oj r270591 : #i77501# impl preview of the executed report 2009-04-07 11:41:03 +0200 oj r270590 : #i77501# impl preview of the executed report 2009-04-07 11:39:32 +0200 oj r270589 : #i77501# impl preview of the executed report 2009-04-07 11:29:25 +0200 oj r270588 : #i77501# convert dos to unix lineends 2009-04-07 11:28:23 +0200 oj r270587 : #i77501# impl preview of the executed report 2009-04-07 11:16:50 +0200 oj r270586 : #i77501# impl preview of the executed report 2009-04-07 11:16:00 +0200 oj r270585 : #i77501# impl preview of the executed report 2009-04-07 11:15:44 +0200 oj r270584 : #i77501# impl preview of the executed report 2009-04-07 11:15:28 +0200 oj r270583 : #i77501# impl preview of the executed report 2009-04-07 11:15:04 +0200 oj r270582 : #i77501# impl preview of the executed report 2009-04-06 15:38:54 +0200 fs r270559 : merge changes from CWS dba32a herein 2009-04-03 15:56:16 +0200 fs r270494 : ImpSvMEdit::Resize: do multiple iterations, if necessary 2009-04-03 14:35:49 +0200 fs r270487 : #i10000# 2009-04-03 13:17:16 +0200 fs r270476 : #i99056# display geometry information for controls, too 2009-04-03 13:16:37 +0200 fs r270475 : #i99056# better ordering of the geometry properties 2009-04-03 13:16:07 +0200 fs r270473 : #i99056# now that SvxShape supports property change listeners, forward add/remove requests to it 2009-04-03 13:13:18 +0200 fs r270472 : #i99056# at SvxShape, allow for PropertyChangeListeners for Size/Position 2009-04-03 09:29:27 +0200 oj r270456 : #i94571# use correct prop name 2009-04-03 09:14:54 +0200 fs r270451 : merge changes from CWS dba32a herein 2009-04-02 17:00:51 +0200 fs r270424 : better diagnostics 2009-04-02 16:35:19 +0200 fs r270421 : diagnostics 2009-04-02 16:34:50 +0200 fs r270420 : #i99056# mxUnoShape not accessible anymore, use impl_setUnoShape instead 2009-04-02 16:32:48 +0200 fs r270419 : #i99056# make getUnoShape cheaper: keep the pointer to the SvxShape all the time, so there's no need to ask for it in getUnoShape. As a consequence, we will later be able to use the pointer in scenarious where performance (potentially) matters 2009-04-02 16:31:13 +0200 fs r270417 : merge changes from CWS dba32a herein 2009-04-02 16:23:16 +0200 fs r270414 : merge changes from CWS dba32a herein 2009-04-02 14:10:35 +0200 fs r270405 : #i10000# 2009-04-02 14:06:26 +0200 fs r270404 : merge changes from CWS dba32a herein 2009-04-02 14:03:03 +0200 fs r270401 : #i10000# 2009-04-02 13:58:13 +0200 fs r270400 : #i10000# 2009-04-02 12:59:44 +0200 fs r270397 : merge changes from CWS dba32a herein 2009-04-02 12:46:30 +0200 fs r270396 : #i99056# let the form page maintain a mapping between control models and control shapes 2009-04-02 12:44:07 +0200 fs r270395 : merge changes from CWS dba32a herein 2009-04-02 12:42:06 +0200 fs r270394 : merge changes from CWS dba32a herein 2009-04-02 12:35:20 +0200 fs r270393 : #i10000# precompiled header 2009-04-02 12:05:31 +0200 fs r270392 : merge changes from CWS dba32a herein 2009-04-02 12:00:42 +0200 fs r270391 : merge changes from CWS dba32a herein 2009-04-02 11:47:26 +0200 fs r270390 : merge changes from CWS dba32a herein 2009-04-02 11:39:15 +0200 oj r270389 : #i94467# foxpro impl several new types 2009-04-02 11:35:58 +0200 fs r270387 : merge changes from CWS dba32a herein 2009-04-01 14:10:51 +0200 fs r270329 : merge changes from CWS dba32a herein 2009-03-31 17:29:50 +0200 fs r270290 : merge changes from CWS dba32a herein 2009-03-30 14:53:56 +0200 fs r270233 : #i100417# don't set grid column widths to 0, but to <void/> 2009-03-30 12:31:03 +0200 oj r270213 : #i100552# wrong orb used 2009-03-30 12:19:20 +0200 oj r270212 : #i98303# convertlike corrected to sal_Unicode 2009-03-30 11:58:25 +0200 fs r270210 : merge changes from CWS dba32a herein 2009-03-30 11:38:16 +0200 oj r270205 : remove duplicate code from merge 2009-03-30 11:02:27 +0200 fs r270202 : merge changes from CWS dba32a herein 2009-03-30 11:02:19 +0200 fs r270201 : merge changes from CWS dba32a herein 2009-03-30 10:31:26 +0200 oj r270200 : #i100665# only throw exception and do not drop table 2009-03-30 09:36:24 +0200 fs r270195 : assertion text 2009-03-28 20:21:58 +0100 fs r270187 : #ii10000# 2009-03-28 20:19:54 +0100 fs r270186 : removed unused help ids 2009-03-28 20:19:40 +0100 fs r270185 : removed unused help ids 2009-03-28 20:19:10 +0100 fs r270184 : #i100237# +DefaultState/XReset 2009-03-28 00:29:29 +0100 fs r270177 : CWS-TOOLING: rebase CWS dba32b to trunk@270033 (milestone: DEV300:m45) 2009-03-27 22:56:46 +0100 fs r270173 : #i100237# DEFAULT_CHECKED -> DEFAULT_STATE 2009-03-27 22:55:52 +0100 fs r270172 : #i100237# DefaultState property for buttons, enabled only when Toggle=Yes 2009-03-27 22:54:15 +0100 fs r270171 : #i100237# DEFAULT_CHECKED -> DEFAULT_STATE 2009-03-27 22:53:54 +0100 fs r270170 : #i100237# introduce a DefaultState property for buttons, which implies buttongs supporting XReset, which needed some refactoring 2009-03-27 13:31:41 +0100 fs r270152 : ignore output paths 2009-03-27 11:23:44 +0100 fs r270139 : tuned behavior with respect to invalid keys/values 2009-03-27 09:57:14 +0100 fs r270136 : don't allow Double.NaN 2009-03-27 09:56:16 +0100 fs r270135 : talk about Double.NaN 2009-03-26 12:14:30 +0100 fs r270067 : removed unused parameter 2009-03-26 12:14:02 +0100 fs r270066 : removed widening conversion when checking keys 2009-03-26 09:17:34 +0100 fs r270053 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-26 09:17:11 +0100 fs r270052 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-26 09:16:49 +0100 fs r270051 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-25 21:55:20 +0100 fs r270044 : #i100541# properly calculat bNeedScrollBox 2009-03-25 12:56:17 +0100 fs r270019 : renamed the previously introduced error condition 2009-03-25 12:11:48 +0100 fs r270015 : #i100095# when the error messages contain non-trivial details (SQLState/ErrorCode), then always display the 'Details' button 2009-03-25 12:10:05 +0100 fs r270012 : renamed the previously introduced error condition 2009-03-25 12:01:04 +0100 fs r270011 : #i100095# when no address book (or respective profile) can be found, then use a dedicated ErrorCondition 2009-03-25 10:29:07 +0100 fs r270003 : add missing localization 2009-03-25 10:23:12 +0100 fs r270001 : in preparation of #i1000095#: rework the error handling, allow using css.sdb.ErrorCondition values, plus allow propagating the nsresult 2009-03-25 10:21:55 +0100 fs r270000 : in preparation of #i1000095#: rework the error handling, allow using css.sdb.ErrorCondition values, plus allow propagating the nsresult 2009-03-20 23:05:38 +0100 fs r269829 : XMap::getSize removed 2009-03-20 23:05:19 +0100 fs r269828 : changes as suggested by sb 2009-03-20 23:04:56 +0100 fs r269827 : enhanced documentation 2009-03-20 15:31:40 +0100 fs r269815 : changes as suggested by sb 2009-03-20 13:23:52 +0100 oj r269804 : #i92538# correct the zorder that fixedtext is infront of control 2009-03-20 12:59:38 +0100 oj r269801 : #i94571# paraadjust now supports BLOCK 2009-03-20 12:58:11 +0100 oj r269800 : #i94571# export style with data style 2009-03-20 12:57:05 +0100 oj r269799 : #i94571# text align is now paraadjust 2009-03-20 12:37:02 +0100 fs r269797 : enum keys only accepted if they have the exact type, not if they have *any* enum type 2009-03-20 12:28:31 +0100 fs r269794 : some changes requested by sb 2009-03-20 08:52:47 +0100 fs r269780 : doc 2009-03-20 07:37:31 +0100 oj r269779 : #i99913# only notifiy when values are different 2009-03-20 07:36:58 +0100 oj r269778 : #i99913# add undoenv as listener at the dataprovider 2009-03-19 22:52:52 +0100 fs r269771 : added comment 2009-03-19 22:40:06 +0100 fs r269770 : +testEnumeration 2009-03-19 22:39:41 +0100 fs r269769 : implemented enumeration, getKeySet, and getValues. Should be finished now. 2009-03-19 14:01:01 +0100 oj r269743 : #i99913# reset the modified state when selecting an object 2009-03-19 12:19:54 +0100 lla r269739 : #i72390# cleanups 2009-03-19 09:25:27 +0100 fs r269727 : #i10000# 2009-03-18 23:37:02 +0100 fs r269708 : extended checks for value type acceptance 2009-03-18 23:36:41 +0100 fs r269707 : fixed value type checks 2009-03-18 14:59:56 +0100 fs r269678 : initial complex test case for the new css.container.Map implementation 2009-03-18 14:59:24 +0100 fs r269677 : verifyExpectedException moved to base class (in complexlib), and renamed to assureException for consistency 2009-03-18 14:58:35 +0100 fs r269676 : removed unused imports 2009-03-18 14:58:03 +0100 fs r269675 : first implementation of the new css.container.Map service (not completed, yet) 2009-03-18 14:57:17 +0100 fs r269674 : base class for UNO components, freeing you from some repeating work 2009-03-18 14:55:53 +0100 fs r269672 : +assureException: call a given method with given parameters on a given object, ensure that a given exception is thrown by the method implementation 2009-03-18 14:54:58 +0100 fs r269671 : +getComponentContext 2009-03-18 14:54:00 +0100 fs r269670 : isEmpty returns a boolean, not a long 2009-03-18 14:14:43 +0100 oj r269663 : #i99743# now text also supports null 2009-03-18 13:54:14 +0100 oj r269660 : #i99223# remove check for 2 params 2009-03-18 13:33:35 +0100 oj r269659 : #i99060# replace text::ParagraphVertAlign with style::VerticalAlignment 2009-03-18 13:32:18 +0100 oj r269658 : #i99060# don't set void property when void isn't allowed 2009-03-18 13:31:11 +0100 oj r269657 : #i99060# handle vertical alignment 2009-03-18 13:28:28 +0100 oj r269656 : #i99060# remove unused elements from sytle 2009-03-18 09:35:42 +0100 lla r269639 : #i72390# cleanups 2009-03-18 09:31:20 +0100 lla r269638 : #i72390# add ButtonList 2009-03-18 09:30:46 +0100 lla r269637 : #i72390# renamed interface 2009-03-18 09:30:15 +0100 lla r269636 : #i72390# use ButtonList instead of ImageList 2009-03-18 09:29:05 +0100 lla r269635 : #i72390# new ButtonList, cleanups 2009-03-18 09:26:34 +0100 lla r269634 : #i72390# cleanups 2009-03-17 12:21:20 +0100 oj r269590 : #i99222# remove assertion 2009-03-17 12:17:22 +0100 oj r269589 : #i98605# impl scale mode 2009-03-17 12:10:42 +0100 oj r269588 : #i98605# impl scale mode 2009-03-17 11:40:15 +0100 oj r269584 : #i96944# doesn't create equation for shapes 2009-03-17 11:33:16 +0100 oj r269583 : #i96423# switch calc from float to long 2009-03-16 15:19:18 +0100 fs r269550 : #i41930# enable zoom for embedded/outplace documents 2009-03-16 14:25:54 +0100 oj r269542 : #i93734# remove ContextSensitive 2009-03-16 14:21:58 +0100 oj r269541 : #i99274# page header before group header 2009-03-16 14:18:23 +0100 oj r269539 : #i99110# fix value type 2009-03-16 14:14:16 +0100 fs r269537 : line ends 2009-03-16 14:11:06 +0100 fs r269535 : line ends 2009-03-16 14:08:34 +0100 fs r269534 : #i100087# (provided my np): allow for polymorphic types with more than one parameter 2009-03-16 12:30:31 +0100 oj r269521 : compile error 2009-03-16 12:19:12 +0100 oj r269519 : compile error 2009-03-16 10:39:28 +0100 oj r269511 : compile error under linux with swap 2009-03-13 10:33:04 +0100 oj r269462 : CWS-TOOLING: rebase CWS dba32b to trunk@269297 (milestone: DEV300:m43) 2009-03-12 14:37:25 +0100 fs r269416 : interface SequenceOutputStreamTest is unneeded, and pollutes the namespace here :) 2009-03-12 14:35:07 +0100 fs r269414 : not needed 2009-03-12 14:34:15 +0100 fs r269413 : preparation for multiple tests in this module 2009-03-12 14:33:02 +0100 fs r269412 : ShowTargets was moved from module integration.forms to module complexlib 2009-03-12 14:32:48 +0100 fs r269411 : helper class for projects containing multiple complex test cases (and following a certain structure) 2009-03-12 14:00:14 +0100 fs r269407 : proper module after the move 2009-03-12 13:59:10 +0100 fs r269406 : superseded by ../makefile.mk 2009-03-12 13:47:38 +0100 fs r269403 : not needed anymore 2009-03-12 13:45:46 +0100 fs r269402 : moved, in preparation of adding more test cases here, with a common infrastructure 2009-03-12 13:45:07 +0100 fs r269401 : moved from ../ 2009-03-12 13:43:59 +0100 fs r269400 : moved to ./comphelper, in preparation of adding more test cases here, with a common infrastructure 2009-03-12 13:29:47 +0100 oj r269396 : #i99914# set parent on dataprovider 2009-03-12 13:10:35 +0100 oj r269393 : #i99832# check thrown exception and show error 2009-03-12 13:08:10 +0100 fs r269392 : reorganizing tests 2009-03-12 12:52:55 +0100 oj r269390 : #i99118# convert formatkey in numberformat 2009-03-12 12:34:53 +0100 fs r269388 : new API tests 2009-03-12 12:29:05 +0100 fs r269386 : Map not yet committed 2009-03-12 12:28:36 +0100 fs r269385 : oops, forgot the SequenceInputStream during the previous refactoring 2009-03-12 12:12:39 +0100 oj r269384 : #i99104# set HasCategories prop 2009-03-12 12:12:08 +0100 oj r269383 : #i99104# check HasCategories even for internal dataprovider 2009-03-12 12:10:40 +0100 oj r269382 : #i99104# set HasCategories prop 2009-03-12 10:51:49 +0100 fs r269373 : #i10000# exception specifications 2009-03-12 10:49:18 +0100 fs r269372 : #i10000# exception specifications 2009-03-12 10:44:02 +0100 fs r269371 : #i10000# exception specifications 2009-03-12 10:30:55 +0100 fs r269368 : refactored the UNO service registration in this module, using the helper classes provided by comphelper itself, so you have less effort when extending the list of to-be-registered components 2009-03-12 10:30:37 +0100 fs r269367 : module-local includes 2009-03-12 07:05:54 +0100 oj r269357 : #i99104# database dataprovider doesn't need dataranges and diagramdata 2009-03-11 10:58:28 +0100 oj r269306 : #i99911# check if name of the report is a valid file name 2009-03-11 10:03:23 +0100 oj r269299 : #i99666# the report is new when the HierarchicalDocumentName is empty 2009-03-10 11:32:45 +0100 oj r269258 : #i99221# use fallback for language 2009-03-10 10:48:40 +0100 oj r269255 : #i99433# now use OStringBuffer 2009-03-10 10:36:21 +0100 fs r269252 : initial version of (X)Map 2009-03-10 09:52:23 +0100 oj r269246 : #i99433# now use OStringBuffer 2009-03-10 08:56:13 +0100 oj r269240 : #i99655# patch applied 2009-03-09 07:35:33 +0100 lla r269058 : #i10000# wrong variable assignment fixed 2009-03-06 17:20:40 +0100 fs r269030 : some explicit defaults 2009-03-06 17:20:30 +0100 fs r269029 : #i98600# 2009-03-06 14:40:34 +0100 fs r269009 : #i87692# during reload, prevent the document being modified just because of some control content changes ... 2009-03-06 12:52:20 +0100 lla r268997 : #i10000# ambigous problem with FontWeight fixed 2009-03-06 11:39:32 +0100 fs r268989 : #i10000# (approved by pl): use --without-t1-library configure option 2009-03-06 10:55:43 +0100 fs r268986 : #i99953# depends on xmlscript module now 2009-03-06 10:54:04 +0100 fs r268985 : #i99953# also adjust the event names found in dialogs embedded in the forms 2009-03-06 09:53:41 +0100 fs r268977 : #i10000# 2009-03-06 09:30:41 +0100 lla r268973 : #i10000# merge problems 2009-03-05 17:52:34 +0100 fs r268932 : #i98593# for sub components which are actually controlled by a DocumentDefinition (aka XComponentSupplier aka XCommandProcessor), close them by executing the 'close' command, not by suspending/closing the controller (which cannot be intercepted) 2009-03-05 11:41:56 +0100 fs r268889 : default the drop down line count for list/combo boxes to 20 2009-03-05 11:39:10 +0100 fs r268887 : do not display empty error messages 2009-03-02 10:13:57 +0100 lla r268639 : #i91541# CWS rebase m41 to m42 2009-03-02 09:06:27 +0100 lla r268635 : #i10000# add ';' to strings 2009-02-26 11:18:00 +0100 fs r268492 : reportdesign depends on REPORTBUILDER, not REPORTDESIGN 2009-02-26 10:11:38 +0100 lla r268489 : CWS-TOOLING: rebase CWS dba32b to trunk@268395 (milestone: DEV300:m42) 2009-02-26 09:04:11 +0100 lla r268488 : CWS-TOOLING: rebase CWS dba32b to trunk@268395 (milestone: DEV300:m42) 2009-02-24 12:09:13 +0100 lla r268392 : #i91541# #i91542# cleanups 2009-02-24 08:08:06 +0100 lla r268382 : merge all dba32a changes into dba32b 2009-02-24 07:14:55 +0100 lla r268381 : merge all dba32a changes into dba32b 2009-02-23 21:44:28 +0100 fs r268377 : oops ... don't tamper with m_aListSourceValues at the end of loadData 2009-02-23 20:57:05 +0100 fs r268376 : #i98162# don't hold the values as strings, but as ORowSetValue, this way preserving their type, and being agnostic to different result/rowset implementations doing different to-string-conversations 2009-02-23 20:55:44 +0100 fs r268375 : getObject: throwFunctionNotSupportedException, instead of silently returning NULL 2009-02-23 20:55:20 +0100 fs r268374 : #i98162# some more supported types 2009-02-23 20:54:43 +0100 fs r268373 : #i98162# +operator != 2009-02-20 09:35:39 +0100 fs r268306 : #i99422# for a font, display the font name, the style, and the size 2009-02-20 09:33:45 +0100 fs r268305 : #i99422# in the property browser, FONT supersedes CHARFONTNAME: the aggregated FormComponentHandler displays them more nicely now 2009-02-19 16:12:06 +0100 fs r268293 : #i99372# recognize DataType::FLOAT as numeric 2009-02-19 15:43:12 +0100 fs r268291 : #i99415# 2009-02-19 15:40:15 +0100 fs r268290 : #i99242# lcl_firstFocussableControl: take disabled controls into account 2009-02-19 15:34:36 +0100 fs r268289 : #i99396# properly decode the base name of the URL when using it as title 2009-02-19 15:19:05 +0100 fs r268287 : #i98247#
2009-06-05 09:47:55 +00:00
getPropertyBox().SetPropertyValue( rName, aNormalizedValue, false );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
2011-12-10 22:14:57 +09:00
catch(const PropertyVetoException& eVetoException)
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
{
InfoBox(m_pView, eVetoException.Message).Execute();
PropertyHandlerRef handler = impl_getHandlerForProperty_throw( rName );
Any aNormalizedValue = handler->getPropertyValue( rName );
CWS-TOOLING: integrate CWS dba32b 2009-06-03 14:58:08 +0200 fs r272581 : #i102439# 2009-05-29 13:56:18 +0200 fs r272456 : remove the sub form when the 'add subform' setting changes from <true/> to <false/>, not only its controls 2009-05-29 13:19:27 +0200 fs r272454 : display '(Default)' instead of an empty string when a control has the default font 2009-05-28 20:49:18 +0200 fs r272428 : #i98162# getFirstSelectedValue: do not return reference to a temporary 2009-05-27 15:30:22 +0200 msc r272353 : #102303# 2009-05-26 13:03:06 +0200 fs r272295 : spelling 2009-05-26 12:59:54 +0200 fs r272294 : merge m48 version to get latest cygwin related fixes 2009-05-25 14:02:06 +0200 fs r272239 : remove references to local files, needed for debugging sessions only 2009-05-25 14:01:16 +0200 fs r272238 : #i102021# ensure members such as bNumberFormat are initialized before actually returning them 2009-05-25 13:10:20 +0200 fs r272236 : #i10000# reset ENABLE_EVOAB2 2009-05-22 06:44:45 +0200 oj r272167 : #i99104# add import handler for calc-sett 2009-05-22 06:42:27 +0200 oj r272166 : #i99104# impl NullDate as member 2009-05-22 06:36:22 +0200 oj r272165 : #i99104# handle nulldate from parent model 2009-05-22 06:33:13 +0200 oj r272164 : #i99104# export and import calculation-settings and nulldate 2009-05-22 06:27:50 +0200 oj r272163 : #i99104# export and import calculation-settings and nulldate 2009-05-20 13:29:58 +0200 oj r272118 : #i99911# handle invalid name 2009-05-20 13:28:49 +0200 oj r272117 : #i101261# handle different rowsets 2009-05-20 11:29:55 +0200 msc r272111 : #i100000# 2009-05-20 11:28:27 +0200 msc r272110 : merge in change from dba32a 2009-05-20 11:27:38 +0200 msc r272109 : #102082# CTRL + C does not work 2009-05-20 09:43:36 +0200 oj r272106 : clean up includes 2009-05-20 09:32:15 +0200 oj r272105 : #i99060# merge error resovled now VERTICAL_ALIGN is in both stmt 2009-05-20 08:37:21 +0200 msc r272104 : add workaround for issue #102010# 2009-05-20 08:10:12 +0200 oj r272103 : #i99104# use numberformatkey 2009-05-20 08:07:02 +0200 oj r272102 : #i99104# use column info from rowset 2009-05-20 08:04:43 +0200 oj r272101 : #i102032# use a special column type where prec and scale are the values currently set at the column 2009-05-20 08:03:04 +0200 oj r272100 : #i102032# correct type info, we have to use SQL defined type names 2009-05-19 10:27:02 +0200 oj r272061 : #i99104# export null-date 2009-05-19 08:26:53 +0200 oj r272056 : #i99104# export null-date 2009-05-18 13:15:10 +0200 msc r272014 : add issue #102019# 2009-05-18 11:33:07 +0200 msc r272005 : add issue #102019# 2009-05-18 08:59:45 +0200 msc r271996 : add workaroud for issue #102010# 2009-05-15 10:21:24 +0200 msc r271929 : #101944# 2009-05-11 21:18:30 +0200 fs r271792 : #i99914# 2009-05-08 13:52:06 +0200 oj r271715 : #i96423# remember column span 2009-05-08 11:26:19 +0200 oj r271708 : #i98605# impl new scale mode 2009-05-08 10:33:35 +0200 fs r271706 : SendUserCall: only call into the shape notification routine for UserCall types where this is necessary (performance issue) 2009-05-07 20:52:44 +0200 fs r271698 : outsource ShapeProperty from shapepropertynotifier.hxx 2009-05-07 20:43:33 +0200 fs r271697 : #i99056# use notifyShapePropertyChange, instead of getShapePropertyChangeNotifier - the latter throws if no shape exists, yet 2009-05-07 20:33:58 +0200 fs r271696 : #i99056# +notifyShapePropertyChange: allow notifying chages without checking whether there actually already exists an SvxShape 2009-05-07 16:22:15 +0200 fs r271679 : #i10000# cygwin needs quotes around the classpath 2009-05-07 16:21:37 +0200 fs r271678 : #i10000# cygwin needs quotes around the classpath 2009-05-07 16:01:11 +0200 oj r271677 : #i99914# notify parent handler 2009-05-07 15:54:54 +0200 fs r271676 : #i10000# cygwin needs some quoting 2009-05-07 14:49:48 +0200 oj r271672 : #i99277# quote alias name 2009-05-07 14:48:12 +0200 oj r271671 : #i92538# add ~ in front of type 2009-05-07 14:37:13 +0200 oj r271667 : #i99118# change type from char to varchar 2009-05-07 14:36:23 +0200 oj r271666 : #i99118# clear dest columns when changing to create new table 2009-05-07 13:35:32 +0200 oj r271657 : #i94467# handle type 0 as double as well 2009-05-07 13:20:49 +0200 oj r271655 : i99743# setNull when varchar is no text 2009-05-07 12:58:06 +0200 fs r271651 : initialize the SdrObject's property change notifier after the ctor, if necessary 2009-05-07 11:47:18 +0200 fs r271647 : #i10000# 2009-05-07 10:57:16 +0200 fs r271639 : OPropertyBrowserController::propertyChange: care for the current property state, too, and properly forward it to the UI 2009-05-07 10:18:14 +0200 fs r271636 : onNewComponent: do not ask the map for grid columns, it will throw 2009-05-07 10:09:55 +0200 fs r271634 : #i101623# 2009-05-07 09:53:44 +0200 fs r271631 : #i101622# 2009-05-06 21:55:53 +0200 fs r271615 : #i10000# 2009-05-06 21:10:42 +0200 fs r271611 : #i10000# 2009-05-06 13:11:48 +0200 fs r271583 : #i10000# 2009-05-05 22:29:31 +0200 fs r271559 : proper assertion message 2009-05-05 22:29:03 +0200 fs r271558 : diagnostics 2009-05-05 22:16:16 +0200 fs r271557 : #i10000# 2009-05-05 13:50:32 +0200 fs r271513 : #i10000# 2009-05-05 10:21:50 +0200 fs r271503 : #i10000# 2009-05-05 09:30:26 +0200 fs r271501 : why did those survive the rebase -C step? 2009-05-05 09:18:12 +0200 fs r271500 : #i10000# 2009-05-04 17:08:17 +0200 fs r271475 : CWS-TOOLING: rebase CWS dba32b to trunk@271427 (milestone: DEV300:m47) 2009-05-04 14:51:26 +0200 fs r271456 : line ends 2009-04-30 15:55:27 +0200 fs r271418 : NewURL -> PublicConnectionURL 2009-04-22 21:18:34 +0200 fs r271141 : #i100944# 2009-04-22 09:12:26 +0200 oj r271071 : #i101261# little code change 2009-04-22 09:11:43 +0200 oj r271070 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:11:25 +0200 oj r271069 : #i101261# new grabage container for nodes 2009-04-22 09:11:02 +0200 oj r271068 : #i101261# new grabage container for nodes 2009-04-22 09:10:44 +0200 oj r271067 : #i101261# new grabage container for nodes 2009-04-22 09:10:21 +0200 oj r271066 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:08:24 +0200 oj r271065 : #i101261# only ask for parameters which aren't set before 2009-04-22 09:07:25 +0200 oj r271064 : #i101261# only ask for parameters which aren't set before 2009-04-22 08:49:07 +0200 oj r271062 : #i77501# preview only when needed 2009-04-22 08:45:44 +0200 oj r271061 : #i101261# new prop max rows 2009-04-22 08:44:18 +0200 oj r271060 : #i101261# create dataprovider earlier to avoid the wrong legend in chart 2009-04-22 08:42:48 +0200 oj r271059 : #i101261# handle parameter 2009-04-17 21:00:23 +0200 fs r270954 : #i98350# 2009-04-17 13:54:19 +0200 fs r270942 : #i99565# 2009-04-17 13:51:34 +0200 fs r270940 : #i101153# only localize the (potentially) localizable properties when there really is support at the control model 2009-04-17 11:43:14 +0200 fs r270932 : removed superfluous include 2009-04-17 10:10:15 +0200 fs r270926 : #i10000# 2009-04-17 10:02:36 +0200 fs r270925 : #i10000# 2009-04-17 09:15:13 +0200 fs r270918 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 09:14:56 +0200 fs r270917 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 09:13:25 +0200 fs r270915 : #i99056# some more refactoring of the recently introduced property change notification mechanism for UNO shapes 2009-04-17 08:30:34 +0200 fs r270914 : removed unotools/servicehelper.hxx in favour of the (duplicated) comphelper/servicehelper.hxx 2009-04-16 21:05:25 +0200 fs r270903 : #i10000# 2009-04-16 20:43:43 +0200 fs r270902 : #i99056# shape notification outsourced to the SdrObject, this is what all other shape implementations (which only aggregate an SvxShape) have access to, too 2009-04-16 15:57:36 +0200 fs r270891 : #i99056# make SetUnoControlModel virtual 2009-04-16 15:44:02 +0200 fs r270890 : #i99056# let the ScShapeObj notify changes in its Anchor property 2009-04-16 15:36:47 +0200 fs r270889 : #i99056# enable the sheet anchor type property, too 2009-04-16 15:33:45 +0200 fs r270887 : #i99056# shape notification outsourced to the SdrObject, this is what all other shape implementations (which only aggregate an SvxShape) have access to, too 2009-04-15 14:53:13 +0200 fs r270844 : #i10000# 2009-04-15 13:08:29 +0200 fs r270836 : #i10000# 2009-04-15 12:28:14 +0200 fs r270832 : #i10000# 2009-04-15 10:59:14 +0200 fs r270827 : #i10000# 2009-04-15 09:41:08 +0200 oj r270823 : fix issues found with findbugs and pmd 2009-04-14 21:08:04 +0200 fs r270808 : #i99056# implement SheetAnchorType - now the only thing missing to enable it is the proper notification when it is modified 2009-04-14 17:09:00 +0200 fs r270799 : #i99056# implement XServiceInfo for the ScShapeObj 2009-04-14 17:07:55 +0200 fs r270798 : #i99056# implement TextAnchorType, partially implement SheetAnchorType 2009-04-14 15:54:05 +0200 fs r270786 : #i99056# SwXShape: notify changes of the AnchorType property 2009-04-14 15:47:32 +0200 fs r270785 : #i99056# deliver shapepropertynotifier.hxx 2009-04-14 15:46:54 +0200 fs r270784 : diagnostics 2009-04-14 15:08:28 +0200 fs r270781 : #i99056# outsourced the SvxShape's property change notification code into a dedicated class 2009-04-14 14:41:09 +0200 fs r270773 : #i99056# outsourced the SvxShape's property change notification code into a dedicated class 2009-04-14 14:37:23 +0200 fs r270772 : in dtor, remove the properties from the temporary component context 2009-04-14 14:36:34 +0200 fs r270771 : getWeakUnoShape made const 2009-04-14 12:23:08 +0200 oj r270757 : #i101064# add missing braces 2009-04-14 12:21:25 +0200 oj r270756 : #i101065# add braces for gcc 4.3.2 2009-04-14 12:17:45 +0200 oj r270755 : #i101059# add dep for manifest 2009-04-09 12:06:58 +0200 oj r270686 : #i93100# use OptimalSize from control to get height 2009-04-08 09:56:55 +0200 oj r270619 : #i92537# handle calculations in the select columns as well 2009-04-08 09:30:39 +0200 oj r270615 : #i96657# throw error message when the key doesn't have any columns 2009-04-07 12:08:26 +0200 oj r270592 : #i77501# impl preview of the executed report 2009-04-07 12:01:56 +0200 oj r270591 : #i77501# impl preview of the executed report 2009-04-07 11:41:03 +0200 oj r270590 : #i77501# impl preview of the executed report 2009-04-07 11:39:32 +0200 oj r270589 : #i77501# impl preview of the executed report 2009-04-07 11:29:25 +0200 oj r270588 : #i77501# convert dos to unix lineends 2009-04-07 11:28:23 +0200 oj r270587 : #i77501# impl preview of the executed report 2009-04-07 11:16:50 +0200 oj r270586 : #i77501# impl preview of the executed report 2009-04-07 11:16:00 +0200 oj r270585 : #i77501# impl preview of the executed report 2009-04-07 11:15:44 +0200 oj r270584 : #i77501# impl preview of the executed report 2009-04-07 11:15:28 +0200 oj r270583 : #i77501# impl preview of the executed report 2009-04-07 11:15:04 +0200 oj r270582 : #i77501# impl preview of the executed report 2009-04-06 15:38:54 +0200 fs r270559 : merge changes from CWS dba32a herein 2009-04-03 15:56:16 +0200 fs r270494 : ImpSvMEdit::Resize: do multiple iterations, if necessary 2009-04-03 14:35:49 +0200 fs r270487 : #i10000# 2009-04-03 13:17:16 +0200 fs r270476 : #i99056# display geometry information for controls, too 2009-04-03 13:16:37 +0200 fs r270475 : #i99056# better ordering of the geometry properties 2009-04-03 13:16:07 +0200 fs r270473 : #i99056# now that SvxShape supports property change listeners, forward add/remove requests to it 2009-04-03 13:13:18 +0200 fs r270472 : #i99056# at SvxShape, allow for PropertyChangeListeners for Size/Position 2009-04-03 09:29:27 +0200 oj r270456 : #i94571# use correct prop name 2009-04-03 09:14:54 +0200 fs r270451 : merge changes from CWS dba32a herein 2009-04-02 17:00:51 +0200 fs r270424 : better diagnostics 2009-04-02 16:35:19 +0200 fs r270421 : diagnostics 2009-04-02 16:34:50 +0200 fs r270420 : #i99056# mxUnoShape not accessible anymore, use impl_setUnoShape instead 2009-04-02 16:32:48 +0200 fs r270419 : #i99056# make getUnoShape cheaper: keep the pointer to the SvxShape all the time, so there's no need to ask for it in getUnoShape. As a consequence, we will later be able to use the pointer in scenarious where performance (potentially) matters 2009-04-02 16:31:13 +0200 fs r270417 : merge changes from CWS dba32a herein 2009-04-02 16:23:16 +0200 fs r270414 : merge changes from CWS dba32a herein 2009-04-02 14:10:35 +0200 fs r270405 : #i10000# 2009-04-02 14:06:26 +0200 fs r270404 : merge changes from CWS dba32a herein 2009-04-02 14:03:03 +0200 fs r270401 : #i10000# 2009-04-02 13:58:13 +0200 fs r270400 : #i10000# 2009-04-02 12:59:44 +0200 fs r270397 : merge changes from CWS dba32a herein 2009-04-02 12:46:30 +0200 fs r270396 : #i99056# let the form page maintain a mapping between control models and control shapes 2009-04-02 12:44:07 +0200 fs r270395 : merge changes from CWS dba32a herein 2009-04-02 12:42:06 +0200 fs r270394 : merge changes from CWS dba32a herein 2009-04-02 12:35:20 +0200 fs r270393 : #i10000# precompiled header 2009-04-02 12:05:31 +0200 fs r270392 : merge changes from CWS dba32a herein 2009-04-02 12:00:42 +0200 fs r270391 : merge changes from CWS dba32a herein 2009-04-02 11:47:26 +0200 fs r270390 : merge changes from CWS dba32a herein 2009-04-02 11:39:15 +0200 oj r270389 : #i94467# foxpro impl several new types 2009-04-02 11:35:58 +0200 fs r270387 : merge changes from CWS dba32a herein 2009-04-01 14:10:51 +0200 fs r270329 : merge changes from CWS dba32a herein 2009-03-31 17:29:50 +0200 fs r270290 : merge changes from CWS dba32a herein 2009-03-30 14:53:56 +0200 fs r270233 : #i100417# don't set grid column widths to 0, but to <void/> 2009-03-30 12:31:03 +0200 oj r270213 : #i100552# wrong orb used 2009-03-30 12:19:20 +0200 oj r270212 : #i98303# convertlike corrected to sal_Unicode 2009-03-30 11:58:25 +0200 fs r270210 : merge changes from CWS dba32a herein 2009-03-30 11:38:16 +0200 oj r270205 : remove duplicate code from merge 2009-03-30 11:02:27 +0200 fs r270202 : merge changes from CWS dba32a herein 2009-03-30 11:02:19 +0200 fs r270201 : merge changes from CWS dba32a herein 2009-03-30 10:31:26 +0200 oj r270200 : #i100665# only throw exception and do not drop table 2009-03-30 09:36:24 +0200 fs r270195 : assertion text 2009-03-28 20:21:58 +0100 fs r270187 : #ii10000# 2009-03-28 20:19:54 +0100 fs r270186 : removed unused help ids 2009-03-28 20:19:40 +0100 fs r270185 : removed unused help ids 2009-03-28 20:19:10 +0100 fs r270184 : #i100237# +DefaultState/XReset 2009-03-28 00:29:29 +0100 fs r270177 : CWS-TOOLING: rebase CWS dba32b to trunk@270033 (milestone: DEV300:m45) 2009-03-27 22:56:46 +0100 fs r270173 : #i100237# DEFAULT_CHECKED -> DEFAULT_STATE 2009-03-27 22:55:52 +0100 fs r270172 : #i100237# DefaultState property for buttons, enabled only when Toggle=Yes 2009-03-27 22:54:15 +0100 fs r270171 : #i100237# DEFAULT_CHECKED -> DEFAULT_STATE 2009-03-27 22:53:54 +0100 fs r270170 : #i100237# introduce a DefaultState property for buttons, which implies buttongs supporting XReset, which needed some refactoring 2009-03-27 13:31:41 +0100 fs r270152 : ignore output paths 2009-03-27 11:23:44 +0100 fs r270139 : tuned behavior with respect to invalid keys/values 2009-03-27 09:57:14 +0100 fs r270136 : don't allow Double.NaN 2009-03-27 09:56:16 +0100 fs r270135 : talk about Double.NaN 2009-03-26 12:14:30 +0100 fs r270067 : removed unused parameter 2009-03-26 12:14:02 +0100 fs r270066 : removed widening conversion when checking keys 2009-03-26 09:17:34 +0100 fs r270053 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-26 09:17:11 +0100 fs r270052 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-26 09:16:49 +0100 fs r270051 : separated the enumerator functionality into a dedicated interface, this way not burdening XMap with it 2009-03-25 21:55:20 +0100 fs r270044 : #i100541# properly calculat bNeedScrollBox 2009-03-25 12:56:17 +0100 fs r270019 : renamed the previously introduced error condition 2009-03-25 12:11:48 +0100 fs r270015 : #i100095# when the error messages contain non-trivial details (SQLState/ErrorCode), then always display the 'Details' button 2009-03-25 12:10:05 +0100 fs r270012 : renamed the previously introduced error condition 2009-03-25 12:01:04 +0100 fs r270011 : #i100095# when no address book (or respective profile) can be found, then use a dedicated ErrorCondition 2009-03-25 10:29:07 +0100 fs r270003 : add missing localization 2009-03-25 10:23:12 +0100 fs r270001 : in preparation of #i1000095#: rework the error handling, allow using css.sdb.ErrorCondition values, plus allow propagating the nsresult 2009-03-25 10:21:55 +0100 fs r270000 : in preparation of #i1000095#: rework the error handling, allow using css.sdb.ErrorCondition values, plus allow propagating the nsresult 2009-03-20 23:05:38 +0100 fs r269829 : XMap::getSize removed 2009-03-20 23:05:19 +0100 fs r269828 : changes as suggested by sb 2009-03-20 23:04:56 +0100 fs r269827 : enhanced documentation 2009-03-20 15:31:40 +0100 fs r269815 : changes as suggested by sb 2009-03-20 13:23:52 +0100 oj r269804 : #i92538# correct the zorder that fixedtext is infront of control 2009-03-20 12:59:38 +0100 oj r269801 : #i94571# paraadjust now supports BLOCK 2009-03-20 12:58:11 +0100 oj r269800 : #i94571# export style with data style 2009-03-20 12:57:05 +0100 oj r269799 : #i94571# text align is now paraadjust 2009-03-20 12:37:02 +0100 fs r269797 : enum keys only accepted if they have the exact type, not if they have *any* enum type 2009-03-20 12:28:31 +0100 fs r269794 : some changes requested by sb 2009-03-20 08:52:47 +0100 fs r269780 : doc 2009-03-20 07:37:31 +0100 oj r269779 : #i99913# only notifiy when values are different 2009-03-20 07:36:58 +0100 oj r269778 : #i99913# add undoenv as listener at the dataprovider 2009-03-19 22:52:52 +0100 fs r269771 : added comment 2009-03-19 22:40:06 +0100 fs r269770 : +testEnumeration 2009-03-19 22:39:41 +0100 fs r269769 : implemented enumeration, getKeySet, and getValues. Should be finished now. 2009-03-19 14:01:01 +0100 oj r269743 : #i99913# reset the modified state when selecting an object 2009-03-19 12:19:54 +0100 lla r269739 : #i72390# cleanups 2009-03-19 09:25:27 +0100 fs r269727 : #i10000# 2009-03-18 23:37:02 +0100 fs r269708 : extended checks for value type acceptance 2009-03-18 23:36:41 +0100 fs r269707 : fixed value type checks 2009-03-18 14:59:56 +0100 fs r269678 : initial complex test case for the new css.container.Map implementation 2009-03-18 14:59:24 +0100 fs r269677 : verifyExpectedException moved to base class (in complexlib), and renamed to assureException for consistency 2009-03-18 14:58:35 +0100 fs r269676 : removed unused imports 2009-03-18 14:58:03 +0100 fs r269675 : first implementation of the new css.container.Map service (not completed, yet) 2009-03-18 14:57:17 +0100 fs r269674 : base class for UNO components, freeing you from some repeating work 2009-03-18 14:55:53 +0100 fs r269672 : +assureException: call a given method with given parameters on a given object, ensure that a given exception is thrown by the method implementation 2009-03-18 14:54:58 +0100 fs r269671 : +getComponentContext 2009-03-18 14:54:00 +0100 fs r269670 : isEmpty returns a boolean, not a long 2009-03-18 14:14:43 +0100 oj r269663 : #i99743# now text also supports null 2009-03-18 13:54:14 +0100 oj r269660 : #i99223# remove check for 2 params 2009-03-18 13:33:35 +0100 oj r269659 : #i99060# replace text::ParagraphVertAlign with style::VerticalAlignment 2009-03-18 13:32:18 +0100 oj r269658 : #i99060# don't set void property when void isn't allowed 2009-03-18 13:31:11 +0100 oj r269657 : #i99060# handle vertical alignment 2009-03-18 13:28:28 +0100 oj r269656 : #i99060# remove unused elements from sytle 2009-03-18 09:35:42 +0100 lla r269639 : #i72390# cleanups 2009-03-18 09:31:20 +0100 lla r269638 : #i72390# add ButtonList 2009-03-18 09:30:46 +0100 lla r269637 : #i72390# renamed interface 2009-03-18 09:30:15 +0100 lla r269636 : #i72390# use ButtonList instead of ImageList 2009-03-18 09:29:05 +0100 lla r269635 : #i72390# new ButtonList, cleanups 2009-03-18 09:26:34 +0100 lla r269634 : #i72390# cleanups 2009-03-17 12:21:20 +0100 oj r269590 : #i99222# remove assertion 2009-03-17 12:17:22 +0100 oj r269589 : #i98605# impl scale mode 2009-03-17 12:10:42 +0100 oj r269588 : #i98605# impl scale mode 2009-03-17 11:40:15 +0100 oj r269584 : #i96944# doesn't create equation for shapes 2009-03-17 11:33:16 +0100 oj r269583 : #i96423# switch calc from float to long 2009-03-16 15:19:18 +0100 fs r269550 : #i41930# enable zoom for embedded/outplace documents 2009-03-16 14:25:54 +0100 oj r269542 : #i93734# remove ContextSensitive 2009-03-16 14:21:58 +0100 oj r269541 : #i99274# page header before group header 2009-03-16 14:18:23 +0100 oj r269539 : #i99110# fix value type 2009-03-16 14:14:16 +0100 fs r269537 : line ends 2009-03-16 14:11:06 +0100 fs r269535 : line ends 2009-03-16 14:08:34 +0100 fs r269534 : #i100087# (provided my np): allow for polymorphic types with more than one parameter 2009-03-16 12:30:31 +0100 oj r269521 : compile error 2009-03-16 12:19:12 +0100 oj r269519 : compile error 2009-03-16 10:39:28 +0100 oj r269511 : compile error under linux with swap 2009-03-13 10:33:04 +0100 oj r269462 : CWS-TOOLING: rebase CWS dba32b to trunk@269297 (milestone: DEV300:m43) 2009-03-12 14:37:25 +0100 fs r269416 : interface SequenceOutputStreamTest is unneeded, and pollutes the namespace here :) 2009-03-12 14:35:07 +0100 fs r269414 : not needed 2009-03-12 14:34:15 +0100 fs r269413 : preparation for multiple tests in this module 2009-03-12 14:33:02 +0100 fs r269412 : ShowTargets was moved from module integration.forms to module complexlib 2009-03-12 14:32:48 +0100 fs r269411 : helper class for projects containing multiple complex test cases (and following a certain structure) 2009-03-12 14:00:14 +0100 fs r269407 : proper module after the move 2009-03-12 13:59:10 +0100 fs r269406 : superseded by ../makefile.mk 2009-03-12 13:47:38 +0100 fs r269403 : not needed anymore 2009-03-12 13:45:46 +0100 fs r269402 : moved, in preparation of adding more test cases here, with a common infrastructure 2009-03-12 13:45:07 +0100 fs r269401 : moved from ../ 2009-03-12 13:43:59 +0100 fs r269400 : moved to ./comphelper, in preparation of adding more test cases here, with a common infrastructure 2009-03-12 13:29:47 +0100 oj r269396 : #i99914# set parent on dataprovider 2009-03-12 13:10:35 +0100 oj r269393 : #i99832# check thrown exception and show error 2009-03-12 13:08:10 +0100 fs r269392 : reorganizing tests 2009-03-12 12:52:55 +0100 oj r269390 : #i99118# convert formatkey in numberformat 2009-03-12 12:34:53 +0100 fs r269388 : new API tests 2009-03-12 12:29:05 +0100 fs r269386 : Map not yet committed 2009-03-12 12:28:36 +0100 fs r269385 : oops, forgot the SequenceInputStream during the previous refactoring 2009-03-12 12:12:39 +0100 oj r269384 : #i99104# set HasCategories prop 2009-03-12 12:12:08 +0100 oj r269383 : #i99104# check HasCategories even for internal dataprovider 2009-03-12 12:10:40 +0100 oj r269382 : #i99104# set HasCategories prop 2009-03-12 10:51:49 +0100 fs r269373 : #i10000# exception specifications 2009-03-12 10:49:18 +0100 fs r269372 : #i10000# exception specifications 2009-03-12 10:44:02 +0100 fs r269371 : #i10000# exception specifications 2009-03-12 10:30:55 +0100 fs r269368 : refactored the UNO service registration in this module, using the helper classes provided by comphelper itself, so you have less effort when extending the list of to-be-registered components 2009-03-12 10:30:37 +0100 fs r269367 : module-local includes 2009-03-12 07:05:54 +0100 oj r269357 : #i99104# database dataprovider doesn't need dataranges and diagramdata 2009-03-11 10:58:28 +0100 oj r269306 : #i99911# check if name of the report is a valid file name 2009-03-11 10:03:23 +0100 oj r269299 : #i99666# the report is new when the HierarchicalDocumentName is empty 2009-03-10 11:32:45 +0100 oj r269258 : #i99221# use fallback for language 2009-03-10 10:48:40 +0100 oj r269255 : #i99433# now use OStringBuffer 2009-03-10 10:36:21 +0100 fs r269252 : initial version of (X)Map 2009-03-10 09:52:23 +0100 oj r269246 : #i99433# now use OStringBuffer 2009-03-10 08:56:13 +0100 oj r269240 : #i99655# patch applied 2009-03-09 07:35:33 +0100 lla r269058 : #i10000# wrong variable assignment fixed 2009-03-06 17:20:40 +0100 fs r269030 : some explicit defaults 2009-03-06 17:20:30 +0100 fs r269029 : #i98600# 2009-03-06 14:40:34 +0100 fs r269009 : #i87692# during reload, prevent the document being modified just because of some control content changes ... 2009-03-06 12:52:20 +0100 lla r268997 : #i10000# ambigous problem with FontWeight fixed 2009-03-06 11:39:32 +0100 fs r268989 : #i10000# (approved by pl): use --without-t1-library configure option 2009-03-06 10:55:43 +0100 fs r268986 : #i99953# depends on xmlscript module now 2009-03-06 10:54:04 +0100 fs r268985 : #i99953# also adjust the event names found in dialogs embedded in the forms 2009-03-06 09:53:41 +0100 fs r268977 : #i10000# 2009-03-06 09:30:41 +0100 lla r268973 : #i10000# merge problems 2009-03-05 17:52:34 +0100 fs r268932 : #i98593# for sub components which are actually controlled by a DocumentDefinition (aka XComponentSupplier aka XCommandProcessor), close them by executing the 'close' command, not by suspending/closing the controller (which cannot be intercepted) 2009-03-05 11:41:56 +0100 fs r268889 : default the drop down line count for list/combo boxes to 20 2009-03-05 11:39:10 +0100 fs r268887 : do not display empty error messages 2009-03-02 10:13:57 +0100 lla r268639 : #i91541# CWS rebase m41 to m42 2009-03-02 09:06:27 +0100 lla r268635 : #i10000# add ';' to strings 2009-02-26 11:18:00 +0100 fs r268492 : reportdesign depends on REPORTBUILDER, not REPORTDESIGN 2009-02-26 10:11:38 +0100 lla r268489 : CWS-TOOLING: rebase CWS dba32b to trunk@268395 (milestone: DEV300:m42) 2009-02-26 09:04:11 +0100 lla r268488 : CWS-TOOLING: rebase CWS dba32b to trunk@268395 (milestone: DEV300:m42) 2009-02-24 12:09:13 +0100 lla r268392 : #i91541# #i91542# cleanups 2009-02-24 08:08:06 +0100 lla r268382 : merge all dba32a changes into dba32b 2009-02-24 07:14:55 +0100 lla r268381 : merge all dba32a changes into dba32b 2009-02-23 21:44:28 +0100 fs r268377 : oops ... don't tamper with m_aListSourceValues at the end of loadData 2009-02-23 20:57:05 +0100 fs r268376 : #i98162# don't hold the values as strings, but as ORowSetValue, this way preserving their type, and being agnostic to different result/rowset implementations doing different to-string-conversations 2009-02-23 20:55:44 +0100 fs r268375 : getObject: throwFunctionNotSupportedException, instead of silently returning NULL 2009-02-23 20:55:20 +0100 fs r268374 : #i98162# some more supported types 2009-02-23 20:54:43 +0100 fs r268373 : #i98162# +operator != 2009-02-20 09:35:39 +0100 fs r268306 : #i99422# for a font, display the font name, the style, and the size 2009-02-20 09:33:45 +0100 fs r268305 : #i99422# in the property browser, FONT supersedes CHARFONTNAME: the aggregated FormComponentHandler displays them more nicely now 2009-02-19 16:12:06 +0100 fs r268293 : #i99372# recognize DataType::FLOAT as numeric 2009-02-19 15:43:12 +0100 fs r268291 : #i99415# 2009-02-19 15:40:15 +0100 fs r268290 : #i99242# lcl_firstFocussableControl: take disabled controls into account 2009-02-19 15:34:36 +0100 fs r268289 : #i99396# properly decode the base name of the URL when using it as title 2009-02-19 15:19:05 +0100 fs r268287 : #i98247#
2009-06-05 09:47:55 +00:00
getPropertyBox().SetPropertyValue( rName, aNormalizedValue, false );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
2011-12-10 22:14:57 +09:00
catch(const Exception&)
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
{
2011-03-01 17:55:09 +01:00
OSL_FAIL("OPropertyBrowserController::Commit : caught an exception !");
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
m_sCommittingProperty = ::rtl::OUString();
}
//--------------------------------------------------------------------
namespace
{
}
//--------------------------------------------------------------------
void OPropertyBrowserController::focusGained( const Reference< XPropertyControl >& _Control )
{
m_aControlObservers.notifyEach( &XPropertyControlObserver::focusGained, _Control );
}
//--------------------------------------------------------------------
void OPropertyBrowserController::valueChanged( const Reference< XPropertyControl >& _Control )
{
m_aControlObservers.notifyEach( &XPropertyControlObserver::valueChanged, _Control );
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
//------------------------------------------------------------------------
namespace
{
Reference< XPropertyHandler > lcl_createHandler( const ComponentContext& _rContext, const Any& _rFactoryDescriptor )
{
Reference< XPropertyHandler > xHandler;
::rtl::OUString sServiceName;
Reference< XSingleServiceFactory > xServiceFac;
Reference< XSingleComponentFactory > xComponentFac;
if ( _rFactoryDescriptor >>= sServiceName )
_rContext.createComponent( sServiceName, xHandler );
else if ( _rFactoryDescriptor >>= xServiceFac )
xHandler = xHandler.query( xServiceFac->createInstance() );
else if ( _rFactoryDescriptor >>= xComponentFac )
xHandler = xHandler.query( xComponentFac->createInstanceWithContext( _rContext.getUNOContext() ) );
OSL_ENSURE(xHandler.is(),"lcl_createHandler: Can not create handler");
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
return xHandler;
}
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
//------------------------------------------------------------------------
void OPropertyBrowserController::getPropertyHandlers( const InterfaceArray& _rObjects, PropertyHandlerArray& _rHandlers )
{
_rHandlers.resize( 0 );
if ( _rObjects.empty() )
return;
// create a component context for the handlers, containing some information about where
// they live
Reference< XComponentContext > xHandlerContext( m_aContext.getUNOContext() );
// if our own creator did not pass a dialog parent window, use our own view for this
Reference< XWindow > xParentWindow( m_aContext.getContextValueByAsciiName( "DialogParentWindow" ), UNO_QUERY );
if ( !xParentWindow.is() )
{
::cppu::ContextEntry_Init aHandlerContextInfo[] =
{
::cppu::ContextEntry_Init( ::rtl::OUString( "DialogParentWindow" ), makeAny( VCLUnoHelper::GetInterface( m_pView ) ) )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
};
xHandlerContext = ::cppu::createComponentContext(
2010-10-15 18:15:35 +01:00
aHandlerContextInfo, SAL_N_ELEMENTS( aHandlerContextInfo ),
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
m_aContext.getUNOContext() );
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
Sequence< Any > aHandlerFactories;
if ( m_xModel.is() )
aHandlerFactories = m_xModel->getHandlerFactories();
const Any* pHandlerFactory = aHandlerFactories.getConstArray();
const Any* pHandlerFactoryEnd = aHandlerFactories.getConstArray() + aHandlerFactories.getLength();
while ( pHandlerFactory != pHandlerFactoryEnd )
{
if ( _rObjects.size() == 1 )
{ // we're inspecting only one object -> one handler
Reference< XPropertyHandler > xHandler( lcl_createHandler( m_aContext, *pHandlerFactory ) );
if ( xHandler.is() )
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
xHandler->inspect( _rObjects[0] );
_rHandlers.push_back( xHandler );
}
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
else
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// create a single handler for every single object
::std::vector< Reference< XPropertyHandler > > aSingleHandlers( _rObjects.size() );
::std::vector< Reference< XPropertyHandler > >::iterator pHandler = aSingleHandlers.begin();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
InterfaceArray::const_iterator pObject = _rObjects.begin();
InterfaceArray::const_iterator pObjectEnd = _rObjects.end();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
for ( ; pObject != pObjectEnd; ++pObject )
{
*pHandler = lcl_createHandler( m_aContext, *pHandlerFactory );
if ( pHandler->is() )
{
(*pHandler)->inspect( *pObject );
++pHandler;
}
}
aSingleHandlers.resize( pHandler - aSingleHandlers.begin() );
2001-02-05 07:58:27 +00:00
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// then create a handler which composes information out of those single handlers
if ( !aSingleHandlers.empty() )
_rHandlers.push_back( new PropertyComposer( aSingleHandlers ) );
}
++pHandlerFactory;
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
// note that the handlers will not be used by our caller, if they indicate that there are no
// properties they feel responsible for
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
//------------------------------------------------------------------------
bool OPropertyBrowserController::impl_findObjectProperty_nothrow( const ::rtl::OUString& _rName, OrderedPropertyMap::const_iterator* _pProperty )
{
OrderedPropertyMap::const_iterator search = m_aProperties.begin();
for ( ; search != m_aProperties.end(); ++search )
if ( search->second.Name == _rName )
break;
if ( _pProperty )
*_pProperty = search;
return ( search != m_aProperties.end() );
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
void OPropertyBrowserController::rebuildPropertyUI( const ::rtl::OUString& _rPropertyName ) throw (RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
::osl::MutexGuard aGuard( m_aMutex );
if ( !haveView() )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
throw RuntimeException();
OrderedPropertyMap::const_iterator propertyPos;
if ( !impl_findObjectProperty_nothrow( _rPropertyName, &propertyPos ) )
return;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
OLineDescriptor aDescriptor;
try
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
describePropertyLine( propertyPos->second, aDescriptor );
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
catch( const Exception& )
{
OSL_FAIL( "OPropertyBrowserController::rebuildPropertyUI: caught an exception!" );
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
getPropertyBox().ChangeEntry( aDescriptor );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
void OPropertyBrowserController::enablePropertyUI( const ::rtl::OUString& _rPropertyName, sal_Bool _bEnable ) throw (RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
::osl::MutexGuard aGuard( m_aMutex );
if ( !haveView() )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
throw RuntimeException();
if ( !impl_findObjectProperty_nothrow( _rPropertyName ) )
return;
getPropertyBox().EnablePropertyLine( _rPropertyName, _bEnable );
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
void OPropertyBrowserController::enablePropertyUIElements( const ::rtl::OUString& _rPropertyName, sal_Int16 _nElements, sal_Bool _bEnable ) throw (RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
::osl::MutexGuard aGuard( m_aMutex );
if ( !haveView() )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
throw RuntimeException();
if ( !impl_findObjectProperty_nothrow( _rPropertyName ) )
return;
getPropertyBox().EnablePropertyControls( _rPropertyName, _nElements, _bEnable );
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
void OPropertyBrowserController::showPropertyUI( const ::rtl::OUString& _rPropertyName ) throw (RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
::osl::MutexGuard aGuard( m_aMutex );
if ( !haveView() )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
throw RuntimeException();
// look up the property in our object properties
OrderedPropertyMap::const_iterator propertyPos;
if ( !impl_findObjectProperty_nothrow( _rPropertyName, &propertyPos ) )
return;
if ( getPropertyBox().GetPropertyPos( _rPropertyName ) != LISTBOX_ENTRY_NOTFOUND )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
{
rebuildPropertyUI( _rPropertyName );
return;
}
OLineDescriptor aDescriptor;
describePropertyLine( propertyPos->second, aDescriptor );
// look for the position to insert the property
// side note: The methods GetPropertyPos and InsertEntry of the OPropertyEditor work
// only on the current page. This implies that it's impossible to use this method here
// to show property lines which are *not* on the current page.
// This is sufficient for now, but should be changed in the future.
// by definition, the properties in m_aProperties are in the order in which they appear in the UI
// So all we need is a predecessor of pProperty in m_aProperties
sal_uInt16 nUIPos = LISTBOX_ENTRY_NOTFOUND;
do
{
if ( propertyPos != m_aProperties.begin() )
--propertyPos;
nUIPos = getPropertyBox().GetPropertyPos( propertyPos->second.Name );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
while ( ( nUIPos == LISTBOX_ENTRY_NOTFOUND ) && ( propertyPos != m_aProperties.begin() ) );
if ( nUIPos == LISTBOX_ENTRY_NOTFOUND )
// insert at the very top
nUIPos = 0;
else
// insert right after the predecessor we found
++nUIPos;
getPropertyBox().InsertEntry(
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
aDescriptor, impl_getPageIdForCategory_nothrow( aDescriptor.Category ), nUIPos );
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
void OPropertyBrowserController::hidePropertyUI( const ::rtl::OUString& _rPropertyName ) throw (RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
::osl::MutexGuard aGuard( m_aMutex );
if ( !haveView() )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
throw RuntimeException();
if ( !impl_findObjectProperty_nothrow( _rPropertyName ) )
return;
getPropertyBox().RemoveEntry( _rPropertyName );
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
void OPropertyBrowserController::showCategory( const ::rtl::OUString& _rCategory, sal_Bool _bShow ) throw (RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
::osl::MutexGuard aGuard( m_aMutex );
if ( !haveView() )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
throw RuntimeException();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
sal_uInt16 nPageId = impl_getPageIdForCategory_nothrow( _rCategory );
OSL_ENSURE( nPageId != (sal_uInt16)-1, "OPropertyBrowserController::showCategory: invalid category!" );
getPropertyBox().ShowPropertyPage( nPageId, _bShow );
}
//------------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
Reference< XPropertyControl > SAL_CALL OPropertyBrowserController::getPropertyControl( const ::rtl::OUString& _rPropertyName ) throw (RuntimeException)
{
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
::osl::MutexGuard aGuard( m_aMutex );
if ( !haveView() )
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
throw RuntimeException();
Reference< XPropertyControl > xControl( getPropertyBox().GetPropertyControl( _rPropertyName ) );
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
return xControl;
}
//--------------------------------------------------------------------
void SAL_CALL OPropertyBrowserController::registerControlObserver( const Reference< XPropertyControlObserver >& _Observer ) throw (RuntimeException)
{
m_aControlObservers.addInterface( _Observer );
}
//--------------------------------------------------------------------
void SAL_CALL OPropertyBrowserController::revokeControlObserver( const Reference< XPropertyControlObserver >& _Observer ) throw (RuntimeException)
{
m_aControlObservers.removeInterface( _Observer );
}
//------------------------------------------------------------------------
void SAL_CALL OPropertyBrowserController::setHelpSectionText( const ::rtl::OUString& _rHelpText ) throw (NoSupportException, RuntimeException)
{
SolarMutexGuard aSolarGuard;
::osl::MutexGuard aGuard( m_aMutex );
if ( !haveView() )
throw DisposedException();
if ( !getPropertyBox().HasHelpSection() )
throw NoSupportException();
getPropertyBox().SetHelpText( _rHelpText );
}
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
//------------------------------------------------------------------------
void OPropertyBrowserController::impl_broadcastPropertyChange_nothrow( const ::rtl::OUString& _rPropertyName, const Any& _rNewValue, const Any& _rOldValue, bool _bFirstTimeInit ) const
{
// are there one or more handlers which are interested in the actuation?
::std::pair< PropertyHandlerMultiRepository::const_iterator, PropertyHandlerMultiRepository::const_iterator > aInterestedHandlers =
m_aDependencyHandlers.equal_range( _rPropertyName );
if ( aInterestedHandlers.first == aInterestedHandlers.second )
// none of our handlers is interested in this
return;
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
ComposedUIAutoFireGuard aAutoFireGuard( *m_pUIRequestComposer );
try
{
// collect the responses from all interested handlers
PropertyHandlerMultiRepository::const_iterator handler = aInterestedHandlers.first;
while ( handler != aInterestedHandlers.second )
{
handler->second->actuatingPropertyChanged( _rPropertyName, _rNewValue, _rOldValue,
m_pUIRequestComposer->getUIForPropertyHandler( handler->second ),
_bFirstTimeInit );
++handler;
}
}
catch( const Exception& )
{
CWS-TOOLING: integrate CWS dba31e 2008-11-19 12:36:23 +0100 msc r263980 : i96104 2008-11-19 12:31:19 +0100 msc r263979 : i96104 2008-11-19 12:21:55 +0100 msc r263977 : i96104 2008-11-19 12:18:53 +0100 msc r263976 : i96104 2008-11-18 09:09:45 +0100 oj r263746 : disable color entry when area is set 2008-11-18 08:37:52 +0100 oj r263741 : #remove sub report entry 2008-11-17 11:20:25 +0100 fs r263708 : #i10000# 2008-11-17 11:06:52 +0100 fs r263706 : minimal version now is 3.1 2008-11-12 22:25:59 +0100 fs r263621 : #i96150# 2008-11-12 22:20:02 +0100 fs r263620 : rebased to m34 2008-11-12 21:39:41 +0100 fs r263618 : MANUAL REBASE: rebase CWS dba31d to DEV300_m34 2008-11-12 13:54:58 +0100 fs r263597 : #i96134# MediaDescriptor.URL is to be preferred over MediaDescriptor.FileName. Nonetheless, ensure both are handled 2008-11-12 13:53:40 +0100 fs r263596 : #i96134# re-enabled the code for #i41897#, a better fix is to come 2008-11-12 12:48:21 +0100 fs r263585 : #i96134# disable saving URLs of file-base databases relatively 2008-11-11 16:11:11 +0100 msc r263566 : #i96104# 2008-11-05 09:09:47 +0100 oj r263342 : #i88727# color noe added 2008-11-05 08:41:43 +0100 oj r263341 : #i77916# zoom added 2008-11-04 21:24:15 +0100 fs r263339 : disposing: call disposeAndClear without own mutex locked - some of our listeners insist on locking the SolarMutex, which sometimes led to deadlocks on the complex test cases 2008-11-04 21:23:15 +0100 fs r263338 : remove SolarMutex locking - this happned in CWS dba31c (in the CVS version), which this CWS was created from, but seems to got lost during resync 2008-11-04 20:49:50 +0100 fs r263335 : docu formatting 2008-11-04 20:06:39 +0100 fs r263334 : #i95826# use m_aMutex, not a DocumentGuard (wrongly resolved merge conflicts) 2008-11-04 17:36:29 +0100 fs r263332 : #i92688# properly revoke as XEventListener from m_xActiveController when disposing 2008-11-04 14:49:34 +0100 fs r263324 : #i92322# enable Input Required if EmptyIsNULL does not exist at the control 2008-10-31 11:10:04 +0100 oj r262857 : merge from cvs to svn 2008-10-31 09:46:45 +0100 oj r262853 : merge from cvs to svn 2008-10-31 08:46:37 +0100 oj r262849 : merge from cvs to svn 2008-10-31 08:44:24 +0100 oj r262848 : merge from cvs to svn 2008-10-31 08:43:33 +0100 oj r262847 : merge from cvs to svn 2008-10-31 08:42:28 +0100 oj r262846 : merge from cvs to svn 2008-10-31 08:41:58 +0100 oj r262845 : merge from cvs to svn 2008-10-31 08:41:32 +0100 oj r262844 : merge from cvs to svn 2008-10-28 12:19:50 +0100 oj r262733 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:42 +0100 oj r262732 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:36 +0100 oj r262731 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:31 +0100 oj r262730 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:22 +0100 oj r262729 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:18 +0100 oj r262728 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:10 +0100 oj r262727 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:06 +0100 oj r262726 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:05 +0100 oj r262725 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:19:01 +0100 oj r262724 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:50 +0100 oj r262723 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:41 +0100 oj r262722 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:40 +0100 oj r262721 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:27 +0100 oj r262720 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:10 +0100 oj r262719 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:18:01 +0100 oj r262718 : #iXXXXX#: migrate CWS dba31e to SVN 2008-10-28 12:17:39 +0100 oj r262717 : #iXXXXX#: migrate CWS dba31e to SVN
2008-12-01 12:31:27 +00:00
DBG_UNHANDLED_EXCEPTION();
INTEGRATION: CWS pbrwuno (1.28.38); FILE MERGED 2006/03/09 14:31:15 fs 1.28.38.33: #i10000# 2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore 2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page 2006/02/13 07:33:02 fs 1.28.38.30: #i10000# 2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity 2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks 2005/12/19 12:21:17 fs 1.28.38.27: #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/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else 2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one 2005/10/31 13:45:57 fs 1.28.38.24: some cleanup 2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095# 2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property 2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs 2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs 2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string > 2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking 2005/10/17 08:17:01 fs 1.28.38.14: #i53095# 2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect 2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:33 fs 1.28.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:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED 2005/09/05 07:41:52 fs 1.28.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.28.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.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:13 fs 1.28.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:46 fs 1.28.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.28.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:22 +00:00
}
}
//............................................................................
} // namespace pcr
//............................................................................
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */