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

656 lines
26 KiB
C++
Raw Normal View History

/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
re-base on ALv2 code. Includes (at least) relevant parts of: linecap: Reintegrating finished LineCap feature Patch contributed by Regina Henschel http://svn.apache.org/viewvc?view=revision&revision=1232507 Patches contributed by Sven Jacobi impress212: #i81610# fixed animation export http://svn.apache.org/viewvc?view=revision&revision=1167620 impress212: drawinglayer gbuild environment changes http://svn.apache.org/viewvc?view=revision&revision=1167627 http://svn.apache.org/viewvc?view=revision&revision=1167628 impress212: DffPropSet -> minor code improvements, removing table http://svn.apache.org/viewvc?view=revision&revision=1167634 impress212: #158494# fixed excel import (text rotation) http://svn.apache.org/viewvc?view=revision&revision=1167638 Patches contributed by Armin Le Grand Svg: Reintegrated Svg replacement from /branches/alg/svgreplavement http://svn.apache.org/viewvc?view=revision&revision=1220836 #118728# changed indentifying definitions for Svg file detection http://svn.apache.org/viewvc?view=revision&revision=1229961 #118838# LineGeometry creation for complicated cases optimized to create single Polygons http://svn.apache.org/viewvc?view=revision&revision=1236232 #119176# corrected file type detection for SVG for svg files without xml header http://svn.apache.org/viewvc?view=revision&revision=1309445 #118728# Extended Svg file detection http://svn.apache.org/viewvc?view=revision&revision=1230531 #118529# solve break converters and convert commands for OLEs and images http://svn.apache.org/viewvc?view=revision&revision=1186168 svg: added WaE changes from branch svgreplacement to trunc http://svn.apache.org/viewvc?view=revision&revision=1222974 svg: corrected missing member initialization http://svn.apache.org/viewvc?view=revision&revision=1226134 fix for #118525#: Using primitives for chart sub-geometry visualisation http://svn.apache.org/viewvc?view=revision&revision=1226879 #118898# Adapted ImpGraphic::ImplGetBitmap to correctly convert metafiles to bitmapEx ... http://svn.apache.org/viewvc?view=revision&revision=1293316 fix for #118525#: removed no longer used variable maOriginalMapMode, one more exception eliminated http://svn.apache.org/viewvc?view=revision&revision=1227097 #16758# Added buffering to the VDev usages of the VclProcessor2D derivates... http://svn.apache.org/viewvc?view=revision&revision=1229521 #116758# Secured VDev buffer device to Vcl deinit http://svn.apache.org/viewvc?view=revision&revision=1230574 #116758# added remembering allocated VDevs for VDevBuffer to be able to also delete these when vcl goes down; it should never happen, but You never know http://svn.apache.org/viewvc?view=revision&revision=1230927 #118730# Changed SvgClipPathNode to use MaskPrimitive2D for primitive representation instead of TransparencePrimitive2D http://svn.apache.org/viewvc?view=revision&revision=1231198 #118822# secured 3D geometry creation (slices) by subdividing the 2D source polyPolygon early http://svn.apache.org/viewvc?view=revision&revision=1234749 #118829# enhanced Svg gradient quality, obstacles avoided http://svn.apache.org/viewvc?view=revision&revision=1235361 #118834# Unified usage of TextBreakupHelper as single tooling class for i18n text primitive breakup http://svn.apache.org/viewvc?view=revision&revision=1236110 #118853# added square pixel size limit to conversion of TransparencePrimitive2D to Metafile action http://svn.apache.org/viewvc?view=revision&revision=1237656 #118824# coreccted mirroring and boundrect when the graphicmanager is used for bitmap output http://svn.apache.org/viewvc?view=revision&revision=1240097 #115092# Corrected VclProcessor2D::RenderPolygonStrokePrimitive2D for various optimization scenarios http://svn.apache.org/viewvc?view=revision&revision=1241434 #118783# Corrected errors in ID strings, corrected Svg line/fill export, corrected polygon close state http://svn.apache.org/viewvc?view=revision&revision=1232006 #118796# corrected null-pointer usage in SVG text exporter http://svn.apache.org/viewvc?view=revision&revision=1240262 #118729# Use GraphicStreamUrl and GraphicUrl to allow multi image import with linked graphics, too http://svn.apache.org/viewvc?view=revision&revision=1229962 #118898# corrected error in GDIMetaFile::GetBoundRect in handling MetaFloatTransparentAction http://svn.apache.org/viewvc?view=revision&revision=1293349 #118855# Corrected handling of possibly created empty clipRegions after PolyPolygon clipping http://svn.apache.org/viewvc?view=revision&revision=1237725 #115962# Better (but not yet optimal, see comments in task) handling of MetaFloatTransparentAction in PDF export http://svn.apache.org/viewvc?view=revision&revision=1241078 IP clearance: #118466# This patch removes librsvg, libcroco, libgsf, ... http://svn.apache.org/viewvc?view=revision&revision=1200879 118779# Added svg content streaming in/out to ImpGraphic stream operators http://svn.apache.org/viewvc?view=revision&revision=1231908 linecap: correctons for WaE and mac drawing http://svn.apache.org/viewvc?view=revision&revision=1232793 svg: uses current system Dpi for Svg replacement image creation http://svn.apache.org/viewvc?view=revision&revision=1233948 Patches contributed by Mathias Bauer (and others) gnumake4 work variously http://svn.apache.org/viewvc?view=revision&revision=1394326 http://svn.apache.org/viewvc?view=revision&revision=1396797 http://svn.apache.org/viewvc?view=revision&revision=1397315 http://svn.apache.org/viewvc?view=revision&revision=1394326 Remove duplicate header includes. cws mba34issues01: #i117720#: convert assertion into warning http://svn.apache.org/viewvc?view=revision&revision=1172352 118485 - Styles for OLEs are not saved. Submitted by Armin Le Grand. http://svn.apache.org/viewvc?view=revision&revision=1182166 cws mba34issues01: #i117714#: remove assertion http://svn.apache.org/viewvc?view=revision&revision=1172357 Patch contributed by Jurgen Schmidt add some additional checks to ensure proper reading operations http://svn.apache.org/viewvc?view=revision&revision=1209022 mostly prefer our stream / bounds checking work. Patches contributed by Herbert Duerr #i118816# add clarifying comment regarding Font::*Color*() methods http://svn.apache.org/viewvc?view=revision&revision=1233833 extend macro->string handling for empty strings http://svn.apache.org/viewvc?view=revision&revision=1175801 avoid magic constants for SALCOLOR_NONE http://svn.apache.org/viewvc?view=revision&revision=1177543 initialize slant properly in ImplFontMetricData constructor (author=iorsh) http://svn.apache.org/viewvc?view=revision&revision=1177551 #i118675# make check for extension updates more stable http://svn.apache.org/viewvc?view=revision&revision=1214797 #a118617# remove VBasicEventListener.dll binary There are no known users depending on its CLSID http://svn.apache.org/viewvc?view=revision&revision=1203697 Patches contributed by Ariel Constenla-Haile Fix build breaker on Linux/gcc http://svn.apache.org/viewvc?view=revision&revision=1221104 Fix crash when trying to instantiate css.graphic.GraphicRasterizer_RSVG http://svn.apache.org/viewvc?view=revision&revision=1215559 Patches contributed by Oliver-Rainer Wittmann sw34bf06: #i117962# - method <SwFlyFrm::IsPaint(..)> - consider instances of <SwFlyDrawObj> http://svn.apache.org/viewvc?view=revision&revision=1172120 sw34bf06: #i117783# - Writer's implementation of XPagePrintable - apply print settings to new printing routines http://svn.apache.org/viewvc?view=revision&revision=1172115 gnumake4 work variously from Hans-Joachim Lankenau http://svn.apache.org/viewvc?view=revision&revision=1397315 http://svn.apache.org/viewvc?view=revision&revision=1396797 http://svn.apache.org/viewvc?view=revision&revision=1396782 http://svn.apache.org/viewvc?view=revision&revision=1394707 plus some amount of re-splitting of legacy headers. Patch contributed by Pavel Janik WaE: Remove unused variables. http://svn.apache.org/viewvc?view=revision&revision=1230697 Patches contributed by Takashi Ono mingwport35: i#117795: MinGW port fix for vcl2gnumake http://svn.apache.org/viewvc?view=revision&revision=1172091 mingwport35: i#117795: MinGW port fix for vcl2gnumake http://svn.apache.org/viewvc?view=revision&revision=1172091 Patch contributed by Christian Lippka impress212: #i98044# re enable Text menu for outline and title shapes http://svn.apache.org/viewvc?view=revision&revision=1167639 Patch contributed by Andre Fischer 118674: Made category B code optional and disabled by default. http://svn.apache.org/viewvc?view=revision&revision=1215131 118881: Ignore empty paragraphs after bullets. http://svn.apache.org/viewvc?view=revision&revision=1296205 Patches contributed by Philipp Lohmann ooo340fixes: #i117780# use rtl allocator http://svn.apache.org/viewvc?view=revision&revision=1172087 ooo34gsl02: #i117807# fix an off by one error (index actually inside the pfb section header) http://svn.apache.org/viewvc?view=revision&revision=1167576 various cleanups, related compilation fixes, warning cleanups, re-working of obsolete stl template pieces to use boost instead, changed string classes, re-adapt KDE about data, about dialog, fixing warnings, and other fixes & improvements. Disable svg import / render for about/ branding code-paths for now. Restore full icon theme set. Remove OS/2 conditionals and sources. Remove conflicting gtk/full-screen monitors support. Retain existing svg rasterizer files - temporarily disabled. Standardize stringificaiton and fixup dllpostfix issues. Rename SvgGradientHelper::== to equalTo to avoid overloading issues. Use the flat GdiPlus API for LineCaps calls.
2012-10-09 12:22:23 +01:00
/*
* This file is part of the LibreOffice project.
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*
* This file incorporates work covered by the following license notice:
*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed
* with this work for additional information regarding copyright
* ownership. The ASF licenses this file to you under the Apache
* License, Version 2.0 (the "License"); you may not use this file
* except in compliance with the License. You may obtain a copy of
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
*/
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
#include "genericpropertyhandler.hxx"
#include "formmetadata.hxx"
#include "handlerhelper.hxx"
#include <com/sun/star/container/XHierarchicalNameAccess.hpp>
#include <com/sun/star/reflection/XEnumTypeDescription.hpp>
#include <com/sun/star/beans/theIntrospection.hpp>
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
#include <com/sun/star/inspection/PropertyControlType.hpp>
#include <com/sun/star/inspection/XHyperlinkControl.hpp>
#include <com/sun/star/awt/XActionListener.hpp>
#include <com/sun/star/script/Converter.hpp>
#include <com/sun/star/util/URLTransformer.hpp>
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
#include <com/sun/star/util/XURLTransformer.hpp>
#include <com/sun/star/frame/Desktop.hpp>
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
#include <com/sun/star/frame/XDispatchProvider.hpp>
#include <cppuhelper/supportsservice.hxx>
#include <comphelper/extract.hxx>
#include <tools/debug.hxx>
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
#include <algorithm>
2011-02-08 19:22:43 +01:00
#include <o3tl/compat_functional.hxx>
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
extern "C" void SAL_CALL createRegistryInfo_GenericPropertyHandler()
{
::pcr::OAutoRegistration< ::pcr::GenericPropertyHandler > aAutoRegistration;
}
namespace pcr
{
using namespace ::com::sun::star::uno;
using namespace ::com::sun::star::beans;
using namespace ::com::sun::star::script;
using namespace ::com::sun::star::frame;
using namespace ::com::sun::star::lang;
using namespace ::com::sun::star::util;
using namespace ::com::sun::star::container;
using namespace ::com::sun::star::reflection;
using namespace ::com::sun::star::inspection;
using ::com::sun::star::awt::XActionListener;
using ::com::sun::star::awt::ActionEvent;
class EnumRepresentation : public IPropertyEnumRepresentation
{
private:
oslInterlockedCount m_refCount;
Reference< XEnumTypeDescription > m_xTypeDescription;
Type m_aEnumType;
public:
EnumRepresentation( const Reference< XComponentContext >& _rxContext, const Type& _rEnumType );
// IPropertyEnumRepresentation implementqation
virtual ::std::vector< OUString >
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
SAL_CALL getDescriptions() const;
virtual void SAL_CALL getValueFromDescription( const OUString& _rDescription, ::com::sun::star::uno::Any& _out_rValue ) const;
virtual OUString SAL_CALL getDescriptionForValue( const ::com::sun::star::uno::Any& _rEnumValue ) const;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
// IReference implementqation
virtual oslInterlockedCount SAL_CALL acquire();
virtual oslInterlockedCount SAL_CALL release();
private:
void impl_getValues( Sequence< sal_Int32 >& _out_rValues ) const;
private:
EnumRepresentation(); // never implemented
EnumRepresentation( const EnumRepresentation& ); // never implemented
EnumRepresentation& operator=( const EnumRepresentation& ); // never implemented
};
EnumRepresentation::EnumRepresentation( const Reference< XComponentContext >& _rxContext, const Type& _rEnumType )
:m_refCount( 0 )
,m_aEnumType( _rEnumType )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
try
{
if ( _rxContext.is() )
{
Reference< XHierarchicalNameAccess > xTypeDescProv(
_rxContext->getValueByName("/singletons/com.sun.star.reflection.theTypeDescriptionManager"),
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
UNO_QUERY_THROW );
m_xTypeDescription = Reference< XEnumTypeDescription >( xTypeDescProv->getByHierarchicalName( m_aEnumType.getTypeName() ), UNO_QUERY_THROW );
}
}
catch( const Exception& )
{
OSL_FAIL( "EnumRepresentation::EnumRepresentation: caught an exception!" );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
}
::std::vector< OUString > EnumRepresentation::getDescriptions() const
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
Sequence< OUString > aNames;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
try
{
if ( m_xTypeDescription.is() )
aNames = m_xTypeDescription->getEnumNames();
}
catch( const Exception& )
{
OSL_FAIL( "EnumRepresentation::getDescriptions: caught an exception!" );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
return ::std::vector< OUString >( aNames.getConstArray(), aNames.getConstArray() + aNames.getLength() );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
void EnumRepresentation::impl_getValues( Sequence< sal_Int32 >& _out_rValues ) const
{
_out_rValues.realloc( 0 );
try
{
if ( m_xTypeDescription.is() )
_out_rValues = m_xTypeDescription->getEnumValues();
}
catch( const Exception& )
{
OSL_FAIL( "EnumRepresentation::impl_getValues: caught an exception!" );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
}
void EnumRepresentation::getValueFromDescription( const OUString& _rDescription, Any& _out_rValue ) const
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
::std::vector< OUString > aDescriptions( getDescriptions() );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
sal_Int32 index = ::std::find( aDescriptions.begin(), aDescriptions.end(),
_rDescription ) - aDescriptions.begin();
Sequence< sal_Int32 > aValues;
impl_getValues( aValues );
if ( ( index >= 0 ) && ( index < aValues.getLength() ) )
_out_rValue = ::cppu::int2enum( aValues[ index ], m_aEnumType );
else
{
2011-03-01 17:55:09 +01:00
OSL_FAIL( "EnumRepresentation::getValueFromDescription: cannot convert!" );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
_out_rValue.clear();
}
}
OUString EnumRepresentation::getDescriptionForValue( const Any& _rEnumValue ) const
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
OUString sDescription;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
sal_Int32 nAsInt = 0;
OSL_VERIFY( ::cppu::enum2int( nAsInt, _rEnumValue ) );
Sequence< sal_Int32 > aValues;
impl_getValues( aValues );
sal_Int32 index = ::std::find( aValues.getConstArray(), aValues.getConstArray() + aValues.getLength(),
nAsInt ) - aValues.getConstArray();
::std::vector< OUString > aDescriptions( getDescriptions() );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
if ( ( index >= 0 ) && ( index < (sal_Int32)aDescriptions.size() ) )
sDescription = aDescriptions[ index ];
else
2008-10-28 15:03:16 +00:00
{
2011-03-01 17:55:09 +01:00
OSL_FAIL( "EnumRepresentation::getDescriptionForValue: cannot convert!" );
2008-10-28 15:03:16 +00:00
}
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
return sDescription;
}
oslInterlockedCount SAL_CALL EnumRepresentation::acquire()
{
return osl_atomic_increment( &m_refCount );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
oslInterlockedCount SAL_CALL EnumRepresentation::release()
{
if ( 0 == osl_atomic_decrement( &m_refCount ) )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
delete this;
return 0;
}
return m_refCount;
}
typedef ::cppu::WeakImplHelper1 < XActionListener
> UrlClickHandler_Base;
class UrlClickHandler : public UrlClickHandler_Base
{
Reference<XComponentContext> m_xContext;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
public:
UrlClickHandler( const Reference<XComponentContext>& _rContext, const Reference< XHyperlinkControl >& _rxControl );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
protected:
~UrlClickHandler();
// XActionListener
virtual void SAL_CALL actionPerformed( const ActionEvent& rEvent ) throw (RuntimeException, std::exception);
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
// XEventListener
virtual void SAL_CALL disposing( const EventObject& Source ) throw (RuntimeException, std::exception);
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
protected:
void impl_dispatch_throw( const OUString& _rURL );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
};
UrlClickHandler::UrlClickHandler( const Reference<XComponentContext>& _rContext, const Reference< XHyperlinkControl >& _rxControl )
:m_xContext( _rContext )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
if ( !_rxControl.is() )
throw NullPointerException();
osl_atomic_increment( &m_refCount );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
_rxControl->addActionListener( this );
}
osl_atomic_decrement( &m_refCount );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
OSL_ENSURE( m_refCount > 0, "UrlClickHandler::UrlClickHandler: leaking!" );
}
UrlClickHandler::~UrlClickHandler()
{
}
void SAL_CALL UrlClickHandler::actionPerformed( const ActionEvent& rEvent ) throw (RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
Reference< XPropertyControl > xControl( rEvent.Source, UNO_QUERY_THROW );
Any aControlValue( xControl->getValue() );
OUString sURL;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
if ( aControlValue.hasValue() && !( aControlValue >>= sURL ) )
throw RuntimeException( OUString(), *this );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
if ( sURL.isEmpty() )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
return;
impl_dispatch_throw( sURL );
}
void SAL_CALL UrlClickHandler::disposing( const EventObject& /*Source*/ ) throw (RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
// not interested in
}
void UrlClickHandler::impl_dispatch_throw( const OUString& _rURL )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
Reference< XURLTransformer > xTransformer( URLTransformer::create(m_xContext) );
URL aURL; aURL.Complete = ".uno:OpenHyperlink";
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
xTransformer->parseStrict( aURL );
Reference< XDesktop2 > xDispProv = Desktop::create( m_xContext );
Reference< XDispatch > xDispatch( xDispProv->queryDispatch( aURL, OUString(), 0 ), UNO_QUERY_THROW );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
Sequence< PropertyValue > aDispatchArgs(1);
aDispatchArgs[0].Name = "URL";
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
aDispatchArgs[0].Value <<= _rURL;
xDispatch->dispatch( aURL, aDispatchArgs );
}
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
GenericPropertyHandler::GenericPropertyHandler( const Reference< XComponentContext >& _rxContext )
:GenericPropertyHandler_Base( m_aMutex )
,m_xContext( _rxContext )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
,m_aPropertyListeners( m_aMutex )
,m_bPropertyMapInitialized( false )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
m_xTypeConverter = Converter::create(_rxContext);
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
GenericPropertyHandler::~GenericPropertyHandler()
{
}
OUString SAL_CALL GenericPropertyHandler::getImplementationName( ) throw (RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
return getImplementationName_static();
}
::sal_Bool SAL_CALL GenericPropertyHandler::supportsService( const OUString& ServiceName ) throw (RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
return cppu::supportsService(this, ServiceName);
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
Sequence< OUString > SAL_CALL GenericPropertyHandler::getSupportedServiceNames( ) throw (RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
return getSupportedServiceNames_static();
}
OUString SAL_CALL GenericPropertyHandler::getImplementationName_static( ) throw (RuntimeException)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
return OUString( "com.sun.star.comp.extensions.GenericPropertyHandler" );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
Sequence< OUString > SAL_CALL GenericPropertyHandler::getSupportedServiceNames_static( ) throw (RuntimeException)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
Sequence< OUString > aSupported( 1 );
aSupported[0] = "com.sun.star.inspection.GenericPropertyHandler";
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
return aSupported;
}
Reference< XInterface > SAL_CALL GenericPropertyHandler::Create( const Reference< XComponentContext >& _rxContext )
{
return *( new GenericPropertyHandler( _rxContext ) );
}
void SAL_CALL GenericPropertyHandler::inspect( const Reference< XInterface >& _rxIntrospectee ) throw (RuntimeException, NullPointerException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
::osl::MutexGuard aGuard( m_aMutex );
if ( !_rxIntrospectee.is() )
throw NullPointerException();
// revoke old property change listeners
::cppu::OInterfaceIteratorHelper iterRemove( m_aPropertyListeners );
::cppu::OInterfaceIteratorHelper iterReAdd( m_aPropertyListeners ); // this holds a copy of the container ...
while ( iterRemove.hasMoreElements() )
m_xComponent->removePropertyChangeListener( OUString(), static_cast< XPropertyChangeListener* >( iterRemove.next() ) );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
m_xComponentIntrospectionAccess.clear();
m_xComponent.clear();
m_xPropertyState.clear();
// create an introspection adapter for the component
Reference< XIntrospection > xIntrospection = theIntrospection::get( m_xContext );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
Reference< XIntrospectionAccess > xIntrospectionAccess( xIntrospection->inspect( makeAny( _rxIntrospectee ) ) );
if ( !xIntrospectionAccess.is() )
throw RuntimeException("The introspection service could not handle the given component.", *this );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
m_xComponent = Reference< XPropertySet >( xIntrospectionAccess->queryAdapter( cppu::UnoType<XPropertySet>::get() ), UNO_QUERY_THROW );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
// now that we survived so far, remember m_xComponentIntrospectionAccess
m_xComponentIntrospectionAccess = xIntrospectionAccess;
m_xPropertyState = m_xPropertyState.query( m_xComponent );
m_bPropertyMapInitialized = false;
m_aProperties.clear();
// re-add the property change listeners
while ( iterReAdd.hasMoreElements() )
m_xComponent->addPropertyChangeListener( OUString(), static_cast< XPropertyChangeListener* >( iterReAdd.next() ) );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
Any SAL_CALL GenericPropertyHandler::getPropertyValue( const OUString& _rPropertyName ) throw (UnknownPropertyException, RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
::osl::MutexGuard aGuard( m_aMutex );
if ( !m_xComponent.is() )
throw UnknownPropertyException();
return m_xComponent->getPropertyValue( _rPropertyName );
}
void SAL_CALL GenericPropertyHandler::setPropertyValue( const OUString& _rPropertyName, const Any& _rValue ) throw (UnknownPropertyException, RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
::osl::MutexGuard aGuard( m_aMutex );
if ( !m_xComponent.is() )
throw UnknownPropertyException();
m_xComponent->setPropertyValue( _rPropertyName, _rValue );
}
::rtl::Reference< IPropertyEnumRepresentation > GenericPropertyHandler::impl_getEnumConverter( const Type& _rEnumType )
{
::rtl::Reference< IPropertyEnumRepresentation >& rConverter = m_aEnumConverters[ _rEnumType ];
if ( !rConverter.is() )
rConverter = new EnumRepresentation( m_xContext, _rEnumType );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
return rConverter;
}
Any SAL_CALL GenericPropertyHandler::convertToPropertyValue( const OUString& _rPropertyName, const Any& _rControlValue ) throw (UnknownPropertyException, RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
::osl::MutexGuard aGuard( m_aMutex );
const_cast< GenericPropertyHandler* >( this )->impl_ensurePropertyMap();
PropertyMap::const_iterator pos = m_aProperties.find( _rPropertyName );
if ( pos == m_aProperties.end() )
throw UnknownPropertyException();
Any aPropertyValue;
if ( !_rControlValue.hasValue() )
// NULL is converted to NULL
return aPropertyValue;
if ( pos->second.Type.getTypeClass() == TypeClass_ENUM )
{
OUString sControlValue;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
OSL_VERIFY( _rControlValue >>= sControlValue );
impl_getEnumConverter( pos->second.Type )->getValueFromDescription( sControlValue, aPropertyValue );
}
else
aPropertyValue = PropertyHandlerHelper::convertToPropertyValue( m_xContext, m_xTypeConverter, pos->second, _rControlValue );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
return aPropertyValue;
}
Any SAL_CALL GenericPropertyHandler::convertToControlValue( const OUString& _rPropertyName, const Any& _rPropertyValue, const Type& _rControlValueType ) throw (UnknownPropertyException, RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
::osl::MutexGuard aGuard( m_aMutex );
const_cast< GenericPropertyHandler* >( this )->impl_ensurePropertyMap();
PropertyMap::const_iterator pos = m_aProperties.find( _rPropertyName );
if ( pos == m_aProperties.end() )
throw UnknownPropertyException();
Any aControlValue;
if ( !_rPropertyValue.hasValue() )
// NULL is converted to NULL
return aControlValue;
if ( pos->second.Type.getTypeClass() == TypeClass_ENUM )
{
aControlValue <<= impl_getEnumConverter( pos->second.Type )->getDescriptionForValue( _rPropertyValue );
}
else
aControlValue = PropertyHandlerHelper::convertToControlValue( m_xContext, m_xTypeConverter, _rPropertyValue, _rControlValueType );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
return aControlValue;
}
PropertyState SAL_CALL GenericPropertyHandler::getPropertyState( const OUString& _rPropertyName ) throw (UnknownPropertyException, RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
::osl::MutexGuard aGuard( m_aMutex );
PropertyState eState = PropertyState_DIRECT_VALUE;
if ( m_xPropertyState.is() )
eState = m_xPropertyState->getPropertyState( _rPropertyName );
return eState;
}
void SAL_CALL GenericPropertyHandler::addPropertyChangeListener( const Reference< XPropertyChangeListener >& _rxListener ) throw (RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
if ( !_rxListener.is() )
throw NullPointerException();
::osl::MutexGuard aGuard( m_aMutex );
m_aPropertyListeners.addInterface( _rxListener );
if ( m_xComponent.is() )
{
try
{
m_xComponent->addPropertyChangeListener( OUString(), _rxListener );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
catch( const UnknownPropertyException& )
{
OSL_FAIL( "GenericPropertyHandler::addPropertyChangeListener:\nThe inspected component does not allow registering for all properties at once! This violates the interface contract!" );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
}
}
void SAL_CALL GenericPropertyHandler::removePropertyChangeListener( const Reference< XPropertyChangeListener >& _rxListener ) throw (RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
::osl::MutexGuard aGuard( m_aMutex );
if ( m_xComponent.is() )
{
try
{
m_xComponent->removePropertyChangeListener( OUString(), _rxListener );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
catch( const UnknownPropertyException& )
{
OSL_FAIL( "GenericPropertyHandler::removePropertyChangeListener:\nThe inspected component does not allow de-registering for all properties at once! This violates the interface contract!" );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
}
m_aPropertyListeners.removeInterface( _rxListener );
}
void GenericPropertyHandler::impl_ensurePropertyMap()
{
if ( !m_bPropertyMapInitialized )
{
m_bPropertyMapInitialized = true;
try
{
Reference< XPropertySetInfo > xPSI;
if ( m_xComponent.is() )
xPSI = m_xComponent->getPropertySetInfo();
Sequence< Property > aProperties;
if ( xPSI.is() )
aProperties = xPSI->getProperties();
DBG_ASSERT( aProperties.getLength(), "GenericPropertyHandler::getSupportedProperties: no properties!" );
for ( const Property* pProperties = aProperties.getConstArray();
pProperties != aProperties.getConstArray() + aProperties.getLength();
++pProperties
)
{
switch ( pProperties->Type.getTypeClass() )
{
case TypeClass_BOOLEAN:
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:
case TypeClass_ENUM:
case TypeClass_STRING:
// allowed, we can handle this type
break;
case TypeClass_SEQUENCE:
{
TypeClass eElementTypeClass = ::comphelper::getSequenceElementType( pProperties->Type ).getTypeClass();
if ( ( eElementTypeClass != TypeClass_STRING )
&& ( eElementTypeClass != TypeClass_BYTE )
&& ( eElementTypeClass != TypeClass_SHORT )
&& ( eElementTypeClass != TypeClass_UNSIGNED_SHORT )
&& ( eElementTypeClass != TypeClass_LONG )
&& ( eElementTypeClass != TypeClass_UNSIGNED_LONG )
)
// can only handle the above
continue;
}
break;
default:
// next property, we don't support this type
continue;
}
m_aProperties.insert( PropertyMap::value_type( pProperties->Name, *pProperties ) );
}
}
catch( const Exception& )
{
OSL_FAIL( "GenericPropertyHandler::impl_ensurePropertyMap: caught an exception!" );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
}
}
Sequence< Property > SAL_CALL GenericPropertyHandler::getSupportedProperties() throw (RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
::osl::MutexGuard aGuard( m_aMutex );
const_cast< GenericPropertyHandler* >( this )->impl_ensurePropertyMap();
Sequence< Property > aReturn( m_aProperties.size() );
::std::transform( m_aProperties.begin(), m_aProperties.end(),
2011-02-08 19:22:43 +01:00
aReturn.getArray(), ::o3tl::select2nd< PropertyMap::value_type >() );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
return aReturn;
}
Sequence< OUString > SAL_CALL GenericPropertyHandler::getSupersededProperties( ) throw (RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
// no superseded properties at all. This handler offers the very basic PropertyHandler
// functionality, so it's much more likely that other handlers want to supersede
// *our* properties ....
return Sequence< OUString >( );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
Sequence< OUString > SAL_CALL GenericPropertyHandler::getActuatingProperties( ) throw (RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
// This basic PropertyHandler implementation is too dumb^Wgeneric to know
// anything about property dependencies
return Sequence< OUString >( );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
LineDescriptor SAL_CALL GenericPropertyHandler::describePropertyLine( const OUString& _rPropertyName,
const Reference< XPropertyControlFactory >& _rxControlFactory )
throw (UnknownPropertyException, NullPointerException, RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
if ( !_rxControlFactory.is() )
throw NullPointerException();
::osl::MutexGuard aGuard( m_aMutex );
const_cast< GenericPropertyHandler* >( this )->impl_ensurePropertyMap();
PropertyMap::const_iterator pos = m_aProperties.find( _rPropertyName );
if ( pos == m_aProperties.end() )
throw UnknownPropertyException();
LineDescriptor aDescriptor;
aDescriptor.DisplayName = _rPropertyName;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
switch ( pos->second.Type.getTypeClass() )
{
case TypeClass_ENUM:
aDescriptor.Control = PropertyHandlerHelper::createListBoxControl( _rxControlFactory,
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
impl_getEnumConverter( pos->second.Type )->getDescriptions(),
PropertyHandlerHelper::requiresReadOnlyControl( pos->second.Attributes ),
sal_False );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
break;
case TypeClass_STRING:
{
// some special handling for URL properties
bool bIsURLProperty = _rPropertyName.endsWithAsciiL( "URL", 3 );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
if ( bIsURLProperty )
{
aDescriptor.Control = _rxControlFactory->createPropertyControl(
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
PropertyControlType::HyperlinkField, PropertyHandlerHelper::requiresReadOnlyControl( pos->second.Attributes ) );
Reference< XHyperlinkControl > xControl( aDescriptor.Control, UNO_QUERY_THROW );
Reference< XActionListener > xEnsureDelete( new UrlClickHandler( m_xContext, xControl ) );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
}
break;
default:
break;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
// fallback
if ( !aDescriptor.Control.is() )
PropertyHandlerHelper::describePropertyLine( pos->second, aDescriptor, _rxControlFactory );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
aDescriptor.Category = "General";
return aDescriptor;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
::sal_Bool SAL_CALL GenericPropertyHandler::isComposable( const OUString& /*_rPropertyName*/ ) throw (UnknownPropertyException, RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
return sal_False;
}
InteractiveSelectionResult SAL_CALL GenericPropertyHandler::onInteractivePropertySelection( const OUString& /*_rPropertyName*/, sal_Bool /*_bPrimary*/, Any& /*_rData*/, const Reference< XObjectInspectorUI >& /*_rxInspectorUI*/ ) throw (UnknownPropertyException, NullPointerException, RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
2011-03-01 17:55:09 +01:00
OSL_FAIL( "GenericPropertyHandler::onInteractivePropertySelection: I'm too dumb to know anything about property browse buttons!" );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
return InteractiveSelectionResult_Cancelled;
}
void SAL_CALL GenericPropertyHandler::actuatingPropertyChanged( const OUString& /*_rActuatingPropertyName*/, const Any& /*_rNewValue*/, const Any& /*_rOldValue*/, const Reference< XObjectInspectorUI >& /*_rxInspectorUI*/, sal_Bool /*_bFirstTimeInit*/ ) throw (NullPointerException, RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
2011-03-01 17:55:09 +01:00
OSL_FAIL( "GenericPropertyHandler::actuatingPropertyChanged: no no no, I did not register for any actuating properties!" );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
}
sal_Bool SAL_CALL GenericPropertyHandler::suspend( sal_Bool /*_bSuspend*/ ) throw (RuntimeException, std::exception)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control 2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component 2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications 2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications 2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters 2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers 2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 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:02 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:05 +00:00
{
return sal_True;
}
void SAL_CALL GenericPropertyHandler::disposing()
{
m_aPropertyListeners.clear();
// not disposeAndClear: the listeners are (virtually) listeners at our introspectee, not
// at this handler instance
}
IMPLEMENT_FORWARD_XCOMPONENT( GenericPropertyHandler, GenericPropertyHandler_Base );
} // namespace pcr
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */