2010-10-12 15:57:08 +02:00
/* -*- 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>
2014-03-07 10:31:07 +01:00
# 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>
2012-08-21 08:07:58 +02:00
# include <com/sun/star/script/Converter.hpp>
2012-06-01 15:15:25 +02:00
# 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>
2012-12-14 12:58:00 +02:00
# 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>
2014-01-25 14:49:15 -02:00
# include <cppuhelper/supportsservice.hxx>
2011-01-28 12:49:53 +01:00
# include <comphelper/extract.hxx>
2014-01-25 14:49:15 -02:00
# 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
2013-04-07 12:06:47 +02:00
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 ;
2013-04-07 12:06:47 +02:00
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 )
2008-01-14 13:58:59 +00:00
: 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 (
2013-06-29 21:24:12 +02:00
_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 & )
{
2011-03-19 14:06:18 +01:00
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
}
}
2013-04-07 12:06:47 +02: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
{
2013-04-07 12:06:47 +02: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 & )
{
2011-03-19 14:06:18 +01:00
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
}
2013-04-07 12:06:47 +02: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 & )
{
2011-03-19 14:06:18 +01:00
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
}
}
2013-04-07 12:06:47 +02: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
{
2013-04-07 12:06:47 +02: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 ( ) ;
}
}
2013-04-07 12:06:47 +02:00
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
{
2013-04-07 12:06:47 +02: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 ( ) ;
2013-04-07 12:06:47 +02: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
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 ( )
{
2012-09-22 01:51:12 -05:00
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 ( )
{
2012-09-22 01:51:12 -05:00
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
{
2013-06-03 15:34:00 +02:00
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 :
2013-06-03 15:34:00 +02:00
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
2014-02-25 21:31:58 +01:00
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
2014-02-25 21:31:58 +01:00
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 :
2013-04-07 12:06:47 +02:00
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
} ;
2014-01-25 14:49:15 -02:00
2013-06-03 15:34:00 +02: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 ( ) ;
2012-09-22 01:51:12 -05:00
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 ) ;
}
2012-09-22 01:51:12 -05:00
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 ( )
{
}
2014-02-25 21:31:58 +01:00
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 ( ) ) ;
2013-04-07 12:06:47 +02:00
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 ) )
2013-04-07 12:06:47 +02:00
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
2011-12-22 15:35:41 -02: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 ) ;
}
2014-02-25 21:31:58 +01:00
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
}
2013-04-07 12:06:47 +02:00
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
{
2013-06-03 15:34:00 +02:00
Reference < XURLTransformer > xTransformer ( URLTransformer : : create ( m_xContext ) ) ;
2013-11-04 11:55:50 +02:00
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 ) ;
2013-06-03 15:34:00 +02:00
Reference < XDesktop2 > xDispProv = Desktop : : create ( m_xContext ) ;
2013-04-07 12:06:47 +02:00
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 ) ;
2013-11-04 11:55:50 +02:00
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 ) ;
}
2014-01-25 14:49:15 -02: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
GenericPropertyHandler : : GenericPropertyHandler ( const Reference < XComponentContext > & _rxContext )
: GenericPropertyHandler_Base ( m_aMutex )
2013-06-03 15:34:00 +02:00
, 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 )
2008-01-14 13:58:59 +00:00
, 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
{
2012-08-21 08:07:58 +02: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 ( )
{
}
2014-02-25 21:31:58 +01:00
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 ( ) ;
}
2014-02-25 21:31:58 +01:00
: : 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
{
2014-01-25 14:49:15 -02: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
}
2014-02-25 21:31:58 +01: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 ( ) ;
}
2013-04-07 12:06:47 +02:00
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
{
2013-04-07 12:06:47 +02: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
}
2013-04-07 12:06:47 +02: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
{
2013-04-07 12:06:47 +02:00
Sequence < OUString > aSupported ( 1 ) ;
2013-11-04 11:55:50 +02:00
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 ) ) ;
}
2014-02-25 21:31:58 +01:00
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 ( ) )
2013-04-07 12:06:47 +02:00
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
2014-03-07 10:31:07 +01:00
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 ( ) )
2013-06-29 21:24:12 +02:00
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
2013-12-12 11:09:57 +01: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 ( ) )
2013-04-07 12:06:47 +02:00
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
}
2014-02-25 21:31:58 +01: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 ) ;
}
2014-02-25 21:31:58 +01:00
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 ( ) )
2013-06-03 15:34:00 +02:00
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 ;
}
2014-02-25 21:31:58 +01:00
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 )
{
2013-04-07 12:06:47 +02:00
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
2013-06-03 15:34:00 +02:00
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 ;
}
2014-02-25 21:31:58 +01:00
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
2013-06-03 15:34:00 +02:00
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 ;
}
2014-02-25 21:31:58 +01:00
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 ;
}
2014-02-25 21:31:58 +01:00
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
{
2013-04-07 12:06:47 +02:00
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 & )
{
2011-03-12 11:29:14 +01:00
OSL_FAIL ( " GenericPropertyHandler::addPropertyChangeListener: \n The 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
}
}
}
2014-02-25 21:31:58 +01: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
{
2013-04-07 12:06:47 +02:00
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 & )
{
2011-03-12 11:29:14 +01:00
OSL_FAIL ( " GenericPropertyHandler::removePropertyChangeListener: \n The 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 & )
{
2011-03-19 14:06:18 +01:00
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
}
}
}
2014-02-25 21:31:58 +01: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 ;
}
2014-02-25 21:31:58 +01:00
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 ....
2013-04-07 12:06:47 +02:00
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
}
2014-02-25 21:31:58 +01: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
2013-04-07 12:06:47 +02:00
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
}
2013-04-07 12:06:47 +02:00
LineDescriptor SAL_CALL GenericPropertyHandler : : describePropertyLine ( const OUString & _rPropertyName ,
2006-07-26 06:58:12 +00:00
const Reference < XPropertyControlFactory > & _rxControlFactory )
2014-02-25 21:31:58 +01:00
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 ( ) ;
2006-07-26 06:58:12 +00:00
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 :
2006-07-26 06:58:12 +00:00
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 ( ) ,
2006-12-13 15:57:21 +00:00
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
2014-03-18 16:12:40 +02:00
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 )
{
2006-07-26 06:58:12 +00:00
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 ) ) ;
2006-07-26 06:58:12 +00:00
Reference < XHyperlinkControl > xControl ( aDescriptor . Control , UNO_QUERY_THROW ) ;
2013-06-03 15:34:00 +02:00
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 ;
2006-07-26 06:58:12 +00:00
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
2006-07-26 06:58:12 +00:00
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
2013-11-04 11:55:50 +02:00
aDescriptor . Category = " General " ;
2006-07-26 06:58:12 +00:00
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
}
2014-02-25 21:31:58 +01: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 ;
}
2014-02-25 21:31:58 +01:00
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 ;
}
2014-02-25 21:31:58 +01:00
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
}
2014-02-25 21:31:58 +01: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
2010-10-12 15:57:08 +02:00
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */