2010-10-12 15:57:08 +02:00
|
|
|
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
|
2001-01-12 10:35:45 +00:00
|
|
|
/*************************************************************************
|
|
|
|
*
|
2008-04-11 10:15:09 +00:00
|
|
|
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2010-02-12 15:01:35 +01:00
|
|
|
* Copyright 2000, 2010 Oracle and/or its affiliates.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2008-04-11 10:15:09 +00:00
|
|
|
* OpenOffice.org - a multi-platform office productivity suite
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2008-04-11 10:15:09 +00:00
|
|
|
* This file is part of OpenOffice.org.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2008-04-11 10:15:09 +00:00
|
|
|
* 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.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2008-04-11 10:15:09 +00:00
|
|
|
* 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).
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2008-04-11 10:15:09 +00:00
|
|
|
* 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.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
|
|
|
************************************************************************/
|
2006-09-16 12:21:40 +00:00
|
|
|
|
|
|
|
// MARKER(update_precomp.py): autogen include statement, do not remove
|
|
|
|
#include "precompiled_extensions.hxx"
|
2001-01-12 10:35:45 +00:00
|
|
|
#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"
|
2001-01-12 10:35:45 +00:00
|
|
|
#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"
|
|
|
|
|
|
|
|
/** === begin UNO includes === **/
|
2001-01-12 10:35:45 +00:00
|
|
|
#include <com/sun/star/awt/XWindow.hpp>
|
2004-03-19 11:05:33 +00:00
|
|
|
#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>
|
2006-12-13 11:02:06 +00:00
|
|
|
#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
|
|
|
/** === end UNO includes === **/
|
|
|
|
#include <tools/debug.hxx>
|
2006-03-31 11:20:11 +00:00
|
|
|
#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>
|
2001-01-12 10:35:45 +00:00
|
|
|
#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>
|
2006-03-31 11:20:11 +00:00
|
|
|
#include <vcl/svapp.hxx>
|
2010-10-16 03:15:49 -05:00
|
|
|
#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>
|
|
|
|
|
2003-10-21 08:06:34 +00:00
|
|
|
#include <algorithm>
|
2004-09-08 13:05:25 +00:00
|
|
|
#include <functional>
|
2010-10-15 18:15:35 +01:00
|
|
|
#include <sal/macros.h>
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
//------------------------------------------------------------------------
|
|
|
|
// !!! 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;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//............................................................................
|
|
|
|
namespace pcr
|
|
|
|
{
|
|
|
|
//............................................................................
|
|
|
|
|
2001-12-13 08:14:26 +00:00
|
|
|
using namespace ::com::sun::star;
|
2001-01-12 10:35:45 +00:00
|
|
|
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;
|
2003-10-21 08:06:34 +00:00
|
|
|
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;
|
2006-12-13 11:02:06 +00:00
|
|
|
using namespace ::com::sun::star::ucb;
|
2001-01-12 10:35:45 +00:00
|
|
|
using namespace ::comphelper;
|
|
|
|
|
|
|
|
#define THISREF() static_cast< XController* >(this)
|
|
|
|
|
|
|
|
//========================================================================
|
|
|
|
//= OPropertyBrowserController
|
|
|
|
//========================================================================
|
2001-01-18 13:45:10 +00:00
|
|
|
DBG_NAME(OPropertyBrowserController)
|
2001-01-12 10:35:45 +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
|
|
|
OPropertyBrowserController::OPropertyBrowserController( const Reference< XComponentContext >& _rxContext )
|
|
|
|
:m_aContext(_rxContext)
|
2006-12-13 11:02:06 +00:00
|
|
|
,m_aDisposeListeners( m_aMutex )
|
|
|
|
,m_aControlObservers( m_aMutex )
|
2001-01-12 10:35:45 +00:00
|
|
|
,m_pView(NULL)
|
2006-12-13 11:02:06 +00:00
|
|
|
,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 )
|
2006-12-13 11:02:06 +00:00
|
|
|
,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 )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
|
|
|
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 );
|
2001-01-12 10:35:45 +00:00
|
|
|
DBG_DTOR(OPropertyBrowserController,NULL);
|
|
|
|
}
|
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
//------------------------------------------------------------------------
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2001-05-30 12:41:46 +00:00
|
|
|
//------------------------------------------------------------------------
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2002-01-09 13:01:46 +00:00
|
|
|
DBG_ASSERT(m_bContainerFocusListening, "OPropertyBrowserController::startContainerWindowListening: unable to start listening (inconsistence)!");
|
2001-05-30 12:41:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------------
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
//--------------------------------------------------------------------
|
|
|
|
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();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-05-10 09:49:24 +00:00
|
|
|
//--------------------------------------------------------------------
|
|
|
|
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
|
|
|
|
{
|
2007-07-06 07:52:26 +00:00
|
|
|
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;
|
2007-05-10 09:49:24 +00:00
|
|
|
|
|
|
|
void (SAL_CALL XPropertySet::*pListenerOperation)( const ::rtl::OUString&, const Reference< XPropertyChangeListener >& )
|
|
|
|
= _bDoListen ? &XPropertySet::addPropertyChangeListener : &XPropertySet::removePropertyChangeListener;
|
|
|
|
|
|
|
|
(xModelProperties.get()->*pListenerOperation)(
|
|
|
|
::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "IsReadOnly" ) ),
|
|
|
|
const_cast< OPropertyBrowserController* >( this )
|
|
|
|
);
|
|
|
|
}
|
|
|
|
catch( const Exception& )
|
|
|
|
{
|
|
|
|
DBG_UNHANDLED_EXCEPTION();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
//--------------------------------------------------------------------
|
|
|
|
void OPropertyBrowserController::impl_bindToNewModel_nothrow( const Reference< XObjectInspectorModel >& _rxInspectorModel )
|
|
|
|
{
|
2007-05-10 09:49:24 +00:00
|
|
|
impl_startOrStopModelListening_nothrow( false );
|
2006-12-13 11:02:06 +00:00
|
|
|
m_xModel = _rxInspectorModel;
|
2007-05-10 09:49:24 +00:00
|
|
|
impl_startOrStopModelListening_nothrow( true );
|
2006-12-13 11:02:06 +00:00
|
|
|
|
|
|
|
// initialize the view, if we already have one
|
|
|
|
if ( haveView() )
|
|
|
|
impl_initializeView_nothrow();
|
|
|
|
|
|
|
|
// inspect again, if we already have inspectees
|
2007-07-06 07:52:26 +00:00
|
|
|
if ( !m_aInspectedObjects.empty() )
|
2007-05-10 09:49:24 +00:00
|
|
|
impl_rebindToInspectee_nothrow( m_aInspectedObjects );
|
2006-12-13 11:02:06 +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 SAL_CALL OPropertyBrowserController::setInspectorModel( const Reference< XObjectInspectorModel >& _inspectorModel ) throw (RuntimeException)
|
|
|
|
{
|
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
|
|
|
|
|
|
|
if ( m_xModel == _inspectorModel )
|
|
|
|
return;
|
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
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
|
|
|
|
2006-12-13 11:02:06 +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)
|
|
|
|
{
|
2010-10-13 04:35:41 -05:00
|
|
|
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 );
|
|
|
|
|
2007-05-10 09:49:24 +00:00
|
|
|
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;
|
2007-05-10 09:49:24 +00:00
|
|
|
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
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
2006-07-26 06:58:55 +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;
|
|
|
|
}
|
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
//------------------------------------------------------------------------
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//------------------------------------------------------------------------
|
|
|
|
void SAL_CALL OPropertyBrowserController::attachFrame( const Reference< XFrame >& _rxFrame ) throw(RuntimeException)
|
|
|
|
{
|
2010-10-13 04:35:41 -05:00
|
|
|
SolarMutexGuard aSolarGuard;
|
2006-03-31 11:20:11 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
if (_rxFrame.is() && haveView())
|
2010-11-28 18:33:53 +01:00
|
|
|
throw RuntimeException(::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("Unable to attach to a second frame.")),*this);
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2001-05-30 12:41:46 +00:00
|
|
|
// revoke as focus listener from the old container window
|
|
|
|
stopContainerWindowListening();
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
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)
|
2010-11-28 18:33:53 +01:00
|
|
|
throw RuntimeException(::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("The frame is invalid. Unable to extract the container window.")),*this);
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2004-11-16 11:10:13 +00:00
|
|
|
if ( Construct( pParentWin ) )
|
|
|
|
{
|
|
|
|
try
|
|
|
|
{
|
|
|
|
m_xFrame->setComponent( VCLUnoHelper::GetInterface( m_pView ), this );
|
|
|
|
}
|
|
|
|
catch( const Exception& )
|
|
|
|
{
|
|
|
|
OSL_ENSURE( sal_False, "OPropertyBrowserController::attachFrame: caught an exception!" );
|
|
|
|
}
|
|
|
|
}
|
2001-05-30 12:41:46 +00:00
|
|
|
|
|
|
|
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();
|
2001-01-12 10:35:45 +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
|
|
|
sal_Bool SAL_CALL OPropertyBrowserController::attachModel( const Reference< XModel >& _rxModel ) throw(RuntimeException)
|
2001-01-12 10:35:45 +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
|
|
|
Reference< XObjectInspectorModel > xModel( _rxModel, UNO_QUERY );
|
|
|
|
if ( !xModel.is() )
|
|
|
|
return false;
|
|
|
|
|
|
|
|
setInspectorModel( xModel );
|
|
|
|
return getInspectorModel() == _rxModel;
|
|
|
|
}
|
|
|
|
|
2007-05-10 09:49:24 +00:00
|
|
|
//------------------------------------------------------------------------
|
|
|
|
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_ENSURE( sal_False, "OPropertyBrowserController::suspendPropertyHandlers_nothrow: caught an exception!" );
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return sal_True;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------------
|
2004-03-19 11:05:33 +00:00
|
|
|
sal_Bool SAL_CALL OPropertyBrowserController::suspend( sal_Bool _bSuspend ) throw(RuntimeException)
|
2001-01-12 10:35:45 +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
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2003-03-25 15:04:55 +00:00
|
|
|
OSL_ENSURE( haveView(), "OPropertyBrowserController::suspend: don't have a view anymore!" );
|
|
|
|
|
2004-03-19 11:05:33 +00:00
|
|
|
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;
|
2004-03-19 11:05:33 +00:00
|
|
|
}
|
|
|
|
|
2007-05-10 09:49:24 +00:00
|
|
|
if ( !suspendAll_nothrow() )
|
|
|
|
return sal_False;
|
2004-03-19 11:05:33 +00:00
|
|
|
|
2003-03-25 15:04:55 +00:00
|
|
|
// commit the editor's content
|
2006-12-13 11:02:06 +00:00
|
|
|
if ( haveView() )
|
|
|
|
getPropertyBox().CommitModified();
|
2003-03-25 15:04:55 +00:00
|
|
|
|
|
|
|
// stop listening
|
2001-05-30 12:41:46 +00:00
|
|
|
stopContainerWindowListening();
|
2003-03-25 15:04:55 +00:00
|
|
|
|
|
|
|
// outtahere
|
2001-01-12 10:35:45 +00:00
|
|
|
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 );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------------
|
|
|
|
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.getLength() )
|
|
|
|
{
|
|
|
|
m_sPageSelection = sPageSelection;
|
|
|
|
selectPageFromViewData();
|
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------------
|
|
|
|
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)
|
|
|
|
{
|
2010-10-13 04:35:41 -05:00
|
|
|
SolarMutexGuard aSolarGuard;
|
2006-03-31 11:20:11 +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
|
|
|
// stop inspecting the current object
|
|
|
|
stopInspection( false );
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
// say our dispose listeners goodbye
|
|
|
|
::com::sun::star::lang::EventObject aEvt;
|
|
|
|
aEvt.Source = static_cast< ::cppu::OWeakObject* >(this);
|
|
|
|
m_aDisposeListeners.disposeAndClear(aEvt);
|
2006-12-13 11:02:06 +00:00
|
|
|
m_aControlObservers.disposeAndClear(aEvt);
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
// don't delete explicitly (this is done by the frame we reside in)
|
|
|
|
m_pView = NULL;
|
2002-01-09 13:01:46 +00:00
|
|
|
|
|
|
|
Reference< XComponent > xViewAsComp( m_xView, UNO_QUERY );
|
|
|
|
if ( xViewAsComp.is() )
|
2004-03-19 11:05:33 +00:00
|
|
|
xViewAsComp->removeEventListener( static_cast< XPropertyChangeListener* >( this ) );
|
2002-01-09 13:01:46 +00:00
|
|
|
m_xView.clear( );
|
|
|
|
|
2007-05-10 09:49:24 +00:00
|
|
|
m_aInspectedObjects.clear();
|
|
|
|
impl_bindToNewModel_nothrow( NULL );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------------
|
|
|
|
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();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------------
|
|
|
|
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();
|
2001-01-12 10:35:45 +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
|
|
|
::rtl::OUString OPropertyBrowserController::getImplementationName_static( ) throw(RuntimeException)
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2010-11-28 18:33:53 +01:00
|
|
|
return ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("org.openoffice.comp.extensions.ObjectInspector"));
|
2001-01-12 10:35:45 +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
|
|
|
Sequence< ::rtl::OUString > OPropertyBrowserController::getSupportedServiceNames_static( ) throw(RuntimeException)
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
|
|
|
Sequence< ::rtl::OUString > aSupported(1);
|
2010-11-28 18:33:53 +01:00
|
|
|
aSupported[0] = ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("com.sun.star.inspection.ObjectInspector"));
|
2001-01-12 10:35:45 +00:00
|
|
|
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)
|
2001-01-12 10:35:45 +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
|
|
|
return *(new OPropertyBrowserController( _rxContext ) );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2001-05-30 12:41:46 +00:00
|
|
|
//------------------------------------------------------------------------
|
|
|
|
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();
|
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
if ( xContainerWindow.get() == xSourceWindow.get() )
|
2001-05-30 12:41:46 +00:00
|
|
|
{ // our container window got the focus
|
2006-12-13 11:02:06 +00:00
|
|
|
if ( haveView() )
|
|
|
|
getPropertyBox().GrabFocus();
|
2001-05-30 12:41:46 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------------
|
2006-07-26 06:58:55 +00:00
|
|
|
void SAL_CALL OPropertyBrowserController::focusLost( const FocusEvent& /*_rSource*/ ) throw (RuntimeException)
|
2001-05-30 12:41:46 +00:00
|
|
|
{
|
|
|
|
// not interested in
|
|
|
|
}
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//------------------------------------------------------------------------
|
|
|
|
void SAL_CALL OPropertyBrowserController::disposing( const EventObject& _rSource ) throw(RuntimeException)
|
|
|
|
{
|
2004-11-16 11:10:13 +00:00
|
|
|
if ( m_xView.is() && ( m_xView == _rSource.Source ) )
|
2001-05-30 12:41:46 +00:00
|
|
|
{
|
|
|
|
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
|
|
|
|
)
|
2001-05-30 12:41:46 +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 ( *loop == _rSource.Source )
|
|
|
|
{
|
|
|
|
m_aInspectedObjects.erase( loop );
|
|
|
|
break;
|
|
|
|
}
|
2001-05-30 12:41:46 +00:00
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2001-02-19 13:08:05 +00:00
|
|
|
//------------------------------------------------------------------------
|
|
|
|
IMPL_LINK(OPropertyBrowserController, OnPageActivation, void*, EMPTYARG)
|
|
|
|
{
|
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();
|
2001-02-19 13:08:05 +00:00
|
|
|
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()
|
2001-02-19 13:08:05 +00:00
|
|
|
{
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
2001-02-19 13:08:05 +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 ( m_sPageSelection.getLength() )
|
|
|
|
m_sLastValidPageSelection = m_sPageSelection;
|
|
|
|
else if ( sOldSelection.getLength() )
|
2005-07-01 10:51:38 +00:00
|
|
|
m_sLastValidPageSelection = sOldSelection;
|
2001-02-19 13:08:05 +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
|
|
|
sal_uInt16 OPropertyBrowserController::impl_getPageIdForCategory_nothrow( const ::rtl::OUString& _rCategoryName ) const
|
2001-02-19 13:08:05 +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
|
|
|
sal_uInt16 nPageId = (sal_uInt16)-1;
|
|
|
|
HashString2Int16::const_iterator pagePos = m_aPageIds.find( _rCategoryName );
|
|
|
|
if ( pagePos != m_aPageIds.end() )
|
|
|
|
nPageId = pagePos->second;
|
|
|
|
return nPageId;
|
2001-02-19 13:08:05 +00:00
|
|
|
}
|
|
|
|
|
2001-01-12 10:35:45 +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::selectPageFromViewData()
|
2001-01-12 10:35:45 +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
|
|
|
sal_uInt16 nNewPage = impl_getPageIdForCategory_nothrow( m_sPageSelection );
|
2001-01-12 10:35:45 +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 ( haveView() && ( nNewPage != (sal_uInt16)-1 ) )
|
|
|
|
m_pView->activatePage( nNewPage );
|
2004-03-19 11:05:33 +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
|
|
|
// just in case ...
|
|
|
|
updateViewDataFromActivePage();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------------
|
|
|
|
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);
|
2001-02-19 13:08:05 +00:00
|
|
|
m_pView->setPageActivationHandler(LINK(this, OPropertyBrowserController, OnPageActivation));
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
// 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())
|
2004-03-19 11:05:33 +00:00
|
|
|
xViewAsComp->addEventListener( static_cast< XPropertyChangeListener* >( this ) );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
getPropertyBox().SetLineListener(this);
|
|
|
|
getPropertyBox().SetControlObserver(this);
|
|
|
|
impl_initializeView_nothrow();
|
|
|
|
|
|
|
|
m_pView->Show();
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
return sal_True;
|
|
|
|
}
|
|
|
|
|
2004-03-19 11:05:33 +00:00
|
|
|
//------------------------------------------------------------------------
|
|
|
|
void SAL_CALL OPropertyBrowserController::propertyChange( const PropertyChangeEvent& _rEvent ) throw (RuntimeException)
|
|
|
|
{
|
2007-05-10 09:49:24 +00:00
|
|
|
if ( _rEvent.Source == m_xModel )
|
|
|
|
{
|
2011-01-20 10:30:44 +01:00
|
|
|
if ( _rEvent.PropertyName.equalsAsciiL( RTL_CONSTASCII_STRINGPARAM( "IsReadOnly" ) ) )
|
2007-05-10 09:49:24 +00:00
|
|
|
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 ) )
|
2004-03-19 11:05:33 +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
|
|
|
// forward the new value to the property box, to reflect the change in the UI
|
|
|
|
aNewValue = impl_getPropertyValue_throw( _rEvent.PropertyName );
|
2006-07-26 06:58:55 +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
|
|
|
// 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 );
|
2004-03-19 11:05:33 +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
|
|
|
|
|
|
|
// 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
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------------
|
2007-05-10 09:49:24 +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
|
|
|
{
|
2007-05-10 09:49:24 +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;
|
2007-05-10 09:49:24 +00:00
|
|
|
|
|
|
|
// 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 )
|
2001-02-19 13:08:05 +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
|
|
|
case PropertyControlType::StringListField:
|
2006-12-13 11:02:06 +00:00
|
|
|
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;
|
2004-03-19 11:05:33 +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
|
|
|
case PropertyControlType::MultiLineTextField:
|
2006-12-13 11:02:06 +00:00
|
|
|
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:
|
2006-12-13 11:02:06 +00:00
|
|
|
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;
|
2004-11-16 11:10:13 +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
|
|
|
case PropertyControlType::ComboBox:
|
2006-12-13 15:58:19 +00:00
|
|
|
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;
|
2004-11-16 11:10:13 +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
|
|
|
case PropertyControlType::TextField:
|
2006-12-13 11:02:06 +00:00
|
|
|
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;
|
2004-03-19 11:05:33 +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
|
|
|
case PropertyControlType::CharacterField:
|
2006-12-13 11:02:06 +00:00
|
|
|
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;
|
2004-03-19 11:05:33 +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
|
|
|
case PropertyControlType::NumericField:
|
2006-12-13 11:02:06 +00:00
|
|
|
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:
|
2006-12-13 11:02:06 +00:00
|
|
|
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:
|
2006-12-13 11:02:06 +00:00
|
|
|
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:
|
2006-12-13 11:02:06 +00:00
|
|
|
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:
|
2006-12-13 11:02:06 +00:00
|
|
|
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:
|
2006-12-13 11:02:06 +00:00
|
|
|
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 );
|
2001-02-19 13:08:05 +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
|
|
|
|
|
|
|
return xControl;
|
2001-01-12 10:35:45 +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_toggleInspecteeListening_nothrow( bool _bOn )
|
2001-01-12 10:35:45 +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
|
|
|
for ( InterfaceArray::const_iterator loop = m_aInspectedObjects.begin();
|
|
|
|
loop != m_aInspectedObjects.end();
|
|
|
|
++loop
|
|
|
|
)
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:10:13 +00:00
|
|
|
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() )
|
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 ) );
|
2008-12-11 07:05:03 +00:00
|
|
|
}
|
2004-11-16 11:10:13 +00:00
|
|
|
}
|
2008-01-14 13:59:53 +00:00
|
|
|
catch( const Exception& )
|
2004-11-16 11:10:13 +00:00
|
|
|
{
|
2008-01-14 13:59:53 +00:00
|
|
|
DBG_UNHANDLED_EXCEPTION();
|
2004-11-16 11:10:13 +00:00
|
|
|
}
|
2001-01-12 10:35:45 +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::stopInspection( bool _bCommitModified )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2006-12-13 11:02:06 +00:00
|
|
|
if ( haveView() )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2006-12-13 11:02:06 +00:00
|
|
|
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
|
2006-12-13 11:02:06 +00:00
|
|
|
getPropertyBox().CommitModified();
|
2001-01-12 10:35:45 +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
|
|
|
// hide the property box so that it does not flicker
|
2006-12-13 11:02:06 +00:00
|
|
|
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
|
2006-12-13 11:02:06 +00:00
|
|
|
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
|
|
|
}
|
2001-01-12 10:35:45 +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() )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
|
|
|
// 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
|
|
|
|
)
|
2006-12-13 11:02:06 +00:00
|
|
|
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-01-12 10:35:45 +00:00
|
|
|
}
|
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 );
|
2001-08-06 13:52:59 +00:00
|
|
|
|
2004-11-16 11:10:13 +00:00
|
|
|
// 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
|
2004-11-16 11:10:13 +00:00
|
|
|
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
|
2004-11-16 11:10:13 +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
|
|
|
{
|
|
|
|
try
|
|
|
|
{
|
|
|
|
(*loop)->removePropertyChangeListener( this );
|
|
|
|
(*loop)->dispose();
|
|
|
|
}
|
2006-03-31 11:20:11 +00:00
|
|
|
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& )
|
|
|
|
{
|
2006-03-31 11:20:11 +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
|
|
|
}
|
|
|
|
}
|
2004-11-16 11:10:13 +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 );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2006-07-26 06:58:55 +00:00
|
|
|
//------------------------------------------------------------------------
|
|
|
|
bool OPropertyBrowserController::impl_hasPropertyHandlerFor_nothrow( const ::rtl::OUString& _rPropertyName ) const
|
|
|
|
{
|
|
|
|
PropertyHandlerRepository::const_iterator handlerPos = m_aPropertyHandlers.find( _rPropertyName );
|
|
|
|
return ( handlerPos != m_aPropertyHandlers.end() );
|
|
|
|
}
|
|
|
|
|
2004-11-16 11:10:13 +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
|
|
|
OPropertyBrowserController::PropertyHandlerRef OPropertyBrowserController::impl_getHandlerForProperty_throw( const ::rtl::OUString& _rPropertyName ) const
|
2004-11-16 11:10:13 +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
|
|
|
PropertyHandlerRepository::const_iterator handlerPos = m_aPropertyHandlers.find( _rPropertyName );
|
|
|
|
if ( handlerPos == m_aPropertyHandlers.end() )
|
|
|
|
throw RuntimeException();
|
|
|
|
return handlerPos->second;
|
|
|
|
}
|
2004-11-16 11:10:13 +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
|
|
|
//------------------------------------------------------------------------
|
|
|
|
Any OPropertyBrowserController::impl_getPropertyValue_throw( const ::rtl::OUString& _rPropertyName )
|
|
|
|
{
|
|
|
|
PropertyHandlerRef handler = impl_getHandlerForProperty_throw( _rPropertyName );
|
|
|
|
return handler->getPropertyValue( _rPropertyName );
|
2004-11-16 11:10:13 +00:00
|
|
|
}
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//------------------------------------------------------------------------
|
2007-05-10 09:49:24 +00:00
|
|
|
void OPropertyBrowserController::impl_rebindToInspectee_nothrow( const InterfaceArray& _rObjects )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
|
|
|
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 );
|
2004-03-19 11:05:33 +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
|
|
|
// inspect the new object(s)
|
|
|
|
m_aInspectedObjects = _rObjects;
|
|
|
|
doInspection();
|
|
|
|
|
|
|
|
// update the user interface
|
|
|
|
UpdateUI();
|
2001-01-12 10:35:45 +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
|
|
|
catch(Exception&)
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2011-03-01 17:55:09 +01:00
|
|
|
OSL_FAIL("OPropertyBrowserController::impl_rebindToInspectee_nothrow: caught an exception !");
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
2003-10-21 08:06:34 +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::doInspection()
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
|
|
|
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;
|
2004-03-19 11:05:33 +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
|
|
|
PropertyHandlerArray aPropertyHandlers;
|
|
|
|
getPropertyHandlers( m_aInspectedObjects, aPropertyHandlers );
|
|
|
|
|
|
|
|
PropertyHandlerArray::iterator aHandler( aPropertyHandlers.begin() );
|
|
|
|
while ( aHandler != aPropertyHandlers.end() )
|
2001-01-12 10:35:45 +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
|
|
|
DBG_ASSERT( aHandler->get(), "OPropertyBrowserController::doInspection: invalid handler!" );
|
2003-03-25 15:04:55 +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
|
|
|
StlSyntaxSequence< Property > aThisHandlersProperties = (*aHandler)->getSupportedProperties();
|
2003-03-25 15:04:55 +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 ( aThisHandlersProperties.empty() )
|
|
|
|
{
|
|
|
|
// this handler doesn't know anything about the current inspectee -> ignore it
|
|
|
|
(*aHandler)->dispose();
|
|
|
|
aHandler = aPropertyHandlers.erase( aHandler );
|
|
|
|
continue;
|
|
|
|
}
|
2001-01-12 10:35:45 +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
|
|
|
// 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 )
|
|
|
|
);
|
2006-12-01 16:36:11 +00:00
|
|
|
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
|
|
|
{
|
2006-12-01 16:36:11 +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;
|
|
|
|
}
|
2001-03-22 09:04:09 +00:00
|
|
|
|
2006-12-01 16:36:11 +00:00
|
|
|
// 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
|
|
|
}
|
2001-01-12 10:35:45 +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
|
2006-12-01 16:36:11 +00:00
|
|
|
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 );
|
|
|
|
}
|
2001-01-12 10:35:45 +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
|
|
|
// be notified of changes which this handler is responsible for
|
|
|
|
(*aHandler)->addPropertyChangeListener( this );
|
2001-01-12 10:35:45 +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
|
|
|
// remember this handler for every of the properties which it is responsible
|
|
|
|
// for
|
2006-07-26 06:58:55 +00:00
|
|
|
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
|
|
|
|
)
|
2004-11-16 11:10:13 +00:00
|
|
|
{
|
2006-07-26 06:58:55 +00:00
|
|
|
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
|
2004-11-16 11:10:13 +00:00
|
|
|
}
|
2001-01-12 10:35:45 +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
|
|
|
// 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 ) );
|
|
|
|
}
|
2001-01-12 10:35:45 +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
|
|
|
++aHandler;
|
2001-01-12 10:35:45 +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
|
|
|
// create a new composer for UI requests coming from the handlers
|
2006-12-13 11:02:06 +00:00
|
|
|
m_pUIRequestComposer.reset( new ComposedPropertyUIUpdate( getInspectorUI(), this ) );
|
2001-01-12 10:35:45 +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
|
|
|
// sort the properties by relative position, as indicated by the model
|
|
|
|
for ( ::std::vector< Property >::const_iterator sourceProps = aProperties.begin();
|
|
|
|
sourceProps != aProperties.end();
|
|
|
|
++sourceProps
|
|
|
|
)
|
2001-01-12 10:35:45 +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
|
|
|
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;
|
2001-01-12 10:35:45 +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
|
|
|
// be notified when one of our inspectees dies
|
|
|
|
impl_toggleInspecteeListening_nothrow( true );
|
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
catch(Exception&)
|
|
|
|
{
|
2011-03-01 17:55:09 +01:00
|
|
|
OSL_FAIL("OPropertyBrowserController::doInspection : caught an exception !");
|
2001-01-12 10:35:45 +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
|
|
|
::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))
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
|
|
|
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
|
|
|
|
|
2006-07-26 06:58:55 +00:00
|
|
|
_rDescriptor.assignFrom( handler->second->describePropertyLine( _rProperty.Name, this ) );
|
2001-01-12 10:35:45 +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
|
|
|
_rDescriptor.xPropertyHandler = handler->second;
|
|
|
|
_rDescriptor.sName = _rProperty.Name;
|
|
|
|
_rDescriptor.aValue = _rDescriptor.xPropertyHandler->getPropertyValue( _rProperty.Name );
|
2001-01-12 10:35:45 +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 ( !_rDescriptor.DisplayName.getLength() )
|
2004-11-16 11:10:13 +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
|
|
|
#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.getLength(), sMessage );
|
|
|
|
#endif
|
|
|
|
_rDescriptor.DisplayName = _rProperty.Name;
|
2004-11-16 11:10:13 +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
|
|
|
|
|
|
|
PropertyState ePropertyState( _rDescriptor.xPropertyHandler->getPropertyState( _rProperty.Name ) );
|
|
|
|
if ( PropertyState_AMBIGUOUS_VALUE == ePropertyState )
|
2004-11-16 11:10:13 +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
|
|
|
_rDescriptor.bUnknownValue = true;
|
|
|
|
_rDescriptor.aValue.clear();
|
2004-11-16 11:10:13 +00:00
|
|
|
}
|
2007-05-10 09:49:24 +00:00
|
|
|
|
|
|
|
_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_ENSURE( sal_False, "OPropertyBrowserController::describePropertyLine: caught an exception!" );
|
|
|
|
}
|
|
|
|
}
|
2001-01-12 10:35:45 +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!" );
|
2004-11-16 11:10:13 +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
|
|
|
StlSyntaxSequence< PropertyCategoryDescriptor > aCategories;
|
|
|
|
if ( m_xModel.is() )
|
|
|
|
aCategories = m_xModel->describeCategories();
|
2001-01-12 10:35:45 +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
|
|
|
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!" );
|
2004-11-16 11:10:13 +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
|
|
|
m_aPageIds[ category->ProgrammaticName ] =
|
2006-12-13 11:02:06 +00:00
|
|
|
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
|
|
|
}
|
|
|
|
}
|
2004-11-16 11:10:13 +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;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
getPropertyBox().DisableUpdate();
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
sal_Bool bHaveFocus = getPropertyBox().HasChildPathFocus();
|
2004-11-16 11:10:13 +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
|
|
|
// create our tab pages
|
|
|
|
impl_buildCategories_throw();
|
|
|
|
// (and allow for pages to be actually unused)
|
|
|
|
::std::set< sal_uInt16 > aUsedPages;
|
2004-11-16 11:10:13 +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
|
|
|
// 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;
|
2004-11-16 11:10:13 +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
|
|
|
// 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 );
|
2004-11-16 11:10:13 +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
|
|
|
bool bIsActuatingProperty = impl_isActuatingProperty_nothrow( property->second.Name );
|
|
|
|
|
|
|
|
#if OSL_DEBUG_LEVEL > 0
|
|
|
|
if ( !aDescriptor.Category.getLength() )
|
2004-11-16 11:10:13 +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
|
|
|
::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_ENSURE( false, sMessage );
|
|
|
|
}
|
|
|
|
#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 ] =
|
2008-03-05 16:13:39 +00:00
|
|
|
getPropertyBox().AppendPage( aDescriptor.Category, SmartId() );
|
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 );
|
2004-11-16 11:10:13 +00:00
|
|
|
}
|
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
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 );
|
2004-11-16 11:10:13 +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 it's an actuating property, remember it
|
|
|
|
if ( bIsActuatingProperty )
|
2004-11-16 11:10:13 +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
|
|
|
aActuatingProperties.push_back( property->second.Name );
|
|
|
|
aActuatingPropertyValues.push_back( impl_getPropertyValue_throw( property->second.Name ) );
|
2004-11-16 11:10:13 +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
|
|
|
// update any dependencies for the actuating properties which we encountered
|
2004-11-16 11:10:13 +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
|
|
|
::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 );
|
2003-10-21 08:06:34 +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
|
|
|
// 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
|
|
|
|
)
|
2001-01-12 10:35:45 +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 ( aUsedPages.find( pageId->second ) == aUsedPages.end() )
|
2006-12-13 11:02:06 +00:00
|
|
|
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 );
|
2004-11-16 11:10:13 +00:00
|
|
|
|
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
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 )
|
2006-12-13 11:02:06 +00:00
|
|
|
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 );
|
2001-01-12 10:35:45 +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
|
|
|
// activate the previously active page (if possible)
|
|
|
|
if ( m_sLastValidPageSelection.getLength() )
|
|
|
|
m_sPageSelection = m_sLastValidPageSelection;
|
|
|
|
selectPageFromViewData();
|
|
|
|
}
|
2008-01-14 13:59:53 +00: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-01-14 13:59:53 +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
|
|
|
}
|
|
|
|
}
|
2001-01-12 10:35:45 +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
|
2006-12-13 11:02:06 +00:00
|
|
|
getPropertyBox().CommitModified();
|
2004-11-16 11:10:13 +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
|
|
|
PropertyHandlerRepository::const_iterator handler = m_aPropertyHandlers.find( _rName );
|
|
|
|
DBG_ASSERT( handler != m_aPropertyHandlers.end(), "OPropertyBrowserController::Clicked: a property without handler? This will crash!" );
|
2004-11-16 11:10:13 +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
|
|
|
ComposedUIAutoFireGuard aAutoFireGuard( *m_pUIRequestComposer );
|
|
|
|
|
|
|
|
Any aData;
|
2007-05-10 09:49:24 +00:00
|
|
|
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;
|
2006-07-26 06:58:55 +00:00
|
|
|
default:
|
|
|
|
OSL_ENSURE( false, "OPropertyBrowserController::Clicked: unknown result value!" );
|
|
|
|
break;
|
2004-11-16 11:10:13 +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
|
|
|
}
|
|
|
|
catch (Exception&)
|
|
|
|
{
|
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
|
|
|
}
|
2007-05-10 09:49:24 +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
|
|
|
|
{
|
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 );
|
2004-11-16 11:10:13 +00:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//////////////////////////////////////////////////////////////////////
|
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 );
|
2001-01-12 10:35:45 +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
|
|
|
// 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
|
|
|
}
|
|
|
|
catch(PropertyVetoException& eVetoException)
|
|
|
|
{
|
|
|
|
InfoBox(m_pView, eVetoException.Message).Execute();
|
2007-07-06 07:52:26 +00:00
|
|
|
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
|
|
|
}
|
|
|
|
catch(Exception&)
|
|
|
|
{
|
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();
|
|
|
|
}
|
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
//--------------------------------------------------------------------
|
|
|
|
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() ) );
|
2007-07-06 07:52:26 +00:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
2001-01-12 10:35:45 +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::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[] =
|
2001-01-12 10:35:45 +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
|
|
|
::cppu::ContextEntry_Init( ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "DialogParentWindow" ) ), makeAny( VCLUnoHelper::GetInterface( m_pView ) ) )
|
|
|
|
};
|
|
|
|
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() );
|
|
|
|
}
|
2001-01-12 10:35:45 +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
|
|
|
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() )
|
2001-01-12 10:35:45 +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
|
|
|
xHandler->inspect( _rObjects[0] );
|
|
|
|
_rHandlers.push_back( xHandler );
|
2001-01-12 10:35:45 +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
|
|
|
else
|
2001-01-12 10:35:45 +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
|
|
|
// create a single handler for every single object
|
|
|
|
::std::vector< Reference< XPropertyHandler > > aSingleHandlers( _rObjects.size() );
|
|
|
|
::std::vector< Reference< XPropertyHandler > >::iterator pHandler = aSingleHandlers.begin();
|
2001-01-12 10:35:45 +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
|
|
|
InterfaceArray::const_iterator pObject = _rObjects.begin();
|
|
|
|
InterfaceArray::const_iterator pObjectEnd = _rObjects.end();
|
2001-01-12 10:35:45 +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
|
|
|
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;
|
2001-01-12 10:35:45 +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
|
|
|
// note that the handlers will not be used by our caller, if they indicate that there are no
|
|
|
|
// properties they feel responsible for
|
|
|
|
}
|
2001-01-12 10:35:45 +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
|
|
|
//------------------------------------------------------------------------
|
|
|
|
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() );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2001-10-19 11:58:51 +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::rebuildPropertyUI( const ::rtl::OUString& _rPropertyName ) throw (RuntimeException)
|
2001-10-19 11:58:51 +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
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2006-12-13 11:02:06 +00:00
|
|
|
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;
|
2001-10-19 11:58:51 +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
|
|
|
OLineDescriptor aDescriptor;
|
|
|
|
try
|
2001-10-19 11:58:51 +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
|
|
|
describePropertyLine( propertyPos->second, aDescriptor );
|
2004-11-16 11:10:13 +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
|
|
|
catch( const Exception& )
|
2004-11-16 11:10:13 +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
|
|
|
OSL_ENSURE( sal_False, "OPropertyBrowserController::rebuildPropertyUI: caught an exception!" );
|
2001-10-19 11:58:51 +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
|
|
|
|
2006-12-13 11:02:06 +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
|
|
|
}
|
2001-10-19 11:58:51 +00:00
|
|
|
|
2003-10-21 08:06:34 +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)
|
2003-10-21 08:06:34 +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
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2006-12-13 11:02:06 +00:00
|
|
|
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;
|
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
getPropertyBox().EnablePropertyLine( _rPropertyName, _bEnable );
|
2003-10-21 08:06:34 +00:00
|
|
|
}
|
|
|
|
|
2004-03-19 11:05:33 +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::enablePropertyUIElements( const ::rtl::OUString& _rPropertyName, sal_Int16 _nElements, sal_Bool _bEnable ) throw (RuntimeException)
|
2002-11-12 11:12:36 +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
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2006-12-13 11:02:06 +00:00
|
|
|
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;
|
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
getPropertyBox().EnablePropertyControls( _rPropertyName, _nElements, _bEnable );
|
2002-11-12 11:12:36 +00:00
|
|
|
}
|
|
|
|
|
2004-03-19 11:05:33 +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::showPropertyUI( const ::rtl::OUString& _rPropertyName ) throw (RuntimeException)
|
2002-11-12 11:12:36 +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
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2006-12-13 11:02:06 +00:00
|
|
|
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;
|
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
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;
|
2006-12-13 11:02:06 +00:00
|
|
|
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;
|
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
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 );
|
2002-11-12 11:12:36 +00:00
|
|
|
}
|
|
|
|
|
2004-03-19 11:05:33 +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::hidePropertyUI( const ::rtl::OUString& _rPropertyName ) throw (RuntimeException)
|
2002-11-12 11:12:36 +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
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2006-12-13 11:02:06 +00:00
|
|
|
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;
|
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
getPropertyBox().RemoveEntry( _rPropertyName );
|
2002-11-12 11:12:36 +00:00
|
|
|
}
|
|
|
|
|
2004-03-19 11:05:33 +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::showCategory( const ::rtl::OUString& _rCategory, sal_Bool _bShow ) throw (RuntimeException)
|
2004-03-19 11:05:33 +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
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2006-12-13 11:02:06 +00:00
|
|
|
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();
|
2004-03-19 11:05:33 +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
|
|
|
sal_uInt16 nPageId = impl_getPageIdForCategory_nothrow( _rCategory );
|
|
|
|
OSL_ENSURE( nPageId != (sal_uInt16)-1, "OPropertyBrowserController::showCategory: invalid category!" );
|
2004-03-19 11:05:33 +00:00
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
getPropertyBox().ShowPropertyPage( nPageId, _bShow );
|
2004-03-19 11:05:33 +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
|
|
|
Reference< XPropertyControl > SAL_CALL OPropertyBrowserController::getPropertyControl( const ::rtl::OUString& _rPropertyName ) throw (RuntimeException)
|
2004-03-19 11:05:33 +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
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2006-12-13 11:02:06 +00:00
|
|
|
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();
|
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
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;
|
|
|
|
}
|
2004-03-19 11:05:33 +00:00
|
|
|
|
2006-12-13 11:02:06 +00:00
|
|
|
//--------------------------------------------------------------------
|
|
|
|
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)
|
|
|
|
{
|
2010-10-13 04:35:41 -05:00
|
|
|
SolarMutexGuard aSolarGuard;
|
2006-12-13 11:02:06 +00:00
|
|
|
::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;
|
2004-03-19 11:05:33 +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
|
|
|
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& )
|
|
|
|
{
|
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
|
|
|
}
|
2004-03-19 11:05:33 +00:00
|
|
|
}
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//............................................................................
|
|
|
|
} // namespace pcr
|
|
|
|
//............................................................................
|
|
|
|
|
|
|
|
|
2010-10-12 15:57:08 +02:00
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|