mir/libreoffice
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f7f4e9a823adc20cb4136d7ff6f83b943f23b3b6
libreoffice/extensions/source/propctrlr/handlerhelper.cxx

287 lines
12 KiB
C++
Raw Normal View History

Add vim/emacs modelines to all source files Fixes #fdo30794 Based on bin/add-modelines script (originally posted in mail 1286706307.1871.1399280959@webmail.messagingengine.com) Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
2010-10-12 15:57:08 +02:00
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
/*************************************************************************
*
INTEGRATION: CWS changefileheader (1.8.48); FILE MERGED 2008/04/01 15:15:18 thb 1.8.48.3: #i85898# Stripping all external header guards 2008/04/01 12:29:50 thb 1.8.48.2: #i85898# Stripping all external header guards 2008/03/31 12:31:44 rt 1.8.48.1: #i87441# Change license header to LPGL v3.
2008-04-11 10:03:24 +00:00
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
*
changefileheader2: #i109125#: change source file copyright notice from Sun Microsystems to Oracle; remove CVS style keywords (RCSfile, Revision)
2010-02-12 15:01:35 +01:00
* Copyright 2000, 2010 Oracle and/or its affiliates.
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
*
INTEGRATION: CWS changefileheader (1.8.48); FILE MERGED 2008/04/01 15:15:18 thb 1.8.48.3: #i85898# Stripping all external header guards 2008/04/01 12:29:50 thb 1.8.48.2: #i85898# Stripping all external header guards 2008/03/31 12:31:44 rt 1.8.48.1: #i87441# Change license header to LPGL v3.
2008-04-11 10:03:24 +00:00
* OpenOffice.org - a multi-platform office productivity suite
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
*
INTEGRATION: CWS changefileheader (1.8.48); FILE MERGED 2008/04/01 15:15:18 thb 1.8.48.3: #i85898# Stripping all external header guards 2008/04/01 12:29:50 thb 1.8.48.2: #i85898# Stripping all external header guards 2008/03/31 12:31:44 rt 1.8.48.1: #i87441# Change license header to LPGL v3.
2008-04-11 10:03:24 +00:00
* This file is part of OpenOffice.org.
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
*
INTEGRATION: CWS changefileheader (1.8.48); FILE MERGED 2008/04/01 15:15:18 thb 1.8.48.3: #i85898# Stripping all external header guards 2008/04/01 12:29:50 thb 1.8.48.2: #i85898# Stripping all external header guards 2008/03/31 12:31:44 rt 1.8.48.1: #i87441# Change license header to LPGL v3.
2008-04-11 10:03:24 +00:00
* OpenOffice.org is free software: you can redistribute it and/or modify
* it under the terms of the GNU Lesser General Public License version 3
* only, as published by the Free Software Foundation.
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
*
INTEGRATION: CWS changefileheader (1.8.48); FILE MERGED 2008/04/01 15:15:18 thb 1.8.48.3: #i85898# Stripping all external header guards 2008/04/01 12:29:50 thb 1.8.48.2: #i85898# Stripping all external header guards 2008/03/31 12:31:44 rt 1.8.48.1: #i87441# Change license header to LPGL v3.
2008-04-11 10:03:24 +00:00
* OpenOffice.org is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Lesser General Public License version 3 for more details
* (a copy is included in the LICENSE file that accompanied this code).
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
*
INTEGRATION: CWS changefileheader (1.8.48); FILE MERGED 2008/04/01 15:15:18 thb 1.8.48.3: #i85898# Stripping all external header guards 2008/04/01 12:29:50 thb 1.8.48.2: #i85898# Stripping all external header guards 2008/03/31 12:31:44 rt 1.8.48.1: #i87441# Change license header to LPGL v3.
2008-04-11 10:03:24 +00:00
* You should have received a copy of the GNU Lesser General Public License
* version 3 along with OpenOffice.org. If not, see
* <http://www.openoffice.org/license.html>
* for a copy of the LGPLv3 License.
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
*
************************************************************************/
#include "handlerhelper.hxx"
#include "propresid.hrc"
CWS-TOOLING: integrate CWS dba31f 2008-12-10 14:16:09 +0100 oj r265185 : #i96658# remove is 2008-12-10 08:46:07 +0100 oj r265147 : remove duplicate ids 2008-12-10 08:35:02 +0100 oj r265146 : #i96658# remove is 2008-12-09 11:44:35 +0100 oj r265072 : use of tools::StringresourceList 2008-12-09 11:43:41 +0100 oj r265071 : new class to read string elements from a Resource 2008-12-09 11:41:56 +0100 oj r265070 : export StringListResource 2008-12-09 11:38:17 +0100 oj r265068 : change string ; to more string objects 2008-12-08 12:11:43 +0100 oj r264985 : change default-license-id to lic-en-US 2008-12-05 12:06:09 +0100 oj r264896 : disable check to uncheck 2008-12-04 08:58:50 +0100 oj r264814 : #i96517,i96520,i96522# d&d, background, state fixed 2008-12-04 08:53:29 +0100 oj r264813 : #i96434# use document ui name from filter 2008-12-04 08:41:06 +0100 oj r264812 : #i96434# use document ui name from filter 2008-12-02 13:48:49 +0100 lla r264697 : #i96526# extra string for default otr wasn't found 2008-11-28 11:46:31 +0100 oj r264536 : move toolbar and resize add field dlg 2008-11-28 08:38:22 +0100 oj r264526 : load string resources 2008-11-27 19:28:52 +0100 oj r264520 : unsigned 2008-11-27 19:10:19 +0100 oj r264517 : move class into unnamed namespace 2008-11-27 18:33:38 +0100 oj r264514 : wrong param 2008-11-27 16:52:39 +0100 oj r264510 : #i96622# wrong string replacement 2008-11-27 16:46:03 +0100 oj r264509 : remove unused var 2008-11-27 13:37:16 +0100 oj r264484 : #i96432# notify only when not in special mode of the page 2008-11-27 13:16:47 +0100 oj r264479 : #i95224# accept alias in group by 2008-11-27 12:35:19 +0100 oj r264477 : #i95416# always show localized strings in the start marker 2008-11-27 09:49:29 +0100 oj r264455 : #i93460# set split pos 2008-11-27 09:05:27 +0100 oj r264447 : #i96453# use extension from mimetype / mediatype 2008-11-26 16:24:43 +0100 oj r264416 : #i96520# #i96522# #i96519# some changes at the add field dialog 2008-11-26 16:20:27 +0100 oj r264414 : #i93420# prevent to register a none system file url 2008-11-26 16:19:02 +0100 oj r264413 : #i96522# new class to paste multiple objects 2008-11-26 10:06:12 +0100 oj r264349 : #i96191# introduce new error message and check if type was defined aand should not be changed 2008-11-26 10:06:12 +0100 oj r264348 : #i96191# throw error when decimal is to big 2008-11-25 12:08:59 +0100 oj r264281 : #i96431# correct state for align and move 2008-11-25 11:54:47 +0100 oj r264280 : #i96428# when new bind to first table 2008-11-25 11:49:55 +0100 oj r264279 : #i96434# add report output format to inspection 2008-11-25 11:49:05 +0100 oj r264278 : #i96434# add report output format to inspection 2008-11-24 10:46:23 +0100 oj r264215 : #i96458# size width for controls 2008-11-24 09:28:56 +0100 oj r264199 : #i96459# mark detail section when nothing is selected 2008-11-20 12:02:35 +0100 oj r264038 : #i96191# fix check for prec 2008-11-20 08:06:32 +0100 oj r264026 : #i90949# patch MID function 2008-11-11 13:14:58 +0100 oj r263555 : #i96086# apply patch 2008-11-11 11:34:46 +0100 oj r263549 : #i94128# correct height of section when controls moved outside 2008-11-11 07:52:08 +0100 oj r263544 : #i94729# fix string with ; as sep 2008-11-11 07:45:27 +0100 oj r263543 : #i95222# export chart title style 2008-11-11 07:43:37 +0100 oj r263542 : #i92541# fix line height
2008-12-10 13:41:25 +00:00
#include "formresid.hrc"
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
#include <comphelper/extract.hxx>
#include "modulepcr.hxx"
#include "enumrepresentation.hxx"
#include "formmetadata.hxx"
#include "pcrcomponentcontext.hxx"
INTEGRATION: CWS oj14 (1.2.66); FILE MERGED 2006/12/18 16:52:33 oj 1.2.66.4: RESYNC: (1.4-1.6); FILE MERGED 2006/11/08 15:07:18 oj 1.2.66.3: merge conflicts resolved 2006/11/07 12:06:26 oj 1.2.66.2: RESYNC: (1.2-1.4); FILE MERGED 2006/07/04 11:07:26 oj 1.2.66.1: property browser adjustments to remove form dependency
2007-07-06 07:49:40 +00:00
#include "com/sun/star/inspection/StringRepresentation.hpp"
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
#include <com/sun/star/beans/PropertyAttribute.hpp>
#include <com/sun/star/uno/XComponentContext.hpp>
#include <com/sun/star/util/XModifiable.hpp>
#include <com/sun/star/awt/XWindow.hpp>
#include <com/sun/star/inspection/LineDescriptor.hpp>
#include <com/sun/star/inspection/PropertyControlType.hpp>
#include <com/sun/star/inspection/XStringListControl.hpp>
#include <com/sun/star/inspection/XNumericControl.hpp>
#include <tools/debug.hxx>
INTEGRATION: CWS wae4extensions (1.7.44); FILE MERGED 2007/09/27 07:18:25 fs 1.7.44.1: #i81612# warning-free code
2008-01-14 13:59:27 +00:00
#include <tools/diagnose_ex.h>
CWS-TOOLING: integrate CWS dba31f 2008-12-10 14:16:09 +0100 oj r265185 : #i96658# remove is 2008-12-10 08:46:07 +0100 oj r265147 : remove duplicate ids 2008-12-10 08:35:02 +0100 oj r265146 : #i96658# remove is 2008-12-09 11:44:35 +0100 oj r265072 : use of tools::StringresourceList 2008-12-09 11:43:41 +0100 oj r265071 : new class to read string elements from a Resource 2008-12-09 11:41:56 +0100 oj r265070 : export StringListResource 2008-12-09 11:38:17 +0100 oj r265068 : change string ; to more string objects 2008-12-08 12:11:43 +0100 oj r264985 : change default-license-id to lic-en-US 2008-12-05 12:06:09 +0100 oj r264896 : disable check to uncheck 2008-12-04 08:58:50 +0100 oj r264814 : #i96517,i96520,i96522# d&d, background, state fixed 2008-12-04 08:53:29 +0100 oj r264813 : #i96434# use document ui name from filter 2008-12-04 08:41:06 +0100 oj r264812 : #i96434# use document ui name from filter 2008-12-02 13:48:49 +0100 lla r264697 : #i96526# extra string for default otr wasn't found 2008-11-28 11:46:31 +0100 oj r264536 : move toolbar and resize add field dlg 2008-11-28 08:38:22 +0100 oj r264526 : load string resources 2008-11-27 19:28:52 +0100 oj r264520 : unsigned 2008-11-27 19:10:19 +0100 oj r264517 : move class into unnamed namespace 2008-11-27 18:33:38 +0100 oj r264514 : wrong param 2008-11-27 16:52:39 +0100 oj r264510 : #i96622# wrong string replacement 2008-11-27 16:46:03 +0100 oj r264509 : remove unused var 2008-11-27 13:37:16 +0100 oj r264484 : #i96432# notify only when not in special mode of the page 2008-11-27 13:16:47 +0100 oj r264479 : #i95224# accept alias in group by 2008-11-27 12:35:19 +0100 oj r264477 : #i95416# always show localized strings in the start marker 2008-11-27 09:49:29 +0100 oj r264455 : #i93460# set split pos 2008-11-27 09:05:27 +0100 oj r264447 : #i96453# use extension from mimetype / mediatype 2008-11-26 16:24:43 +0100 oj r264416 : #i96520# #i96522# #i96519# some changes at the add field dialog 2008-11-26 16:20:27 +0100 oj r264414 : #i93420# prevent to register a none system file url 2008-11-26 16:19:02 +0100 oj r264413 : #i96522# new class to paste multiple objects 2008-11-26 10:06:12 +0100 oj r264349 : #i96191# introduce new error message and check if type was defined aand should not be changed 2008-11-26 10:06:12 +0100 oj r264348 : #i96191# throw error when decimal is to big 2008-11-25 12:08:59 +0100 oj r264281 : #i96431# correct state for align and move 2008-11-25 11:54:47 +0100 oj r264280 : #i96428# when new bind to first table 2008-11-25 11:49:55 +0100 oj r264279 : #i96434# add report output format to inspection 2008-11-25 11:49:05 +0100 oj r264278 : #i96434# add report output format to inspection 2008-11-24 10:46:23 +0100 oj r264215 : #i96458# size width for controls 2008-11-24 09:28:56 +0100 oj r264199 : #i96459# mark detail section when nothing is selected 2008-11-20 12:02:35 +0100 oj r264038 : #i96191# fix check for prec 2008-11-20 08:06:32 +0100 oj r264026 : #i90949# patch MID function 2008-11-11 13:14:58 +0100 oj r263555 : #i96086# apply patch 2008-11-11 11:34:46 +0100 oj r263549 : #i94128# correct height of section when controls moved outside 2008-11-11 07:52:08 +0100 oj r263544 : #i94729# fix string with ; as sep 2008-11-11 07:45:27 +0100 oj r263543 : #i95222# export chart title style 2008-11-11 07:43:37 +0100 oj r263542 : #i92541# fix line height
2008-12-10 13:41:25 +00:00
#include <tools/StringListResource.hxx>
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
#include <toolkit/helper/vclunohelper.hxx>
INTEGRATION: CWS dba22ui (1.4.54); FILE MERGED 2006/11/20 09:58:03 fs 1.4.54.1: #i28897# sorting in a combo/list box now optional
2006-12-13 15:57:36 +00:00
#include <algorithm>
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
//........................................................................
namespace pcr
{
//........................................................................
using namespace ::com::sun::star::uno;
using namespace ::com::sun::star::lang;
using namespace ::com::sun::star::awt;
using namespace ::com::sun::star::util;
using namespace ::com::sun::star::beans;
using namespace ::com::sun::star::script;
using namespace ::com::sun::star::inspection;
//====================================================================
//= PropertyHandlerHelper
//====================================================================
//--------------------------------------------------------------------
INTEGRATION: CWS dba204b (1.2.68); FILE MERGED 2006/07/06 14:52:28 fs 1.2.68.1: #i65159# describePropertyLine now returning a LineDescriptor, instead of taking an out parameter / some less warnings
2006-07-26 06:58:12 +00:00
void PropertyHandlerHelper::describePropertyLine( const Property& _rProperty,
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
LineDescriptor& /* [out] */ _out_rDescriptor, const Reference< XPropertyControlFactory >& _rxControlFactory )
{
// display the pure property name - no L10N
_out_rDescriptor.DisplayName = _rProperty.Name;
OSL_PRECOND( _rxControlFactory.is(), "PropertyHandlerHelper::describePropertyLine: no factory -> no control!" );
if ( !_rxControlFactory.is() )
return;
sal_Bool bReadOnlyControl = requiresReadOnlyControl( _rProperty.Attributes );
INTEGRATION: CWS dba22ui (1.4.54); FILE MERGED 2006/11/20 09:58:03 fs 1.4.54.1: #i28897# sorting in a combo/list box now optional
2006-12-13 15:57:36 +00:00
// special handling for booleans (this will become a list)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
if ( _rProperty.Type.getTypeClass() == TypeClass_BOOLEAN )
{
CWS-TOOLING: integrate CWS dba31f 2008-12-10 14:16:09 +0100 oj r265185 : #i96658# remove is 2008-12-10 08:46:07 +0100 oj r265147 : remove duplicate ids 2008-12-10 08:35:02 +0100 oj r265146 : #i96658# remove is 2008-12-09 11:44:35 +0100 oj r265072 : use of tools::StringresourceList 2008-12-09 11:43:41 +0100 oj r265071 : new class to read string elements from a Resource 2008-12-09 11:41:56 +0100 oj r265070 : export StringListResource 2008-12-09 11:38:17 +0100 oj r265068 : change string ; to more string objects 2008-12-08 12:11:43 +0100 oj r264985 : change default-license-id to lic-en-US 2008-12-05 12:06:09 +0100 oj r264896 : disable check to uncheck 2008-12-04 08:58:50 +0100 oj r264814 : #i96517,i96520,i96522# d&d, background, state fixed 2008-12-04 08:53:29 +0100 oj r264813 : #i96434# use document ui name from filter 2008-12-04 08:41:06 +0100 oj r264812 : #i96434# use document ui name from filter 2008-12-02 13:48:49 +0100 lla r264697 : #i96526# extra string for default otr wasn't found 2008-11-28 11:46:31 +0100 oj r264536 : move toolbar and resize add field dlg 2008-11-28 08:38:22 +0100 oj r264526 : load string resources 2008-11-27 19:28:52 +0100 oj r264520 : unsigned 2008-11-27 19:10:19 +0100 oj r264517 : move class into unnamed namespace 2008-11-27 18:33:38 +0100 oj r264514 : wrong param 2008-11-27 16:52:39 +0100 oj r264510 : #i96622# wrong string replacement 2008-11-27 16:46:03 +0100 oj r264509 : remove unused var 2008-11-27 13:37:16 +0100 oj r264484 : #i96432# notify only when not in special mode of the page 2008-11-27 13:16:47 +0100 oj r264479 : #i95224# accept alias in group by 2008-11-27 12:35:19 +0100 oj r264477 : #i95416# always show localized strings in the start marker 2008-11-27 09:49:29 +0100 oj r264455 : #i93460# set split pos 2008-11-27 09:05:27 +0100 oj r264447 : #i96453# use extension from mimetype / mediatype 2008-11-26 16:24:43 +0100 oj r264416 : #i96520# #i96522# #i96519# some changes at the add field dialog 2008-11-26 16:20:27 +0100 oj r264414 : #i93420# prevent to register a none system file url 2008-11-26 16:19:02 +0100 oj r264413 : #i96522# new class to paste multiple objects 2008-11-26 10:06:12 +0100 oj r264349 : #i96191# introduce new error message and check if type was defined aand should not be changed 2008-11-26 10:06:12 +0100 oj r264348 : #i96191# throw error when decimal is to big 2008-11-25 12:08:59 +0100 oj r264281 : #i96431# correct state for align and move 2008-11-25 11:54:47 +0100 oj r264280 : #i96428# when new bind to first table 2008-11-25 11:49:55 +0100 oj r264279 : #i96434# add report output format to inspection 2008-11-25 11:49:05 +0100 oj r264278 : #i96434# add report output format to inspection 2008-11-24 10:46:23 +0100 oj r264215 : #i96458# size width for controls 2008-11-24 09:28:56 +0100 oj r264199 : #i96459# mark detail section when nothing is selected 2008-11-20 12:02:35 +0100 oj r264038 : #i96191# fix check for prec 2008-11-20 08:06:32 +0100 oj r264026 : #i90949# patch MID function 2008-11-11 13:14:58 +0100 oj r263555 : #i96086# apply patch 2008-11-11 11:34:46 +0100 oj r263549 : #i94128# correct height of section when controls moved outside 2008-11-11 07:52:08 +0100 oj r263544 : #i94729# fix string with ; as sep 2008-11-11 07:45:27 +0100 oj r263543 : #i95222# export chart title style 2008-11-11 07:43:37 +0100 oj r263542 : #i92541# fix line height
2008-12-10 13:41:25 +00:00
::std::vector< ::rtl::OUString > aListEntries;
tools::StringListResource aRes(PcrRes(RID_RSC_ENUM_YESNO),aListEntries);
_out_rDescriptor.Control = createListBoxControl( _rxControlFactory, aListEntries, bReadOnlyControl, sal_False );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
return;
}
sal_Int16 nControlType = PropertyControlType::TextField;
switch ( _rProperty.Type.getTypeClass() )
{
case TypeClass_BYTE:
case TypeClass_SHORT:
case TypeClass_UNSIGNED_SHORT:
case TypeClass_LONG:
case TypeClass_UNSIGNED_LONG:
case TypeClass_HYPER:
case TypeClass_UNSIGNED_HYPER:
case TypeClass_FLOAT:
case TypeClass_DOUBLE:
nControlType = PropertyControlType::NumericField;
break;
case TypeClass_SEQUENCE:
nControlType = PropertyControlType::StringListField;
break;
default:
Move DBG_ERROR to OSL_FAIL
2011-03-01 17:55:09 +01:00
OSL_FAIL( "PropertyHandlerHelper::describePropertyLine: don't know how to represent this at the UI!" );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
// NO break!
case TypeClass_STRING:
nControlType = PropertyControlType::TextField;
break;
}
// create a control
_out_rDescriptor.Control = _rxControlFactory->createPropertyControl( nControlType, bReadOnlyControl );
}
//--------------------------------------------------------------------
namespace
{
Reference< XPropertyControl > lcl_implCreateListLikeControl(
const Reference< XPropertyControlFactory >& _rxControlFactory,
const ::std::vector< ::rtl::OUString >& _rInitialListEntries,
sal_Bool _bReadOnlyControl,
INTEGRATION: CWS dba22ui (1.4.54); FILE MERGED 2006/11/20 09:58:03 fs 1.4.54.1: #i28897# sorting in a combo/list box now optional
2006-12-13 15:57:36 +00:00
sal_Bool _bSorted,
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
sal_Bool _bTrueIfListBoxFalseIfComboBox
)
{
Reference< XStringListControl > xListControl(
_rxControlFactory->createPropertyControl(
_bTrueIfListBoxFalseIfComboBox ? PropertyControlType::ListBox : PropertyControlType::ComboBox, _bReadOnlyControl
),
UNO_QUERY_THROW
);
INTEGRATION: CWS dba22ui (1.4.54); FILE MERGED 2006/11/20 09:58:03 fs 1.4.54.1: #i28897# sorting in a combo/list box now optional
2006-12-13 15:57:36 +00:00
::std::vector< ::rtl::OUString > aInitialEntries( _rInitialListEntries );
if ( _bSorted )
::std::sort( aInitialEntries.begin(), aInitialEntries.end() );
for ( ::std::vector< ::rtl::OUString >::const_iterator loop = aInitialEntries.begin();
loop != aInitialEntries.end();
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
++loop
)
xListControl->appendListEntry( *loop );
return xListControl.get();
}
}
//--------------------------------------------------------------------
Reference< XPropertyControl > PropertyHandlerHelper::createListBoxControl( const Reference< XPropertyControlFactory >& _rxControlFactory,
INTEGRATION: CWS dba22ui (1.4.54); FILE MERGED 2006/11/20 09:58:03 fs 1.4.54.1: #i28897# sorting in a combo/list box now optional
2006-12-13 15:57:36 +00:00
const ::std::vector< ::rtl::OUString >& _rInitialListEntries, sal_Bool _bReadOnlyControl, sal_Bool _bSorted )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
{
INTEGRATION: CWS dba22ui (1.4.54); FILE MERGED 2006/11/20 09:58:03 fs 1.4.54.1: #i28897# sorting in a combo/list box now optional
2006-12-13 15:57:36 +00:00
return lcl_implCreateListLikeControl( _rxControlFactory, _rInitialListEntries, _bReadOnlyControl, _bSorted, sal_True );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
}
//--------------------------------------------------------------------
Reference< XPropertyControl > PropertyHandlerHelper::createComboBoxControl( const Reference< XPropertyControlFactory >& _rxControlFactory,
INTEGRATION: CWS dba22ui (1.4.54); FILE MERGED 2006/11/20 09:58:03 fs 1.4.54.1: #i28897# sorting in a combo/list box now optional
2006-12-13 15:57:36 +00:00
const ::std::vector< ::rtl::OUString >& _rInitialListEntries, sal_Bool _bReadOnlyControl, sal_Bool _bSorted )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
{
INTEGRATION: CWS dba22ui (1.4.54); FILE MERGED 2006/11/20 09:58:03 fs 1.4.54.1: #i28897# sorting in a combo/list box now optional
2006-12-13 15:57:36 +00:00
return lcl_implCreateListLikeControl( _rxControlFactory, _rInitialListEntries, _bReadOnlyControl, _bSorted, sal_False );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
}
//--------------------------------------------------------------------
Reference< XPropertyControl > PropertyHandlerHelper::createNumericControl( const Reference< XPropertyControlFactory >& _rxControlFactory,
sal_Int16 _nDigits, const Optional< double >& _rMinValue, const Optional< double >& _rMaxValue, sal_Bool _bReadOnlyControl )
{
Reference< XNumericControl > xNumericControl(
_rxControlFactory->createPropertyControl( PropertyControlType::NumericField, _bReadOnlyControl ),
UNO_QUERY_THROW
);
xNumericControl->setDecimalDigits( _nDigits );
xNumericControl->setMinValue( _rMinValue );
xNumericControl->setMaxValue( _rMaxValue );
return xNumericControl.get();
}
//--------------------------------------------------------------------
INTEGRATION: CWS oj14 (1.2.66); FILE MERGED 2006/12/18 16:52:33 oj 1.2.66.4: RESYNC: (1.4-1.6); FILE MERGED 2006/11/08 15:07:18 oj 1.2.66.3: merge conflicts resolved 2006/11/07 12:06:26 oj 1.2.66.2: RESYNC: (1.2-1.4); FILE MERGED 2006/07/04 11:07:26 oj 1.2.66.1: property browser adjustments to remove form dependency
2007-07-06 07:49:40 +00:00
Any PropertyHandlerHelper::convertToPropertyValue( const Reference< XComponentContext >& _rxContext,const Reference< XTypeConverter >& _rxTypeConverter,
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
const Property& _rProperty, const Any& _rControlValue )
{
Any aPropertyValue( _rControlValue );
if ( !aPropertyValue.hasValue() )
// NULL is converted to NULL
return aPropertyValue;
if ( aPropertyValue.getValueType().equals( _rProperty.Type ) )
// nothing to do, type is already as desired
return aPropertyValue;
if ( _rControlValue.getValueType().getTypeClass() == TypeClass_STRING )
{
::rtl::OUString sControlValue;
_rControlValue >>= sControlValue;
INTEGRATION: CWS oj14 (1.2.66); FILE MERGED 2006/12/18 16:52:33 oj 1.2.66.4: RESYNC: (1.4-1.6); FILE MERGED 2006/11/08 15:07:18 oj 1.2.66.3: merge conflicts resolved 2006/11/07 12:06:26 oj 1.2.66.2: RESYNC: (1.2-1.4); FILE MERGED 2006/07/04 11:07:26 oj 1.2.66.1: property browser adjustments to remove form dependency
2007-07-06 07:49:40 +00:00
Reference< XStringRepresentation > xConversionHelper = StringRepresentation::create( _rxContext,_rxTypeConverter );
aPropertyValue = xConversionHelper->convertToPropertyValue( sControlValue, _rProperty.Type );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
}
else
{
try
{
if ( _rxTypeConverter.is() )
aPropertyValue = _rxTypeConverter->convertTo( _rControlValue, _rProperty.Type );
}
catch( const Exception& )
{
Move OSL_ENSURE(sal_False,...) to OSL_FAIL(...)
2011-03-19 14:06:18 +01:00
OSL_FAIL( "PropertyHandlerHelper::convertToPropertyValue: caught an exception while converting via TypeConverter!" );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
}
}
return aPropertyValue;
}
//--------------------------------------------------------------------
INTEGRATION: CWS oj14 (1.2.66); FILE MERGED 2006/12/18 16:52:33 oj 1.2.66.4: RESYNC: (1.4-1.6); FILE MERGED 2006/11/08 15:07:18 oj 1.2.66.3: merge conflicts resolved 2006/11/07 12:06:26 oj 1.2.66.2: RESYNC: (1.2-1.4); FILE MERGED 2006/07/04 11:07:26 oj 1.2.66.1: property browser adjustments to remove form dependency
2007-07-06 07:49:40 +00:00
Any PropertyHandlerHelper::convertToControlValue( const Reference< XComponentContext >& _rxContext,const Reference< XTypeConverter >& _rxTypeConverter,
INTEGRATION: CWS dba204b (1.2.68); FILE MERGED 2006/07/06 14:52:28 fs 1.2.68.1: #i65159# describePropertyLine now returning a LineDescriptor, instead of taking an out parameter / some less warnings
2006-07-26 06:58:12 +00:00
const Any& _rPropertyValue, const Type& _rControlValueType )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
{
Any aControlValue( _rPropertyValue );
if ( !aControlValue.hasValue() )
// NULL is converted to NULL
return aControlValue;
if ( _rControlValueType.getTypeClass() == TypeClass_STRING )
{
INTEGRATION: CWS oj14 (1.2.66); FILE MERGED 2006/12/18 16:52:33 oj 1.2.66.4: RESYNC: (1.4-1.6); FILE MERGED 2006/11/08 15:07:18 oj 1.2.66.3: merge conflicts resolved 2006/11/07 12:06:26 oj 1.2.66.2: RESYNC: (1.2-1.4); FILE MERGED 2006/07/04 11:07:26 oj 1.2.66.1: property browser adjustments to remove form dependency
2007-07-06 07:49:40 +00:00
Reference< XStringRepresentation > xConversionHelper = StringRepresentation::create( _rxContext,_rxTypeConverter );
aControlValue <<= xConversionHelper->convertToControlValue( _rPropertyValue );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
}
else
{
try
{
if ( _rxTypeConverter.is() )
aControlValue = _rxTypeConverter->convertTo( _rPropertyValue, _rControlValueType );
}
catch( const Exception& )
{
Move OSL_ENSURE(sal_False,...) to OSL_FAIL(...)
2011-03-19 14:06:18 +01:00
OSL_FAIL( "PropertyHandlerHelper::convertToControlValue: caught an exception while converting via TypeConverter!" );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
}
}
return aControlValue;
}
//--------------------------------------------------------------------
void PropertyHandlerHelper::setContextDocumentModified( const ComponentContext& _rContext )
{
try
{
Reference< XModifiable > xDocumentModifiable( _rContext.getContextValueByAsciiName( "ContextDocument" ), UNO_QUERY_THROW );
xDocumentModifiable->setModified( sal_True );
}
INTEGRATION: CWS wae4extensions (1.7.44); FILE MERGED 2007/09/27 07:18:25 fs 1.7.44.1: #i81612# warning-free code
2008-01-14 13:59:27 +00:00
catch( const Exception& )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
{
INTEGRATION: CWS wae4extensions (1.7.44); FILE MERGED 2007/09/27 07:18:25 fs 1.7.44.1: #i81612# warning-free code
2008-01-14 13:59:27 +00:00
DBG_UNHANDLED_EXCEPTION();
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
}
}
//--------------------------------------------------------------------
Window* PropertyHandlerHelper::getDialogParentWindow( const ComponentContext& _rContext )
{
Window* pInspectorWindow = NULL;
try
{
Reference< XWindow > xInspectorWindow( _rContext.getContextValueByAsciiName( "DialogParentWindow" ), UNO_QUERY_THROW );
pInspectorWindow = VCLUnoHelper::GetWindow( xInspectorWindow );
}
INTEGRATION: CWS wae4extensions (1.7.44); FILE MERGED 2007/09/27 07:18:25 fs 1.7.44.1: #i81612# warning-free code
2008-01-14 13:59:27 +00:00
catch( const Exception& )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
{
INTEGRATION: CWS wae4extensions (1.7.44); FILE MERGED 2007/09/27 07:18:25 fs 1.7.44.1: #i81612# warning-free code
2008-01-14 13:59:27 +00:00
DBG_UNHANDLED_EXCEPTION();
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:24 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:27 +00:00
}
return pInspectorWindow;
}
//........................................................................
} // namespace pcr
//........................................................................
Add vim/emacs modelines to all source files Fixes #fdo30794 Based on bin/add-modelines script (originally posted in mail 1286706307.1871.1399280959@webmail.messagingengine.com) Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
2010-10-12 15:57:08 +02:00
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
Reference in New Issue Copy Permalink