Files
libreoffice/extensions/source/propctrlr/handlerhelper.hxx

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

230 lines
9.4 KiB
C++
Raw Normal View History

2010-10-27 12:45:03 +01:00
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
/*
* This file is part of the LibreOffice project.
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*
* This file incorporates work covered by the following license notice:
*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed
* with this work for additional information regarding copyright
* ownership. The ASF licenses this file to you under the Apache
* License, Version 2.0 (the "License"); you may not use this file
* except in compliance with the License. You may obtain a copy of
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
*/
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
#ifndef INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_HANDLERHELPER_HXX
#define INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_HANDLERHELPER_HXX
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
#include <com/sun/star/beans/Property.hpp>
#include <com/sun/star/uno/XComponentContext.hpp>
#include <com/sun/star/script/XTypeConverter.hpp>
#include <com/sun/star/beans/XPropertyChangeListener.hpp>
#include <com/sun/star/inspection/XPropertyControlFactory.hpp>
#include <com/sun/star/beans/PropertyAttribute.hpp>
#include <com/sun/star/beans/Optional.hpp>
#include <vector>
namespace vcl { class Window; }
namespace weld { class Window; }
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
namespace com { namespace sun { namespace star {
namespace inspection {
struct LineDescriptor;
}
} } }
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
namespace pcr
{
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
//= PropertyHandlerHelper
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
class PropertyHandlerHelper
{
public:
/** helper for implementing XPropertyHandler::describePropertyLine in a generic way
*/
static void describePropertyLine(
const css::beans::Property& _rProperty,
css::inspection::LineDescriptor& /* [out] */ _out_rDescriptor,
const css::uno::Reference< css::inspection::XPropertyControlFactory >& _rxControlFactory
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
);
/** helper for implementing XPropertyHandler::convertToPropertyValue
*/
static css::uno::Any convertToPropertyValue(
const css::uno::Reference< css::uno::XComponentContext >& _rxContext,
const css::uno::Reference< css::script::XTypeConverter >& _rxTypeConverter,
const css::beans::Property& _rProperty,
const css::uno::Any& _rControlValue
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
);
/// helper for implementing XPropertyHandler::convertToControlValue
static css::uno::Any convertToControlValue(
const css::uno::Reference< css::uno::XComponentContext >& _rxContext,
const css::uno::Reference< css::script::XTypeConverter >& _rxTypeConverter,
const css::uno::Any& _rPropertyValue,
const css::uno::Type& _rControlValueType
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
);
/** creates an <member scope="css::inspection">PropertyControlType::ListBox</member>-type control
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
and fills it with initial values
@param _rxControlFactory
A control factory. Must not be <NULL/>.
@param _rInitialListEntries
the initial values of the control
@param _bReadOnlyControl
determines whether the control should be read-only
@param _bSorted
determines whether the list entries should be sorted
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
@return
the newly created control
*/
static css::uno::Reference< css::inspection::XPropertyControl >
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
createListBoxControl(
const css::uno::Reference< css::inspection::XPropertyControlFactory >& _rxControlFactory,
const std::vector< OUString >& _rInitialListEntries,
bool _bReadOnlyControl,
bool _bSorted
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
);
/** creates an <member scope="css::inspection">PropertyControlType::ListBox</member>-type control
and fills it with initial values.
@param _rxControlFactory
A control factory. Must not be <NULL/>.
migrate to boost::gettext * all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl * all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string") * ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching MODULE .mo files * UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui goes from l10n target to normal one, so the res/lang.zips of UI files go away * translation via Translation::get(hrc-define-key, imbued-std::locale) * python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there to keep finding the .hrc file uniform) so magic numbers can go away there * java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation mechanism * en-US res files go away, their strings are now the .hrc keys in the source code * remaining .res files are replaced by .mo files * in .res/.ui-lang-zip files, the old scheme missing translations of strings results in inserting the english original so something can be found, now the standard fallback of using the english original from the source key is used, so partial translations shrink dramatically in size * extract .hrc strings with hrcex which backs onto xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap * extract .ui strings with uiex which backs onto xgettext --add-comments --no-wrap * qtz for gettext translations is generated at runtime as ascii-ified crc32 of content + "|" + msgid * [API CHANGE] remove deprecated binary .res resouce loader related uno apis com::sun::star::resource::OfficeResourceLoader com::sun::star::resource::XResourceBundleLoader com::sun::star::resource::XResourceBundle when translating strings via uno apis com.sun.star.resource.StringResourceWithLocation can continue to be used Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
2017-06-11 20:56:30 +01:00
@param pTransIds
the initial translation ids for the value of the control
@param nElements
the count of initial values of the control
@param _bReadOnlyControl
determines whether the control should be read-only
@return
the newly created control
*/
static css::uno::Reference< css::inspection::XPropertyControl >
createListBoxControl(
const css::uno::Reference< css::inspection::XPropertyControlFactory >& _rxControlFactory,
migrate to boost::gettext * all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl * all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string") * ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching MODULE .mo files * UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui goes from l10n target to normal one, so the res/lang.zips of UI files go away * translation via Translation::get(hrc-define-key, imbued-std::locale) * python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there to keep finding the .hrc file uniform) so magic numbers can go away there * java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation mechanism * en-US res files go away, their strings are now the .hrc keys in the source code * remaining .res files are replaced by .mo files * in .res/.ui-lang-zip files, the old scheme missing translations of strings results in inserting the english original so something can be found, now the standard fallback of using the english original from the source key is used, so partial translations shrink dramatically in size * extract .hrc strings with hrcex which backs onto xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap * extract .ui strings with uiex which backs onto xgettext --add-comments --no-wrap * qtz for gettext translations is generated at runtime as ascii-ified crc32 of content + "|" + msgid * [API CHANGE] remove deprecated binary .res resouce loader related uno apis com::sun::star::resource::OfficeResourceLoader com::sun::star::resource::XResourceBundleLoader com::sun::star::resource::XResourceBundle when translating strings via uno apis com.sun.star.resource.StringResourceWithLocation can continue to be used Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
2017-06-11 20:56:30 +01:00
const char** pTransIds, size_t nElements,
bool _bReadOnlyControl
);
/** creates an <member scope="css::inspection">PropertyControlType::ComboBox</member>-type control
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
and fills it with initial values
@param _rxControlFactory
A control factory. Must not be <NULL/>.
@param _rInitialListEntries
the initial values of the control
@param _bSorted
determines whether the list entries should be sorted
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
@return
the newly created control
*/
static css::uno::Reference< css::inspection::XPropertyControl >
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
createComboBoxControl(
const css::uno::Reference< css::inspection::XPropertyControlFactory >& _rxControlFactory,
const std::vector< OUString >& _rInitialListEntries,
bool _bSorted
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
);
/** creates an <member scope="css::inspection">PropertyControlType::NumericField</member>-type control
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
and initializes it
@param _rxControlFactory
A control factory. Must not be <NULL/>.
@param _nDigits
number of decimal digits for the control
(<member scope="css::inspection">XNumericControl::DecimalDigits</member>)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
@param _rMinValue
minimum value which can be entered in the control
(<member scope="css::inspection">XNumericControl::MinValue</member>)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
@param _rMaxValue
maximum value which can be entered in the control
(<member scope="css::inspection">XNumericControl::MaxValue</member>)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
@return
the newly created control
*/
static css::uno::Reference< css::inspection::XPropertyControl >
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
createNumericControl(
const css::uno::Reference< css::inspection::XPropertyControlFactory >& _rxControlFactory,
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
sal_Int16 _nDigits,
const css::beans::Optional< double >& _rMinValue,
const css::beans::Optional< double >& _rMaxValue
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
);
/** marks the document passed in our UNO context as modified
The method looks up a value called "ContextDocument" in the given UNO component context,
queries it for the ->css::util::XModifiable interface, and calls its
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
setModified method. If either of those steps fails, this is asserted in a non-product
version, and silently ignore otherwise.
@param _rContext
the component context which was used to create the component calling this method
*/
static void setContextDocumentModified(
const css::uno::Reference< css::uno::XComponentContext > & _rContext
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
);
static css::uno::Reference< css::uno::XInterface > getContextDocument( const css::uno::Reference<css::uno::XComponentContext> & _rContext );
/// @throws css::uno::RuntimeException
static css::uno::Reference< css::uno::XInterface > getContextDocument_throw( const css::uno::Reference<css::uno::XComponentContext> & _rContext );
/** gets the window of the ObjectInspector in which a property handler lives
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
The method looks up a value called "DialogParentWindow" in the given UNO component context,
queries it for XWindow, and returns the respective vcl::Window*. If either of those steps fails,
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
this is asserted in a non-product version, and silently ignore otherwise.
@param _rContext
the component context which was used to create the component calling this method
*/
static vcl::Window* getDialogParentWindow( const css::uno::Reference< css::uno::XComponentContext > & _rContext );
static weld::Window* getDialogParentFrame( const css::uno::Reference< css::uno::XComponentContext > & _rContext );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
/** determines whether given PropertyAttributes require a to-be-created
<type scope="css::inspection">XPropertyControl</type> to be read-only
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
@param _nPropertyAttributes
the attributes of the property which should be reflected by a to-be-created
<type scope="css::inspection">XPropertyControl</type>
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
*/
static bool requiresReadOnlyControl( sal_Int16 _nPropertyAttributes )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
{
return ( _nPropertyAttributes & css::beans::PropertyAttribute::READONLY ) != 0;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
}
private:
PropertyHandlerHelper( const PropertyHandlerHelper& ) = delete;
PropertyHandlerHelper& operator=( const PropertyHandlerHelper& ) = delete;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
};
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
} // namespace pcr
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
#endif // INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_HANDLERHELPER_HXX
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:25 fs 1.1.2.5: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/09/05 07:41:51 fs 1.1.2.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/10 15:41:46 fs 1.1.2.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 14:00:03 fs 1.1.2.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:25:37 +00:00
2010-10-27 12:45:03 +01:00
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */