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 .
|
|
|
|
*/
|
2004-11-16 11:13:18 +00:00
|
|
|
|
2014-04-13 23:44:29 +02:00
|
|
|
#include <sal/config.h>
|
|
|
|
|
|
|
|
#include "pcrservices.hxx"
|
2004-11-16 11:13:18 +00:00
|
|
|
#include "submissionhandler.hxx"
|
|
|
|
#include "formmetadata.hxx"
|
|
|
|
#include "formstrings.hxx"
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
#include "handlerhelper.hxx"
|
2004-11-16 11:13:18 +00:00
|
|
|
|
|
|
|
#include <com/sun/star/form/FormButtonType.hpp>
|
|
|
|
#include <com/sun/star/container/XNamed.hpp>
|
|
|
|
#include <com/sun/star/container/XIndexAccess.hpp>
|
|
|
|
#include <com/sun/star/form/submission/XSubmissionSupplier.hpp>
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
#include <com/sun/star/inspection/XObjectInspectorUI.hpp>
|
2017-02-06 17:08:38 +01:00
|
|
|
#include <com/sun/star/lang/NullPointerException.hpp>
|
2004-11-16 11:13:18 +00:00
|
|
|
#include <tools/debug.hxx>
|
|
|
|
#include <rtl/ustrbuf.hxx>
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
extern "C" void SAL_CALL createRegistryInfo_SubmissionPropertyHandler()
|
|
|
|
{
|
|
|
|
::pcr::SubmissionPropertyHandler::registerImplementation();
|
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2004-11-16 11:13:18 +00:00
|
|
|
namespace pcr
|
|
|
|
{
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2004-11-16 11:13:18 +00:00
|
|
|
|
|
|
|
using namespace ::comphelper;
|
|
|
|
using namespace ::com::sun::star;
|
|
|
|
using namespace ::com::sun::star::uno;
|
|
|
|
using namespace ::com::sun::star::lang;
|
|
|
|
using namespace ::com::sun::star::beans;
|
|
|
|
using namespace ::com::sun::star::script;
|
|
|
|
using namespace ::com::sun::star::form;
|
|
|
|
using namespace ::com::sun::star::xforms;
|
|
|
|
using namespace ::com::sun::star::container;
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
using namespace ::com::sun::star::inspection;
|
2004-11-16 11:13:18 +00:00
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2004-11-16 11:13:18 +00:00
|
|
|
//= SubmissionHelper
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
SubmissionHelper::SubmissionHelper( ::osl::Mutex& _rMutex, const Reference< XPropertySet >& _rxIntrospectee, const Reference< frame::XModel >& _rxContextDocument )
|
|
|
|
:EFormsHelper( _rMutex, _rxIntrospectee, _rxContextDocument )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
|
|
|
OSL_ENSURE( canTriggerSubmissions( _rxIntrospectee, _rxContextDocument ),
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
"SubmissionHelper::SubmissionHelper: you should not have instantiated me!" );
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2004-11-16 11:13:18 +00:00
|
|
|
bool SubmissionHelper::canTriggerSubmissions( const Reference< XPropertySet >& _rxControlModel,
|
2014-06-05 08:15:03 +02:00
|
|
|
const Reference< frame::XModel >& _rxContextDocument )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
|
|
|
if ( !EFormsHelper::isEForm( _rxContextDocument ) )
|
|
|
|
return false;
|
|
|
|
|
|
|
|
try
|
|
|
|
{
|
|
|
|
Reference< submission::XSubmissionSupplier > xSubmissionSupp( _rxControlModel, UNO_QUERY );
|
|
|
|
if ( xSubmissionSupp.is() )
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
catch( const Exception& )
|
|
|
|
{
|
2011-03-19 14:06:18 +01:00
|
|
|
OSL_FAIL( "SubmissionHelper::canTriggerSubmissions: caught an exception!" );
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2004-11-16 11:13:18 +00:00
|
|
|
//= SubmissionPropertyHandler
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
SubmissionPropertyHandler::SubmissionPropertyHandler( const Reference< XComponentContext >& _rxContext )
|
|
|
|
:EditPropertyHandler_Base( _rxContext )
|
|
|
|
,OPropertyChangeListener( m_aMutex )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2004-11-16 11:13:18 +00:00
|
|
|
SubmissionPropertyHandler::~SubmissionPropertyHandler( )
|
|
|
|
{
|
|
|
|
disposeAdapter();
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
OUString SAL_CALL SubmissionPropertyHandler::getImplementationName_static( )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
2013-04-07 12:06:47 +02:00
|
|
|
return OUString( "com.sun.star.comp.extensions.SubmissionPropertyHandler" );
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
}
|
2004-11-16 11:13:18 +00:00
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
Sequence< OUString > SAL_CALL SubmissionPropertyHandler::getSupportedServiceNames_static( )
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
{
|
2015-11-15 12:22:28 +02:00
|
|
|
Sequence<OUString> aSupported { "com.sun.star.form.inspection.SubmissionPropertyHandler" };
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
return aSupported;
|
|
|
|
}
|
2004-11-16 11:13:18 +00:00
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
Any SAL_CALL SubmissionPropertyHandler::getPropertyValue( const OUString& _rPropertyName )
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
{
|
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2014-06-13 13:19:14 +01:00
|
|
|
PropertyId nPropId( impl_getPropertyId_throwUnknownProperty( _rPropertyName ) );
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
|
|
|
|
OSL_ENSURE( m_pHelper.get(), "SubmissionPropertyHandler::getPropertyValue: inconsistency!" );
|
2014-06-13 13:19:14 +01:00
|
|
|
// if we survived impl_getPropertyId_throwUnknownProperty, we should have a helper, since no helper implies no properties
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
|
|
|
|
Any aReturn;
|
2004-11-16 11:13:18 +00:00
|
|
|
try
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
switch ( nPropId )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_SUBMISSION_ID:
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
Reference< submission::XSubmissionSupplier > xSubmissionSupp( m_xComponent, UNO_QUERY );
|
2004-11-16 11:13:18 +00:00
|
|
|
OSL_ENSURE( xSubmissionSupp.is(), "SubmissionPropertyHandler::getPropertyValue: this should never happen ..." );
|
|
|
|
// this handler is not intended for components which are no XSubmissionSupplier
|
|
|
|
Reference< submission::XSubmission > xSubmission;
|
|
|
|
if ( xSubmissionSupp.is() )
|
|
|
|
xSubmission = xSubmissionSupp->getSubmission( );
|
|
|
|
aReturn <<= xSubmission;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_XFORMS_BUTTONTYPE:
|
|
|
|
{
|
|
|
|
FormButtonType eType = FormButtonType_PUSH;
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
OSL_VERIFY( m_xComponent->getPropertyValue( PROPERTY_BUTTONTYPE ) >>= eType );
|
2004-11-16 11:13:18 +00:00
|
|
|
if ( ( eType != FormButtonType_PUSH ) && ( eType != FormButtonType_SUBMIT ) )
|
|
|
|
eType = FormButtonType_PUSH;
|
|
|
|
aReturn <<= eType;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2011-03-01 17:55:09 +01:00
|
|
|
OSL_FAIL( "SubmissionPropertyHandler::getPropertyValue: cannot handle this property!" );
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
break;
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
catch( const Exception& )
|
|
|
|
{
|
2011-03-19 14:06:18 +01:00
|
|
|
OSL_FAIL( "SubmissionPropertyHandler::getPropertyValue: caught an exception!" );
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return aReturn;
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
void SAL_CALL SubmissionPropertyHandler::setPropertyValue( const OUString& _rPropertyName, const Any& _rValue )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2014-06-13 13:19:14 +01:00
|
|
|
PropertyId nPropId( impl_getPropertyId_throwUnknownProperty( _rPropertyName ) );
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
|
|
|
|
OSL_ENSURE( m_pHelper.get(), "SubmissionPropertyHandler::setPropertyValue: inconsistency!" );
|
2014-06-13 13:19:14 +01:00
|
|
|
// if we survived impl_getPropertyId_throwUnknownProperty, we should have a helper, since no helper implies no properties
|
2004-11-16 11:13:18 +00:00
|
|
|
|
|
|
|
try
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
switch ( nPropId )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_SUBMISSION_ID:
|
|
|
|
{
|
|
|
|
Reference< submission::XSubmission > xSubmission;
|
|
|
|
OSL_VERIFY( _rValue >>= xSubmission );
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
Reference< submission::XSubmissionSupplier > xSubmissionSupp( m_xComponent, UNO_QUERY );
|
2004-11-16 11:13:18 +00:00
|
|
|
OSL_ENSURE( xSubmissionSupp.is(), "SubmissionPropertyHandler::setPropertyValue: this should never happen ..." );
|
|
|
|
// this handler is not intended for components which are no XSubmissionSupplier
|
|
|
|
if ( xSubmissionSupp.is() )
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
{
|
2004-11-16 11:13:18 +00:00
|
|
|
xSubmissionSupp->setSubmission( xSubmission );
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
impl_setContextDocumentModified_nothrow();
|
|
|
|
}
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_XFORMS_BUTTONTYPE:
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
m_xComponent->setPropertyValue( PROPERTY_BUTTONTYPE, _rValue );
|
2004-11-16 11:13:18 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2011-03-19 14:06:18 +01:00
|
|
|
OSL_FAIL( "SubmissionPropertyHandler::setPropertyValue: cannot handle this id!" );
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
catch( const Exception& )
|
|
|
|
{
|
2011-03-19 14:06:18 +01:00
|
|
|
OSL_FAIL( "SubmissionPropertyHandler::setPropertyValue: caught an exception!" );
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
Sequence< OUString > SAL_CALL SubmissionPropertyHandler::getActuatingProperties( )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2004-11-16 11:13:18 +00:00
|
|
|
if ( !m_pHelper.get() )
|
2013-04-07 12:06:47 +02:00
|
|
|
return Sequence< OUString >();
|
2004-11-16 11:13:18 +00:00
|
|
|
|
2015-11-15 13:17:00 +02:00
|
|
|
Sequence<OUString> aReturn { PROPERTY_XFORMS_BUTTONTYPE };
|
2004-11-16 11:13:18 +00:00
|
|
|
return aReturn;
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
Sequence< OUString > SAL_CALL SubmissionPropertyHandler::getSupersededProperties( )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2004-11-16 11:13:18 +00:00
|
|
|
if ( !m_pHelper.get() )
|
2013-04-07 12:06:47 +02:00
|
|
|
return Sequence< OUString >();
|
2004-11-16 11:13:18 +00:00
|
|
|
|
2013-04-07 12:06:47 +02:00
|
|
|
Sequence< OUString > aReturn( 3 );
|
2004-11-16 11:13:18 +00:00
|
|
|
aReturn[ 0 ] = PROPERTY_TARGET_URL;
|
|
|
|
aReturn[ 1 ] = PROPERTY_TARGET_FRAME;
|
|
|
|
aReturn[ 2 ] = PROPERTY_BUTTONTYPE;
|
|
|
|
return aReturn;
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
void SubmissionPropertyHandler::onNewComponent()
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
2017-01-20 13:43:25 +02:00
|
|
|
if ( m_xPropChangeMultiplexer.is() )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
2017-01-20 13:43:25 +02:00
|
|
|
m_xPropChangeMultiplexer->dispose();
|
|
|
|
m_xPropChangeMultiplexer.clear();
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
EditPropertyHandler_Base::onNewComponent();
|
|
|
|
|
|
|
|
Reference< frame::XModel > xDocument( impl_getContextDocument_nothrow() );
|
|
|
|
DBG_ASSERT( xDocument.is(), "SubmissionPropertyHandler::onNewComponent: no document!" );
|
|
|
|
|
2014-01-06 14:10:06 +00:00
|
|
|
m_pHelper.reset();
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
|
|
|
|
if ( SubmissionHelper::canTriggerSubmissions( m_xComponent, xDocument ) )
|
|
|
|
{
|
|
|
|
m_pHelper.reset( new SubmissionHelper( m_aMutex, m_xComponent, xDocument ) );
|
|
|
|
|
2017-01-20 13:43:25 +02:00
|
|
|
m_xPropChangeMultiplexer = new OPropertyChangeMultiplexer( this, m_xComponent );
|
|
|
|
m_xPropChangeMultiplexer->addProperty( PROPERTY_BUTTONTYPE );
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
Sequence< Property > SAL_CALL SubmissionPropertyHandler::doDescribeSupportedProperties() const
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
2017-02-17 19:06:24 +02:00
|
|
|
std::vector< Property > aProperties;
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
if ( m_pHelper.get() )
|
|
|
|
{
|
2014-05-22 23:19:05 +02:00
|
|
|
implAddPropertyDescription( aProperties, PROPERTY_SUBMISSION_ID, cppu::UnoType<submission::XSubmission>::get() );
|
2014-05-11 10:09:04 +02:00
|
|
|
implAddPropertyDescription( aProperties, PROPERTY_XFORMS_BUTTONTYPE, ::cppu::UnoType<FormButtonType>::get() );
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
}
|
|
|
|
if ( aProperties.empty() )
|
|
|
|
return Sequence< Property >();
|
|
|
|
return Sequence< Property >( &(*aProperties.begin()), aProperties.size() );
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2013-04-07 12:06:47 +02:00
|
|
|
LineDescriptor SAL_CALL SubmissionPropertyHandler::describePropertyLine( const OUString& _rPropertyName,
|
2006-07-26 07:01:15 +00:00
|
|
|
const Reference< XPropertyControlFactory >& _rxControlFactory )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
|
|
|
if ( !_rxControlFactory.is() )
|
|
|
|
throw NullPointerException();
|
2004-11-16 11:13:18 +00:00
|
|
|
if ( !m_pHelper.get() )
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
RuntimeException();
|
2004-11-16 11:13:18 +00:00
|
|
|
|
2017-02-17 19:06:24 +02:00
|
|
|
std::vector< OUString > aListEntries;
|
2014-06-13 13:19:14 +01:00
|
|
|
PropertyId nPropId( impl_getPropertyId_throwUnknownProperty( _rPropertyName ) );
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
switch ( nPropId )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_SUBMISSION_ID:
|
2015-04-13 12:35:57 +02:00
|
|
|
m_pHelper.get()->getAllElementUINames( EFormsHelper::Submission, aListEntries, false );
|
2004-11-16 11:13:18 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_XFORMS_BUTTONTYPE:
|
|
|
|
{
|
|
|
|
// available options are nearly the same as for the "normal" button type, but only the
|
|
|
|
// first two options
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
aListEntries = m_pInfoService->getPropertyEnumRepresentations( PROPERTY_ID_BUTTONTYPE );
|
|
|
|
aListEntries.resize( 2 );
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2011-03-19 14:06:18 +01:00
|
|
|
OSL_FAIL( "SubmissionPropertyHandler::describePropertyLine: cannot handle this id!" );
|
2006-07-26 07:01:15 +00:00
|
|
|
return LineDescriptor();
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
|
2006-07-26 07:01:15 +00:00
|
|
|
LineDescriptor aDescriptor;
|
2014-04-30 11:46:15 +02:00
|
|
|
aDescriptor.Control = PropertyHandlerHelper::createListBoxControl( _rxControlFactory, aListEntries, false, true );
|
2006-07-26 07:01:15 +00:00
|
|
|
aDescriptor.DisplayName = m_pInfoService->getPropertyTranslation( nPropId );
|
2013-11-15 11:05:19 +02:00
|
|
|
aDescriptor.Category = "General";
|
2006-07-26 07:01:15 +00:00
|
|
|
aDescriptor.HelpURL = HelpIdUrl::getHelpURL( m_pInfoService->getPropertyHelpId( nPropId ) );
|
|
|
|
return aDescriptor;
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
void SAL_CALL SubmissionPropertyHandler::actuatingPropertyChanged( const OUString& _rActuatingPropertyName, const Any& _rNewValue, const Any& /*_rOldValue*/, const Reference< XObjectInspectorUI >& _rxInspectorUI, sal_Bool )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
if ( !_rxInspectorUI.is() )
|
|
|
|
throw NullPointerException();
|
2004-11-16 11:13:18 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2014-06-13 13:19:14 +01:00
|
|
|
PropertyId nActuatingPropId( impl_getPropertyId_throwRuntime( _rActuatingPropertyName ) );
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
OSL_PRECOND( m_pHelper.get(), "SubmissionPropertyHandler::actuatingPropertyChanged: inconsistentcy!" );
|
2014-06-13 13:19:14 +01:00
|
|
|
// if we survived impl_getPropertyId_throwRuntime, we should have a helper, since no helper implies no properties
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
|
|
|
|
switch ( nActuatingPropId )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_XFORMS_BUTTONTYPE:
|
|
|
|
{
|
|
|
|
FormButtonType eType = FormButtonType_PUSH;
|
|
|
|
OSL_VERIFY( _rNewValue >>= eType );
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_SUBMISSION_ID, eType == FormButtonType_SUBMIT );
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2011-03-19 14:06:18 +01:00
|
|
|
OSL_FAIL( "SubmissionPropertyHandler::actuatingPropertyChanged: cannot handle this id!" );
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
Any SAL_CALL SubmissionPropertyHandler::convertToPropertyValue( const OUString& _rPropertyName, const Any& _rControlValue )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
|
|
|
Any aPropertyValue;
|
2004-11-16 11:13:18 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
OSL_ENSURE( m_pHelper.get(), "SubmissionPropertyHandler::convertToPropertyValue: we have no SupportedProperties!" );
|
2004-11-16 11:13:18 +00:00
|
|
|
if ( !m_pHelper.get() )
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
return aPropertyValue;
|
2004-11-16 11:13:18 +00:00
|
|
|
|
2013-04-07 12:06:47 +02:00
|
|
|
OUString sControlValue;
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
OSL_VERIFY( _rControlValue >>= sControlValue );
|
|
|
|
|
|
|
|
PropertyId nPropId( m_pInfoService->getPropertyId( _rPropertyName ) );
|
|
|
|
switch ( nPropId )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_SUBMISSION_ID:
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
Reference< XSubmission > xSubmission( m_pHelper->getModelElementFromUIName( EFormsHelper::Submission, sControlValue ), UNO_QUERY );
|
|
|
|
aPropertyValue <<= xSubmission;
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_XFORMS_BUTTONTYPE:
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
::rtl::Reference< IPropertyEnumRepresentation > aEnumConversion(
|
2014-05-11 10:09:04 +02:00
|
|
|
new DefaultEnumRepresentation( *m_pInfoService, ::cppu::UnoType<FormButtonType>::get(), PROPERTY_ID_BUTTONTYPE ) );
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
// TODO/UNOize: make aEnumConversion a member?
|
|
|
|
aEnumConversion->getValueFromDescription( sControlValue, aPropertyValue );
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2011-03-19 14:06:18 +01:00
|
|
|
OSL_FAIL( "SubmissionPropertyHandler::convertToPropertyValue: cannot handle this id!" );
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
return aPropertyValue;
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
Any SAL_CALL SubmissionPropertyHandler::convertToControlValue( const OUString& _rPropertyName, const Any& _rPropertyValue, const Type& _rControlValueType )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
|
|
|
Any aControlValue;
|
2004-11-16 11:13:18 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
OSL_ENSURE( m_pHelper.get(), "SubmissionPropertyHandler::convertToControlValue: we have no SupportedProperties!" );
|
2004-11-16 11:13:18 +00:00
|
|
|
if ( !m_pHelper.get() )
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
return aControlValue;
|
|
|
|
|
|
|
|
OSL_ENSURE( _rControlValueType.getTypeClass() == TypeClass_STRING,
|
|
|
|
"SubmissionPropertyHandler::convertToControlValue: all our controls should use strings for value exchange!" );
|
2004-11-16 11:13:18 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
PropertyId nPropId( m_pInfoService->getPropertyId( _rPropertyName ) );
|
|
|
|
switch ( nPropId )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_SUBMISSION_ID:
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
Reference< XPropertySet > xSubmission( _rPropertyValue, UNO_QUERY );
|
2004-11-16 11:13:18 +00:00
|
|
|
if ( xSubmission.is() )
|
2015-04-15 13:17:16 +02:00
|
|
|
aControlValue <<= EFormsHelper::getModelElementUIName( EFormsHelper::Submission, xSubmission );
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_XFORMS_BUTTONTYPE:
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
::rtl::Reference< IPropertyEnumRepresentation > aEnumConversion(
|
|
|
|
new DefaultEnumRepresentation( *m_pInfoService, _rPropertyValue.getValueType(), PROPERTY_ID_BUTTONTYPE ) );
|
|
|
|
// TODO/UNOize: make aEnumConversion a member?
|
|
|
|
aControlValue <<= aEnumConversion->getDescriptionForValue( _rPropertyValue );
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2011-03-19 14:06:18 +01:00
|
|
|
OSL_FAIL( "SubmissionPropertyHandler::convertToControlValue: cannot handle this id!" );
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.88); FILE MERGED
2006/03/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 fs 1.3.88.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:35 fs 1.3.88.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 fs 1.3.88.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:48 fs 1.3.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:08 fs 1.3.88.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:33:39 +00:00
|
|
|
return aControlValue;
|
2004-11-16 11:13:18 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
void SubmissionPropertyHandler::_propertyChanged( const PropertyChangeEvent& _rEvent )
|
2004-11-16 11:13:18 +00:00
|
|
|
{
|
|
|
|
if ( _rEvent.PropertyName == PROPERTY_BUTTONTYPE )
|
|
|
|
firePropertyChange( PROPERTY_XFORMS_BUTTONTYPE, PROPERTY_ID_XFORMS_BUTTONTYPE, _rEvent.OldValue, _rEvent.NewValue );
|
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2004-11-16 11:13:18 +00:00
|
|
|
} // namespace pcr
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2004-11-16 11:13:18 +00:00
|
|
|
|
2010-10-12 15:57:08 +02:00
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|