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:05:03 +00:00
|
|
|
|
|
|
|
#include "eformspropertyhandler.hxx"
|
|
|
|
#include "formstrings.hxx"
|
|
|
|
#include "formmetadata.hxx"
|
2014-04-13 23:44:29 +02:00
|
|
|
#include "pcrservices.hxx"
|
2017-10-23 22:41:56 +02:00
|
|
|
#include <propctrlr.h>
|
2004-11-16 11:05:03 +00:00
|
|
|
#include "formbrowsertools.hxx"
|
|
|
|
#include "eformshelper.hxx"
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
#include "handlerhelper.hxx"
|
2004-11-16 11:05:03 +00:00
|
|
|
|
2017-02-06 17:08:38 +01:00
|
|
|
#include <com/sun/star/lang/NullPointerException.hpp>
|
2004-11-16 11:05:03 +00:00
|
|
|
#include <com/sun/star/ui/dialogs/XExecutableDialog.hpp>
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
#include <com/sun/star/inspection/PropertyControlType.hpp>
|
|
|
|
#include <com/sun/star/inspection/XObjectInspectorUI.hpp>
|
2004-11-16 11:05:03 +00:00
|
|
|
#include <tools/debug.hxx>
|
2019-03-01 14:42:38 +02:00
|
|
|
#include <tools/diagnose_ex.h>
|
2018-07-27 09:42:16 +02:00
|
|
|
#include <sal/log.hxx>
|
2004-11-16 11:05:03 +00:00
|
|
|
|
|
|
|
#include <functional>
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-12-08 15:58:41 +02:00
|
|
|
extern "C" void createRegistryInfo_EFormsPropertyHandler()
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
{
|
|
|
|
::pcr::EFormsPropertyHandler::registerImplementation();
|
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2004-11-16 11:05:03 +00:00
|
|
|
namespace pcr
|
|
|
|
{
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2004-11-16 11:05:03 +00:00
|
|
|
|
|
|
|
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::xforms;
|
|
|
|
using namespace ::com::sun::star::script;
|
|
|
|
using namespace ::com::sun::star::ui::dialogs;
|
|
|
|
using namespace ::com::sun::star::form::binding;
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
using namespace ::com::sun::star::inspection;
|
2004-11-16 11:05:03 +00:00
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2004-11-16 11:05:03 +00:00
|
|
|
//= EFormsPropertyHandler
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
EFormsPropertyHandler::EFormsPropertyHandler( const Reference< XComponentContext >& _rxContext )
|
|
|
|
:EFormsPropertyHandler_Base( _rxContext )
|
|
|
|
,m_bSimulatingModelChange( false )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2004-11-16 11:05:03 +00:00
|
|
|
EFormsPropertyHandler::~EFormsPropertyHandler( )
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
No need to keep these whitelisted functions decorated with SAL_CALL
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-14 08:45:02 +01:00
|
|
|
OUString EFormsPropertyHandler::getImplementationName_static( )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
2019-07-30 17:55:06 +02:00
|
|
|
return "com.sun.star.comp.extensions.EFormsPropertyHandler";
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
No need to keep these whitelisted functions decorated with SAL_CALL
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-14 08:45:02 +01:00
|
|
|
Sequence< OUString > EFormsPropertyHandler::getSupportedServiceNames_static( )
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
{
|
2015-11-15 12:22:28 +02:00
|
|
|
Sequence<OUString> aSupported { "com.sun.star.form.inspection.XMLFormsPropertyHandler" };
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
return aSupported;
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2013-04-07 12:06:47 +02:00
|
|
|
OUString EFormsPropertyHandler::getModelNamePropertyValue() const
|
2005-07-01 10:50:00 +00:00
|
|
|
{
|
2013-04-07 12:06:47 +02:00
|
|
|
OUString sModelName = m_pHelper->getCurrentFormModelName();
|
2011-12-22 15:35:41 -02:00
|
|
|
if ( sModelName.isEmpty() )
|
2005-07-01 10:50:00 +00:00
|
|
|
sModelName = m_sBindingLessModelName;
|
|
|
|
return sModelName;
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
Any SAL_CALL EFormsPropertyHandler::getPropertyValue( const OUString& _rPropertyName )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2014-06-13 13:19:14 +01:00
|
|
|
PropertyId nPropId( impl_getPropertyId_throwUnknownProperty( _rPropertyName ) );
|
2004-11-16 11:05:03 +00:00
|
|
|
|
2018-10-16 15:23:12 +02:00
|
|
|
OSL_ENSURE(
|
|
|
|
m_pHelper,
|
|
|
|
"EFormsPropertyHandler::getPropertyValue: we don't have any SupportedProperties!");
|
|
|
|
// if we survived impl_getPropertyId_throwUnknownProperty, we should have a helper, since no helper implies no properties
|
2004-11-16 11:05:03 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
Any aReturn;
|
2004-11-16 11:05:03 +00:00
|
|
|
try
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
switch ( nPropId )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_LIST_BINDING:
|
|
|
|
aReturn <<= m_pHelper->getCurrentListSourceBinding();
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_XML_DATA_MODEL:
|
2005-07-01 10:50:00 +00:00
|
|
|
aReturn <<= getModelNamePropertyValue();
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_BINDING_NAME:
|
|
|
|
aReturn <<= m_pHelper->getCurrentBindingName();
|
|
|
|
break;
|
2004-11-16 11:05:03 +00:00
|
|
|
|
|
|
|
case PROPERTY_ID_BIND_EXPRESSION:
|
|
|
|
case PROPERTY_ID_XSD_CONSTRAINT:
|
|
|
|
case PROPERTY_ID_XSD_CALCULATION:
|
|
|
|
case PROPERTY_ID_XSD_REQUIRED:
|
|
|
|
case PROPERTY_ID_XSD_RELEVANT:
|
|
|
|
case PROPERTY_ID_XSD_READONLY:
|
|
|
|
{
|
|
|
|
Reference< XPropertySet > xBindingProps( m_pHelper->getCurrentBinding() );
|
|
|
|
if ( xBindingProps.is() )
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
aReturn = xBindingProps->getPropertyValue( _rPropertyName );
|
2014-05-11 10:09:04 +02:00
|
|
|
DBG_ASSERT( aReturn.getValueType().equals( ::cppu::UnoType<OUString>::get() ),
|
2004-11-16 11:05:03 +00:00
|
|
|
"EFormsPropertyHandler::getPropertyValue: invalid BindingExpression value type!" );
|
|
|
|
}
|
|
|
|
else
|
2013-04-07 12:06:47 +02:00
|
|
|
aReturn <<= OUString();
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2011-03-01 17:55:09 +01:00
|
|
|
OSL_FAIL( "EFormsPropertyHandler::getPropertyValue: cannot handle this property!" );
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
break;
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
catch( const Exception& )
|
|
|
|
{
|
2019-08-15 15:56:55 +02:00
|
|
|
TOOLS_WARN_EXCEPTION( "extensions.propctrlr", "EFormsPropertyHandler::getPropertyValue: caught an exception!"
|
|
|
|
"(have been asked for the \"" <<_rPropertyName << "\" property.)");
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
return aReturn;
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
void SAL_CALL EFormsPropertyHandler::setPropertyValue( const OUString& _rPropertyName, const Any& _rValue )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21: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.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
|
2018-10-16 15:23:12 +02:00
|
|
|
OSL_ENSURE(
|
|
|
|
m_pHelper,
|
|
|
|
"EFormsPropertyHandler::setPropertyValue: we don't have any SupportedProperties!");
|
|
|
|
// if we survived impl_getPropertyId_throwUnknownProperty, we should have a helper, since no helper implies no properties
|
2004-11-16 11:05:03 +00:00
|
|
|
|
|
|
|
try
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
Any aOldValue = getPropertyValue( _rPropertyName );
|
|
|
|
|
|
|
|
switch ( nPropId )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_LIST_BINDING:
|
|
|
|
{
|
|
|
|
Reference< XListEntrySource > xSource;
|
|
|
|
OSL_VERIFY( _rValue >>= xSource );
|
|
|
|
m_pHelper->setListSourceBinding( xSource );
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_XML_DATA_MODEL:
|
|
|
|
{
|
2005-07-01 10:50:00 +00:00
|
|
|
OSL_VERIFY( _rValue >>= m_sBindingLessModelName );
|
2004-11-16 11:05:03 +00:00
|
|
|
|
2005-07-01 10:50:00 +00:00
|
|
|
// if the model changed, reset the binding to NULL
|
|
|
|
if ( m_pHelper->getCurrentFormModelName() != m_sBindingLessModelName )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
2013-04-07 12:06:47 +02:00
|
|
|
OUString sOldBindingName = m_pHelper->getCurrentBindingName();
|
2015-11-10 10:14:53 +01:00
|
|
|
m_pHelper->setBinding( nullptr );
|
2005-07-01 10:50:00 +00:00
|
|
|
firePropertyChange( PROPERTY_BINDING_NAME, PROPERTY_ID_BINDING_NAME,
|
2013-04-07 12:06:47 +02:00
|
|
|
makeAny( sOldBindingName ), makeAny( OUString() ) );
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
2005-07-01 10:50:00 +00:00
|
|
|
}
|
|
|
|
break;
|
2004-11-16 11:05:03 +00:00
|
|
|
|
2005-07-01 10:50:00 +00:00
|
|
|
case PROPERTY_ID_BINDING_NAME:
|
|
|
|
{
|
2013-04-07 12:06:47 +02:00
|
|
|
OUString sNewBindingName;
|
2005-07-01 10:50:00 +00:00
|
|
|
OSL_VERIFY( _rValue >>= sNewBindingName );
|
|
|
|
|
|
|
|
bool bPreviouslyEmptyModel = !m_pHelper->getCurrentFormModel().is();
|
|
|
|
|
|
|
|
Reference< XPropertySet > xNewBinding;
|
2011-12-22 15:35:41 -02:00
|
|
|
if ( !sNewBindingName.isEmpty() )
|
2005-07-01 10:50:00 +00:00
|
|
|
// obtain the binding with this name, for the current model
|
|
|
|
xNewBinding = m_pHelper->getOrCreateBindingForModel( getModelNamePropertyValue(), sNewBindingName );
|
|
|
|
|
|
|
|
m_pHelper->setBinding( xNewBinding );
|
|
|
|
|
|
|
|
if ( bPreviouslyEmptyModel )
|
|
|
|
{ // simulate a property change for the model property
|
|
|
|
// This is because we "simulate" the Model property by remembering the
|
|
|
|
// value ourself. Other instances might, however, not know this value,
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
// but prefer to retrieve it somewhere else - e.g. from the EFormsHelper
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2005-07-01 10:50:00 +00:00
|
|
|
// The really correct solution would be if *all* property handlers
|
|
|
|
// obtain a "current property value" for *all* properties from a central
|
|
|
|
// instance. Then, handler A could ask it for the value of property
|
|
|
|
// X, and this request would be re-routed to handler B, which ultimately
|
|
|
|
// knows the current value.
|
|
|
|
// However, there's no such mechanism in place currently.
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
m_bSimulatingModelChange = true;
|
2005-07-01 10:50:00 +00:00
|
|
|
firePropertyChange( PROPERTY_XML_DATA_MODEL, PROPERTY_ID_XML_DATA_MODEL,
|
2013-04-07 12:06:47 +02:00
|
|
|
makeAny( OUString() ), makeAny( getModelNamePropertyValue() ) );
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
m_bSimulatingModelChange = false;
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_BIND_EXPRESSION:
|
|
|
|
{
|
|
|
|
Reference< XPropertySet > xBinding( m_pHelper->getCurrentBinding() );
|
|
|
|
OSL_ENSURE( xBinding.is(), "You should not reach this without an active binding!" );
|
|
|
|
if ( xBinding.is() )
|
|
|
|
xBinding->setPropertyValue( PROPERTY_BIND_EXPRESSION, _rValue );
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_XSD_REQUIRED:
|
|
|
|
case PROPERTY_ID_XSD_RELEVANT:
|
|
|
|
case PROPERTY_ID_XSD_READONLY:
|
|
|
|
case PROPERTY_ID_XSD_CONSTRAINT:
|
|
|
|
case PROPERTY_ID_XSD_CALCULATION:
|
|
|
|
{
|
|
|
|
Reference< XPropertySet > xBindingProps( m_pHelper->getCurrentBinding() );
|
|
|
|
DBG_ASSERT( xBindingProps.is(), "EFormsPropertyHandler::setPropertyValue: how can I set a property if there's no binding?" );
|
|
|
|
if ( xBindingProps.is() )
|
|
|
|
{
|
2014-05-11 10:09:04 +02:00
|
|
|
DBG_ASSERT( _rValue.getValueType().equals( ::cppu::UnoType<OUString>::get() ),
|
2004-11-16 11:05:03 +00:00
|
|
|
"EFormsPropertyHandler::setPropertyValue: invalid value type!" );
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
xBindingProps->setPropertyValue( _rPropertyName, _rValue );
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2011-03-01 17:55:09 +01:00
|
|
|
OSL_FAIL( "EFormsPropertyHandler::setPropertyValue: cannot handle this property!" );
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
break;
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
|
|
|
|
impl_setContextDocumentModified_nothrow();
|
|
|
|
|
|
|
|
Any aNewValue( getPropertyValue( _rPropertyName ) );
|
|
|
|
firePropertyChange( _rPropertyName, nPropId, aOldValue, aNewValue );
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
catch( const Exception& )
|
|
|
|
{
|
2011-03-19 14:06:18 +01:00
|
|
|
OSL_FAIL( "EFormsPropertyHandler::setPropertyValue: caught an exception!" );
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
void EFormsPropertyHandler::onNewComponent()
|
|
|
|
{
|
|
|
|
EFormsPropertyHandler_Base::onNewComponent();
|
|
|
|
|
|
|
|
Reference< frame::XModel > xDocument( impl_getContextDocument_nothrow() );
|
|
|
|
DBG_ASSERT( xDocument.is(), "EFormsPropertyHandler::onNewComponent: no document!" );
|
|
|
|
if ( EFormsHelper::isEForm( xDocument ) )
|
|
|
|
m_pHelper.reset( new EFormsHelper( m_aMutex, m_xComponent, xDocument ) );
|
|
|
|
else
|
2014-01-06 14:10:06 +00:00
|
|
|
m_pHelper.reset();
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-12-05 10:11:39 +02:00
|
|
|
Sequence< Property > EFormsPropertyHandler::doDescribeSupportedProperties() const
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
2017-02-17 19:06:24 +02:00
|
|
|
std::vector< Property > aProperties;
|
2004-11-16 11:05:03 +00:00
|
|
|
|
2018-10-16 15:23:12 +02:00
|
|
|
if (m_pHelper)
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
|
|
|
if ( m_pHelper->canBindToAnyDataType() )
|
|
|
|
{
|
|
|
|
aProperties.reserve( 7 );
|
|
|
|
addStringPropertyDescription( aProperties, PROPERTY_XML_DATA_MODEL );
|
2005-07-01 10:50:00 +00:00
|
|
|
addStringPropertyDescription( aProperties, PROPERTY_BINDING_NAME );
|
2004-11-16 11:05:03 +00:00
|
|
|
addStringPropertyDescription( aProperties, PROPERTY_BIND_EXPRESSION );
|
|
|
|
addStringPropertyDescription( aProperties, PROPERTY_XSD_REQUIRED );
|
|
|
|
addStringPropertyDescription( aProperties, PROPERTY_XSD_RELEVANT );
|
|
|
|
addStringPropertyDescription( aProperties, PROPERTY_XSD_READONLY );
|
|
|
|
addStringPropertyDescription( aProperties, PROPERTY_XSD_CONSTRAINT );
|
|
|
|
addStringPropertyDescription( aProperties, PROPERTY_XSD_CALCULATION );
|
|
|
|
}
|
|
|
|
if ( m_pHelper->isListEntrySink() )
|
|
|
|
{
|
|
|
|
implAddPropertyDescription( aProperties, PROPERTY_LIST_BINDING,
|
2014-05-22 23:19:05 +02:00
|
|
|
cppu::UnoType<XListEntrySource>::get() );
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
if ( aProperties.empty() )
|
|
|
|
return Sequence< Property >();
|
2019-02-20 01:10:07 +03:00
|
|
|
return comphelper::containerToSequence(aProperties);
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
Any SAL_CALL EFormsPropertyHandler::convertToPropertyValue( const OUString& _rPropertyName, const Any& _rControlValue )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2004-11-16 11:05:03 +00:00
|
|
|
Any aReturn;
|
|
|
|
|
2018-10-16 15:23:12 +02:00
|
|
|
OSL_ENSURE(
|
|
|
|
m_pHelper,
|
|
|
|
"EFormsPropertyHandler::convertToPropertyValue: we have no SupportedProperties!");
|
|
|
|
if (!m_pHelper)
|
2004-11-16 11:05:03 +00:00
|
|
|
return aReturn;
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
PropertyId nPropId( m_pInfoService->getPropertyId( _rPropertyName ) );
|
|
|
|
|
2013-04-07 12:06:47 +02:00
|
|
|
OUString sControlValue;
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
switch ( nPropId )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_LIST_BINDING:
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
OSL_VERIFY( _rControlValue >>= sControlValue );
|
|
|
|
Reference< XListEntrySource > xListSource( m_pHelper->getModelElementFromUIName( EFormsHelper::Binding, sControlValue ), UNO_QUERY );
|
|
|
|
OSL_ENSURE( xListSource.is() || !m_pHelper->getModelElementFromUIName( EFormsHelper::Binding, sControlValue ).is(),
|
|
|
|
"EFormsPropertyHandler::convertToPropertyValue: there's a binding which is no ListEntrySource!" );
|
2004-11-16 11:05:03 +00:00
|
|
|
aReturn <<= xListSource;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
aReturn = EFormsPropertyHandler_Base::convertToPropertyValue( _rPropertyName, _rControlValue );
|
2004-11-16 11:05:03 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return aReturn;
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
Any SAL_CALL EFormsPropertyHandler::convertToControlValue( const OUString& _rPropertyName, const Any& _rPropertyValue, const Type& _rControlValueType )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
|
|
|
Any aReturn;
|
2004-11-16 11:05:03 +00:00
|
|
|
|
2018-10-16 15:23:12 +02:00
|
|
|
OSL_ENSURE(m_pHelper,
|
|
|
|
"EFormsPropertyHandler::convertToControlValue: we have no SupportedProperties!");
|
|
|
|
if (!m_pHelper)
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
return aReturn;
|
|
|
|
|
|
|
|
PropertyId nPropId( m_pInfoService->getPropertyId( _rPropertyName ) );
|
2004-11-16 11:05:03 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
OSL_ENSURE( _rControlValueType.getTypeClass() == TypeClass_STRING,
|
|
|
|
"EFormsPropertyHandler::convertToControlValue: all our controls should use strings for value exchange!" );
|
|
|
|
|
|
|
|
switch ( nPropId )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_LIST_BINDING:
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
Reference< XPropertySet > xListSourceBinding( _rPropertyValue, UNO_QUERY );
|
2004-11-16 11:05:03 +00:00
|
|
|
if ( xListSourceBinding.is() )
|
2015-04-15 13:17:16 +02:00
|
|
|
aReturn <<= EFormsHelper::getModelElementUIName( EFormsHelper::Binding, xListSourceBinding );
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
aReturn = EFormsPropertyHandler_Base::convertToControlValue( _rPropertyName, _rPropertyValue, _rControlValueType );
|
2004-11-16 11:05:03 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
return aReturn;
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
Sequence< OUString > SAL_CALL EFormsPropertyHandler::getActuatingProperties( )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2018-10-16 15:23:12 +02:00
|
|
|
if (!m_pHelper)
|
2013-04-07 12:06:47 +02:00
|
|
|
return Sequence< OUString >();
|
2004-11-16 11:05:03 +00:00
|
|
|
|
2017-02-17 19:06:24 +02:00
|
|
|
std::vector< OUString > aInterestedInActuations( 2 );
|
2004-11-16 11:05:03 +00:00
|
|
|
aInterestedInActuations[ 0 ] = PROPERTY_XML_DATA_MODEL;
|
2005-07-01 10:50:00 +00:00
|
|
|
aInterestedInActuations[ 1 ] = PROPERTY_BINDING_NAME;
|
2019-02-20 01:10:07 +03:00
|
|
|
return comphelper::containerToSequence(aInterestedInActuations);
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
Sequence< OUString > SAL_CALL EFormsPropertyHandler::getSupersededProperties( )
|
CWS-TOOLING: integrate CWS dba32e
2009-08-10 13:16:25 +0200 fs r274805 : #i84390# typo corrected
2009-08-10 13:04:28 +0200 fs r274804 : #i103741# properly terminate the last token in a string with a 0 byte
2009-07-24 08:54:05 +0200 msc r274286 : #103219# changed long name
2009-07-24 08:42:28 +0200 msc r274285 : #i79649# changed behaviour of the wizard
2009-07-22 14:17:49 +0200 oj r274238 : GrabFocus
2009-07-22 13:38:01 +0200 oj r274232 : #i102934# mixed up
2009-07-22 13:37:16 +0200 oj r274231 : #i102934# mixed up
2009-07-21 12:30:36 +0200 oj r274176 : crash when using distinct
2009-07-21 10:03:44 +0200 oj r274163 : set last char to 0
2009-07-21 09:31:22 +0200 oj r274161 : mediatype corrected
2009-07-20 11:45:33 +0200 fs r274118 : typo in formatting string
2009-07-20 11:40:39 +0200 fs r274117 : removed unused include
2009-07-20 11:40:01 +0200 fs r274116 : class name corrected
2009-07-16 13:41:45 +0200 oj r274046 : i101587 wrong check for embeddeddatabase url in confguration, have to check path
2009-07-16 13:12:05 +0200 tbo r274044 : #i103219# adjust declarion to new hid.lst
2009-07-16 12:43:48 +0200 oj r274041 : #i102497# check also fot longvarchar
2009-07-16 12:15:41 +0200 oj r274039 : #i103030# handle type description and exceptions as well
2009-07-16 11:14:26 +0200 fs r274035 : let SVN ignore output paths
2009-07-16 09:23:43 +0200 fs r274030 : TransforFormComponentProperties: no need to check for attribute equality
2009-07-10 14:16:23 +0200 oj r273892 : CWS-TOOLING: rebase CWS dba32e to trunk@273858 (milestone: DEV300:m52)
2009-07-01 21:41:50 +0200 fs r273614 : #i10000#
2009-07-01 15:01:10 +0200 fs r273589 : Input required doesn't make sense at all in XML form documents
2009-07-01 12:10:31 +0200 fs r273562 : updated
2009-07-01 11:46:12 +0200 fs r273560 : #i103219# add about 100 missing long names
2009-07-01 10:11:41 +0200 fs r273551 : moved from socket/port usage to pipe/name usage, which is more common nowadays
2009-07-01 09:50:03 +0200 fs r273549 : removed obsolete (empty) folder
2009-07-01 09:47:35 +0200 fs r273548 : copied the code for the Accessibility Workbench herein, formerly located in the old CVS repository, at gsl/awb
2009-06-30 10:07:47 +0200 fs r273493 : merging latest changes from CWS dba32d
2009-06-29 20:46:31 +0200 fs r273482 : #i103138# Rectangle conversions
2009-06-29 10:01:13 +0200 fs r273453 : #i103138#
refactored the code for positioning/zooming the control
Basically, we now allow adjustControlGeometry_throw (formerly known as positionControl_throw and setControlZoom) to
take an additional ViewTransformation parameter, describing the transformation to obtain the actual
control position/size. Consequently, positionControl itself also allows for a ViewTransformation parameter.
This has become necessary since during painting, the device which we created our control for might not necessarily
have a proper MapMode set. In this case, if we would use this map mode for calculating the control's position/size,
this would lead to wrong results.
Note that this problem was introduced by the fix for #i101398#: During the fix, we postponed the control creation
to a later time (when it is really needed). At this later time, the MapMode at the device is broken, at the earlier
time where we formerly crearted the control (createPrimitive2DSequence), it is not yet broken.
Whether or not the MapMode is defined as "broken" might depend on one's point of view, however ...
I consider it broken, since:
- we need the map mode to obtain the proper zoom level, which is to be forwarded to the control
- there are scenarios where the MapMode is *not* set to MAP_PIXEL (in those scenarios, everything works
fine), and there are scenarios where it *is* set to MAP_PIXEL (in those the bug 103138 appears).
It somehow feels wrong that one cannot rely on the device's map mode this way, but on the other hand
one has no possibility to obtain the current zoom by other means.
Note that one issue (still to be submitted) is left: In the page pane of a Draw/Impress document, controls
have a wrong text size. This is because in this pane, the above-mentioned "broken" map mode is used,
which means the controls have a zoom of "1:1" set, which is wrong here.
2009-06-29 09:52:13 +0200 fs r273452 : during #i103138#: belongsToDevice is unused nowadays
2009-06-24 12:40:06 +0200 fs r273329 : #i102888# #i102899#
2009-06-24 12:10:29 +0200 oj r273327 : #i103030# some code changes
2009-06-24 09:44:14 +0200 oj r273311 : #i103030# some code changes
2009-06-24 09:24:42 +0200 oj r273309 : #i103030# add log
2009-06-24 09:03:29 +0200 fs r273308 : if a col's table name is schema.table, properly quote all parts
2009-06-24 08:56:06 +0200 oj r273307 : #i102691# changed string
2009-06-23 13:31:43 +0200 oj r273280 : #i102479# fix date, time and datetime
2009-06-23 12:51:28 +0200 oj r273277 : #i103020# clear old expression when updating to avoid dead pointers in treelist userdata
2009-06-23 12:17:16 +0200 oj r273275 : #i103030# add LogBridge
2009-06-23 11:53:10 +0200 oj r273272 : shawdowed var resolved
2009-06-23 11:48:49 +0200 oj r273270 : #i103030# add :log to uno env if var UNO_ENV_LOG is set
2009-06-23 11:47:47 +0200 oj r273269 : #i103030# add LogBridge
2009-06-23 11:47:11 +0200 oj r273268 : #i103030# add LogBridge
2009-06-23 08:05:08 +0200 oj r273253 : #i102934# add key for collapsing
2009-06-22 13:21:33 +0200 fs r273225 : merging latest changes from CWS dba32d
2009-06-22 13:15:22 +0200 fs r273221 : why restrict to 12 entries?
2009-06-22 08:12:21 +0200 oj r273196 : #i102655# choosen > chosen typo fixed
2009-06-22 08:08:04 +0200 oj r273195 : #i102657# typo fix
2009-06-22 08:06:28 +0200 oj r273194 : #i102934# expanding and collasping of section
2009-06-22 08:05:52 +0200 oj r273193 : #i102930# set focus in treelistbox
2009-06-22 08:04:56 +0200 oj r273192 : #i102929# enable tabstop
2009-06-19 13:18:26 +0200 oj r273157 : remove unused param
2009-06-19 10:07:05 +0200 oj r273149 : CWS-TOOLING: rebase CWS dba32e to trunk@272827 (milestone: DEV300:m50)
2009-06-19 07:32:40 +0200 oj r273146 : merge from dba32d to dba32e
2009-06-19 07:22:56 +0200 oj r273145 : merge from dba32d to dba32e
2009-06-19 07:22:33 +0200 oj r273144 : merge from dba32d to dba32e
2009-06-18 14:09:34 +0200 fs r273116 : merging the latest changes from CWS dba32d (up to revision 273108) herein, which effectively is a rebase to DEV300.m50
2009-06-18 08:50:35 +0200 oj r273098 : #i102894# fix for new line in text
2009-06-18 08:28:48 +0200 oj r273097 : #i102892# check any
2009-06-18 08:21:34 +0200 oj r273096 : check if error is valid
2009-06-16 13:49:28 +0200 fs r273019 : why make a drop down control by default? The form control factory in SVX does this better those days ...
2009-06-10 09:53:20 +0200 oj r272797 : add lic text
2009-06-10 09:48:55 +0200 oj r272796 : test added for i101618
2009-06-09 14:57:39 +0200 oj r272771 : #i101618# access database document only when script container is needed
2009-06-09 12:42:25 +0200 oj r272765 : #i102497# check type property
2009-06-09 12:32:49 +0200 oj r272764 : adjust test cases
2009-06-09 12:31:58 +0200 oj r272763 : adjust test cases
2009-06-09 12:31:22 +0200 oj r272762 : adjust test cases
2009-06-09 11:35:42 +0200 oj r272761 : check if error is valid
2009-06-09 11:29:42 +0200 oj r272760 : #i102497# longvarchar was missing
2009-06-08 14:52:49 +0200 fs r272733 : #i102564# when setting a new field, also set m_nFieldType
2009-06-08 13:51:20 +0200 oj r272730 : add tests
2009-06-05 14:38:01 +0200 oj r272686 : add dep
2009-06-05 14:35:00 +0200 oj r272684 : add new tests
2009-06-05 13:41:18 +0200 oj r272681 : code clean ups
2009-06-05 12:40:51 +0200 oj r272678 : code cleanup
2009-06-05 12:02:57 +0200 oj r272677 : code cleanup
2009-06-05 10:42:38 +0200 oj r272670 : #i49320# impl export of single rows and as RTF and HTML
2009-06-03 14:30:37 +0200 oj r272576 : #i79649# check if file matches filter wildcard
2009-06-03 13:41:57 +0200 oj r272560 : #i102470# impl not b like 'c'
2009-08-26 10:09:17 +00:00
|
|
|
{
|
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2018-10-16 15:23:12 +02:00
|
|
|
if (!m_pHelper)
|
2013-04-07 12:06:47 +02:00
|
|
|
return Sequence< OUString >();
|
CWS-TOOLING: integrate CWS dba32e
2009-08-10 13:16:25 +0200 fs r274805 : #i84390# typo corrected
2009-08-10 13:04:28 +0200 fs r274804 : #i103741# properly terminate the last token in a string with a 0 byte
2009-07-24 08:54:05 +0200 msc r274286 : #103219# changed long name
2009-07-24 08:42:28 +0200 msc r274285 : #i79649# changed behaviour of the wizard
2009-07-22 14:17:49 +0200 oj r274238 : GrabFocus
2009-07-22 13:38:01 +0200 oj r274232 : #i102934# mixed up
2009-07-22 13:37:16 +0200 oj r274231 : #i102934# mixed up
2009-07-21 12:30:36 +0200 oj r274176 : crash when using distinct
2009-07-21 10:03:44 +0200 oj r274163 : set last char to 0
2009-07-21 09:31:22 +0200 oj r274161 : mediatype corrected
2009-07-20 11:45:33 +0200 fs r274118 : typo in formatting string
2009-07-20 11:40:39 +0200 fs r274117 : removed unused include
2009-07-20 11:40:01 +0200 fs r274116 : class name corrected
2009-07-16 13:41:45 +0200 oj r274046 : i101587 wrong check for embeddeddatabase url in confguration, have to check path
2009-07-16 13:12:05 +0200 tbo r274044 : #i103219# adjust declarion to new hid.lst
2009-07-16 12:43:48 +0200 oj r274041 : #i102497# check also fot longvarchar
2009-07-16 12:15:41 +0200 oj r274039 : #i103030# handle type description and exceptions as well
2009-07-16 11:14:26 +0200 fs r274035 : let SVN ignore output paths
2009-07-16 09:23:43 +0200 fs r274030 : TransforFormComponentProperties: no need to check for attribute equality
2009-07-10 14:16:23 +0200 oj r273892 : CWS-TOOLING: rebase CWS dba32e to trunk@273858 (milestone: DEV300:m52)
2009-07-01 21:41:50 +0200 fs r273614 : #i10000#
2009-07-01 15:01:10 +0200 fs r273589 : Input required doesn't make sense at all in XML form documents
2009-07-01 12:10:31 +0200 fs r273562 : updated
2009-07-01 11:46:12 +0200 fs r273560 : #i103219# add about 100 missing long names
2009-07-01 10:11:41 +0200 fs r273551 : moved from socket/port usage to pipe/name usage, which is more common nowadays
2009-07-01 09:50:03 +0200 fs r273549 : removed obsolete (empty) folder
2009-07-01 09:47:35 +0200 fs r273548 : copied the code for the Accessibility Workbench herein, formerly located in the old CVS repository, at gsl/awb
2009-06-30 10:07:47 +0200 fs r273493 : merging latest changes from CWS dba32d
2009-06-29 20:46:31 +0200 fs r273482 : #i103138# Rectangle conversions
2009-06-29 10:01:13 +0200 fs r273453 : #i103138#
refactored the code for positioning/zooming the control
Basically, we now allow adjustControlGeometry_throw (formerly known as positionControl_throw and setControlZoom) to
take an additional ViewTransformation parameter, describing the transformation to obtain the actual
control position/size. Consequently, positionControl itself also allows for a ViewTransformation parameter.
This has become necessary since during painting, the device which we created our control for might not necessarily
have a proper MapMode set. In this case, if we would use this map mode for calculating the control's position/size,
this would lead to wrong results.
Note that this problem was introduced by the fix for #i101398#: During the fix, we postponed the control creation
to a later time (when it is really needed). At this later time, the MapMode at the device is broken, at the earlier
time where we formerly crearted the control (createPrimitive2DSequence), it is not yet broken.
Whether or not the MapMode is defined as "broken" might depend on one's point of view, however ...
I consider it broken, since:
- we need the map mode to obtain the proper zoom level, which is to be forwarded to the control
- there are scenarios where the MapMode is *not* set to MAP_PIXEL (in those scenarios, everything works
fine), and there are scenarios where it *is* set to MAP_PIXEL (in those the bug 103138 appears).
It somehow feels wrong that one cannot rely on the device's map mode this way, but on the other hand
one has no possibility to obtain the current zoom by other means.
Note that one issue (still to be submitted) is left: In the page pane of a Draw/Impress document, controls
have a wrong text size. This is because in this pane, the above-mentioned "broken" map mode is used,
which means the controls have a zoom of "1:1" set, which is wrong here.
2009-06-29 09:52:13 +0200 fs r273452 : during #i103138#: belongsToDevice is unused nowadays
2009-06-24 12:40:06 +0200 fs r273329 : #i102888# #i102899#
2009-06-24 12:10:29 +0200 oj r273327 : #i103030# some code changes
2009-06-24 09:44:14 +0200 oj r273311 : #i103030# some code changes
2009-06-24 09:24:42 +0200 oj r273309 : #i103030# add log
2009-06-24 09:03:29 +0200 fs r273308 : if a col's table name is schema.table, properly quote all parts
2009-06-24 08:56:06 +0200 oj r273307 : #i102691# changed string
2009-06-23 13:31:43 +0200 oj r273280 : #i102479# fix date, time and datetime
2009-06-23 12:51:28 +0200 oj r273277 : #i103020# clear old expression when updating to avoid dead pointers in treelist userdata
2009-06-23 12:17:16 +0200 oj r273275 : #i103030# add LogBridge
2009-06-23 11:53:10 +0200 oj r273272 : shawdowed var resolved
2009-06-23 11:48:49 +0200 oj r273270 : #i103030# add :log to uno env if var UNO_ENV_LOG is set
2009-06-23 11:47:47 +0200 oj r273269 : #i103030# add LogBridge
2009-06-23 11:47:11 +0200 oj r273268 : #i103030# add LogBridge
2009-06-23 08:05:08 +0200 oj r273253 : #i102934# add key for collapsing
2009-06-22 13:21:33 +0200 fs r273225 : merging latest changes from CWS dba32d
2009-06-22 13:15:22 +0200 fs r273221 : why restrict to 12 entries?
2009-06-22 08:12:21 +0200 oj r273196 : #i102655# choosen > chosen typo fixed
2009-06-22 08:08:04 +0200 oj r273195 : #i102657# typo fix
2009-06-22 08:06:28 +0200 oj r273194 : #i102934# expanding and collasping of section
2009-06-22 08:05:52 +0200 oj r273193 : #i102930# set focus in treelistbox
2009-06-22 08:04:56 +0200 oj r273192 : #i102929# enable tabstop
2009-06-19 13:18:26 +0200 oj r273157 : remove unused param
2009-06-19 10:07:05 +0200 oj r273149 : CWS-TOOLING: rebase CWS dba32e to trunk@272827 (milestone: DEV300:m50)
2009-06-19 07:32:40 +0200 oj r273146 : merge from dba32d to dba32e
2009-06-19 07:22:56 +0200 oj r273145 : merge from dba32d to dba32e
2009-06-19 07:22:33 +0200 oj r273144 : merge from dba32d to dba32e
2009-06-18 14:09:34 +0200 fs r273116 : merging the latest changes from CWS dba32d (up to revision 273108) herein, which effectively is a rebase to DEV300.m50
2009-06-18 08:50:35 +0200 oj r273098 : #i102894# fix for new line in text
2009-06-18 08:28:48 +0200 oj r273097 : #i102892# check any
2009-06-18 08:21:34 +0200 oj r273096 : check if error is valid
2009-06-16 13:49:28 +0200 fs r273019 : why make a drop down control by default? The form control factory in SVX does this better those days ...
2009-06-10 09:53:20 +0200 oj r272797 : add lic text
2009-06-10 09:48:55 +0200 oj r272796 : test added for i101618
2009-06-09 14:57:39 +0200 oj r272771 : #i101618# access database document only when script container is needed
2009-06-09 12:42:25 +0200 oj r272765 : #i102497# check type property
2009-06-09 12:32:49 +0200 oj r272764 : adjust test cases
2009-06-09 12:31:58 +0200 oj r272763 : adjust test cases
2009-06-09 12:31:22 +0200 oj r272762 : adjust test cases
2009-06-09 11:35:42 +0200 oj r272761 : check if error is valid
2009-06-09 11:29:42 +0200 oj r272760 : #i102497# longvarchar was missing
2009-06-08 14:52:49 +0200 fs r272733 : #i102564# when setting a new field, also set m_nFieldType
2009-06-08 13:51:20 +0200 oj r272730 : add tests
2009-06-05 14:38:01 +0200 oj r272686 : add dep
2009-06-05 14:35:00 +0200 oj r272684 : add new tests
2009-06-05 13:41:18 +0200 oj r272681 : code clean ups
2009-06-05 12:40:51 +0200 oj r272678 : code cleanup
2009-06-05 12:02:57 +0200 oj r272677 : code cleanup
2009-06-05 10:42:38 +0200 oj r272670 : #i49320# impl export of single rows and as RTF and HTML
2009-06-03 14:30:37 +0200 oj r272576 : #i79649# check if file matches filter wildcard
2009-06-03 13:41:57 +0200 oj r272560 : #i102470# impl not b like 'c'
2009-08-26 10:09:17 +00:00
|
|
|
|
2015-11-15 13:17:00 +02:00
|
|
|
Sequence<OUString> aReturn { PROPERTY_INPUT_REQUIRED };
|
CWS-TOOLING: integrate CWS dba32e
2009-08-10 13:16:25 +0200 fs r274805 : #i84390# typo corrected
2009-08-10 13:04:28 +0200 fs r274804 : #i103741# properly terminate the last token in a string with a 0 byte
2009-07-24 08:54:05 +0200 msc r274286 : #103219# changed long name
2009-07-24 08:42:28 +0200 msc r274285 : #i79649# changed behaviour of the wizard
2009-07-22 14:17:49 +0200 oj r274238 : GrabFocus
2009-07-22 13:38:01 +0200 oj r274232 : #i102934# mixed up
2009-07-22 13:37:16 +0200 oj r274231 : #i102934# mixed up
2009-07-21 12:30:36 +0200 oj r274176 : crash when using distinct
2009-07-21 10:03:44 +0200 oj r274163 : set last char to 0
2009-07-21 09:31:22 +0200 oj r274161 : mediatype corrected
2009-07-20 11:45:33 +0200 fs r274118 : typo in formatting string
2009-07-20 11:40:39 +0200 fs r274117 : removed unused include
2009-07-20 11:40:01 +0200 fs r274116 : class name corrected
2009-07-16 13:41:45 +0200 oj r274046 : i101587 wrong check for embeddeddatabase url in confguration, have to check path
2009-07-16 13:12:05 +0200 tbo r274044 : #i103219# adjust declarion to new hid.lst
2009-07-16 12:43:48 +0200 oj r274041 : #i102497# check also fot longvarchar
2009-07-16 12:15:41 +0200 oj r274039 : #i103030# handle type description and exceptions as well
2009-07-16 11:14:26 +0200 fs r274035 : let SVN ignore output paths
2009-07-16 09:23:43 +0200 fs r274030 : TransforFormComponentProperties: no need to check for attribute equality
2009-07-10 14:16:23 +0200 oj r273892 : CWS-TOOLING: rebase CWS dba32e to trunk@273858 (milestone: DEV300:m52)
2009-07-01 21:41:50 +0200 fs r273614 : #i10000#
2009-07-01 15:01:10 +0200 fs r273589 : Input required doesn't make sense at all in XML form documents
2009-07-01 12:10:31 +0200 fs r273562 : updated
2009-07-01 11:46:12 +0200 fs r273560 : #i103219# add about 100 missing long names
2009-07-01 10:11:41 +0200 fs r273551 : moved from socket/port usage to pipe/name usage, which is more common nowadays
2009-07-01 09:50:03 +0200 fs r273549 : removed obsolete (empty) folder
2009-07-01 09:47:35 +0200 fs r273548 : copied the code for the Accessibility Workbench herein, formerly located in the old CVS repository, at gsl/awb
2009-06-30 10:07:47 +0200 fs r273493 : merging latest changes from CWS dba32d
2009-06-29 20:46:31 +0200 fs r273482 : #i103138# Rectangle conversions
2009-06-29 10:01:13 +0200 fs r273453 : #i103138#
refactored the code for positioning/zooming the control
Basically, we now allow adjustControlGeometry_throw (formerly known as positionControl_throw and setControlZoom) to
take an additional ViewTransformation parameter, describing the transformation to obtain the actual
control position/size. Consequently, positionControl itself also allows for a ViewTransformation parameter.
This has become necessary since during painting, the device which we created our control for might not necessarily
have a proper MapMode set. In this case, if we would use this map mode for calculating the control's position/size,
this would lead to wrong results.
Note that this problem was introduced by the fix for #i101398#: During the fix, we postponed the control creation
to a later time (when it is really needed). At this later time, the MapMode at the device is broken, at the earlier
time where we formerly crearted the control (createPrimitive2DSequence), it is not yet broken.
Whether or not the MapMode is defined as "broken" might depend on one's point of view, however ...
I consider it broken, since:
- we need the map mode to obtain the proper zoom level, which is to be forwarded to the control
- there are scenarios where the MapMode is *not* set to MAP_PIXEL (in those scenarios, everything works
fine), and there are scenarios where it *is* set to MAP_PIXEL (in those the bug 103138 appears).
It somehow feels wrong that one cannot rely on the device's map mode this way, but on the other hand
one has no possibility to obtain the current zoom by other means.
Note that one issue (still to be submitted) is left: In the page pane of a Draw/Impress document, controls
have a wrong text size. This is because in this pane, the above-mentioned "broken" map mode is used,
which means the controls have a zoom of "1:1" set, which is wrong here.
2009-06-29 09:52:13 +0200 fs r273452 : during #i103138#: belongsToDevice is unused nowadays
2009-06-24 12:40:06 +0200 fs r273329 : #i102888# #i102899#
2009-06-24 12:10:29 +0200 oj r273327 : #i103030# some code changes
2009-06-24 09:44:14 +0200 oj r273311 : #i103030# some code changes
2009-06-24 09:24:42 +0200 oj r273309 : #i103030# add log
2009-06-24 09:03:29 +0200 fs r273308 : if a col's table name is schema.table, properly quote all parts
2009-06-24 08:56:06 +0200 oj r273307 : #i102691# changed string
2009-06-23 13:31:43 +0200 oj r273280 : #i102479# fix date, time and datetime
2009-06-23 12:51:28 +0200 oj r273277 : #i103020# clear old expression when updating to avoid dead pointers in treelist userdata
2009-06-23 12:17:16 +0200 oj r273275 : #i103030# add LogBridge
2009-06-23 11:53:10 +0200 oj r273272 : shawdowed var resolved
2009-06-23 11:48:49 +0200 oj r273270 : #i103030# add :log to uno env if var UNO_ENV_LOG is set
2009-06-23 11:47:47 +0200 oj r273269 : #i103030# add LogBridge
2009-06-23 11:47:11 +0200 oj r273268 : #i103030# add LogBridge
2009-06-23 08:05:08 +0200 oj r273253 : #i102934# add key for collapsing
2009-06-22 13:21:33 +0200 fs r273225 : merging latest changes from CWS dba32d
2009-06-22 13:15:22 +0200 fs r273221 : why restrict to 12 entries?
2009-06-22 08:12:21 +0200 oj r273196 : #i102655# choosen > chosen typo fixed
2009-06-22 08:08:04 +0200 oj r273195 : #i102657# typo fix
2009-06-22 08:06:28 +0200 oj r273194 : #i102934# expanding and collasping of section
2009-06-22 08:05:52 +0200 oj r273193 : #i102930# set focus in treelistbox
2009-06-22 08:04:56 +0200 oj r273192 : #i102929# enable tabstop
2009-06-19 13:18:26 +0200 oj r273157 : remove unused param
2009-06-19 10:07:05 +0200 oj r273149 : CWS-TOOLING: rebase CWS dba32e to trunk@272827 (milestone: DEV300:m50)
2009-06-19 07:32:40 +0200 oj r273146 : merge from dba32d to dba32e
2009-06-19 07:22:56 +0200 oj r273145 : merge from dba32d to dba32e
2009-06-19 07:22:33 +0200 oj r273144 : merge from dba32d to dba32e
2009-06-18 14:09:34 +0200 fs r273116 : merging the latest changes from CWS dba32d (up to revision 273108) herein, which effectively is a rebase to DEV300.m50
2009-06-18 08:50:35 +0200 oj r273098 : #i102894# fix for new line in text
2009-06-18 08:28:48 +0200 oj r273097 : #i102892# check any
2009-06-18 08:21:34 +0200 oj r273096 : check if error is valid
2009-06-16 13:49:28 +0200 fs r273019 : why make a drop down control by default? The form control factory in SVX does this better those days ...
2009-06-10 09:53:20 +0200 oj r272797 : add lic text
2009-06-10 09:48:55 +0200 oj r272796 : test added for i101618
2009-06-09 14:57:39 +0200 oj r272771 : #i101618# access database document only when script container is needed
2009-06-09 12:42:25 +0200 oj r272765 : #i102497# check type property
2009-06-09 12:32:49 +0200 oj r272764 : adjust test cases
2009-06-09 12:31:58 +0200 oj r272763 : adjust test cases
2009-06-09 12:31:22 +0200 oj r272762 : adjust test cases
2009-06-09 11:35:42 +0200 oj r272761 : check if error is valid
2009-06-09 11:29:42 +0200 oj r272760 : #i102497# longvarchar was missing
2009-06-08 14:52:49 +0200 fs r272733 : #i102564# when setting a new field, also set m_nFieldType
2009-06-08 13:51:20 +0200 oj r272730 : add tests
2009-06-05 14:38:01 +0200 oj r272686 : add dep
2009-06-05 14:35:00 +0200 oj r272684 : add new tests
2009-06-05 13:41:18 +0200 oj r272681 : code clean ups
2009-06-05 12:40:51 +0200 oj r272678 : code cleanup
2009-06-05 12:02:57 +0200 oj r272677 : code cleanup
2009-06-05 10:42:38 +0200 oj r272670 : #i49320# impl export of single rows and as RTF and HTML
2009-06-03 14:30:37 +0200 oj r272576 : #i79649# check if file matches filter wildcard
2009-06-03 13:41:57 +0200 oj r272560 : #i102470# impl not b like 'c'
2009-08-26 10:09:17 +00:00
|
|
|
return aReturn;
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2013-04-07 12:06:47 +02:00
|
|
|
LineDescriptor SAL_CALL EFormsPropertyHandler::describePropertyLine( const OUString& _rPropertyName,
|
2006-07-26 06:54:58 +00:00
|
|
|
const Reference< XPropertyControlFactory >& _rxControlFactory )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
|
|
|
if ( !_rxControlFactory.is() )
|
|
|
|
throw NullPointerException();
|
2018-10-16 15:23:12 +02:00
|
|
|
if (!m_pHelper)
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
throw RuntimeException();
|
2004-11-16 11:05:03 +00:00
|
|
|
|
2006-07-26 06:54:58 +00:00
|
|
|
LineDescriptor aDescriptor;
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
sal_Int16 nControlType = PropertyControlType::TextField;
|
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.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
switch ( nPropId )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_LIST_BINDING:
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
nControlType = PropertyControlType::ListBox;
|
2018-10-16 15:23:12 +02:00
|
|
|
m_pHelper->getAllElementUINames(EFormsHelper::Binding, aListEntries, true);
|
2004-11-16 11:05:03 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case PROPERTY_ID_XML_DATA_MODEL:
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
nControlType = PropertyControlType::ListBox;
|
|
|
|
m_pHelper->getFormModelNames( aListEntries );
|
2004-11-16 11:05:03 +00:00
|
|
|
break;
|
|
|
|
|
2005-07-01 10:50:00 +00:00
|
|
|
case PROPERTY_ID_BINDING_NAME:
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
nControlType = PropertyControlType::ComboBox;
|
2013-04-07 12:06:47 +02:00
|
|
|
OUString sCurrentModel( getModelNamePropertyValue() );
|
2011-12-22 15:35:41 -02:00
|
|
|
if ( !sCurrentModel.isEmpty() )
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
m_pHelper->getBindingNames( sCurrentModel, aListEntries );
|
2005-07-01 10:50:00 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2014-12-12 17:51:56 +01:00
|
|
|
case PROPERTY_ID_BIND_EXPRESSION: aDescriptor.PrimaryButtonId = UID_PROP_DLG_BIND_EXPRESSION; break;
|
|
|
|
case PROPERTY_ID_XSD_REQUIRED: aDescriptor.PrimaryButtonId = UID_PROP_DLG_XSD_REQUIRED; break;
|
|
|
|
case PROPERTY_ID_XSD_RELEVANT: aDescriptor.PrimaryButtonId = UID_PROP_DLG_XSD_RELEVANT; break;
|
|
|
|
case PROPERTY_ID_XSD_READONLY: aDescriptor.PrimaryButtonId = UID_PROP_DLG_XSD_READONLY; break;
|
|
|
|
case PROPERTY_ID_XSD_CONSTRAINT: aDescriptor.PrimaryButtonId = UID_PROP_DLG_XSD_CONSTRAINT; break;
|
|
|
|
case PROPERTY_ID_XSD_CALCULATION: aDescriptor.PrimaryButtonId = UID_PROP_DLG_XSD_CALCULATION; break;
|
2004-11-16 11:05:03 +00:00
|
|
|
|
|
|
|
default:
|
2011-03-01 17:55:09 +01:00
|
|
|
OSL_FAIL( "EFormsPropertyHandler::describePropertyLine: cannot handle this property!" );
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
break;
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
|
|
|
|
switch ( nControlType )
|
|
|
|
{
|
|
|
|
case PropertyControlType::ListBox:
|
2014-04-30 11:46:15 +02:00
|
|
|
aDescriptor.Control = PropertyHandlerHelper::createListBoxControl( _rxControlFactory, aListEntries, false, true );
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
break;
|
|
|
|
case PropertyControlType::ComboBox:
|
2018-03-08 10:47:12 +02:00
|
|
|
aDescriptor.Control = PropertyHandlerHelper::createComboBoxControl( _rxControlFactory, aListEntries, true );
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
break;
|
|
|
|
default:
|
2016-04-20 17:16:53 +02:00
|
|
|
aDescriptor.Control = _rxControlFactory->createPropertyControl( nControlType, false );
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2006-07-26 06:54:58 +00:00
|
|
|
aDescriptor.DisplayName = m_pInfoService->getPropertyTranslation( nPropId );
|
2013-11-15 11:05:19 +02:00
|
|
|
aDescriptor.Category = "Data";
|
2006-07-26 06:54:58 +00:00
|
|
|
aDescriptor.HelpURL = HelpIdUrl::getHelpURL( m_pInfoService->getPropertyHelpId( nPropId ) );
|
|
|
|
return aDescriptor;
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
InteractiveSelectionResult SAL_CALL EFormsPropertyHandler::onInteractivePropertySelection( const OUString& _rPropertyName, sal_Bool /*_bPrimary*/, Any& _rData, const Reference< XObjectInspectorUI >& _rxInspectorUI )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
if ( !_rxInspectorUI.is() )
|
|
|
|
throw NullPointerException();
|
|
|
|
|
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2018-10-16 15:23:12 +02:00
|
|
|
OSL_ENSURE(m_pHelper, "EFormsPropertyHandler::onInteractivePropertySelection: we do not "
|
|
|
|
"have any SupportedProperties!");
|
|
|
|
if (!m_pHelper)
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
return InteractiveSelectionResult_Cancelled;
|
|
|
|
|
2014-06-13 13:19:14 +01:00
|
|
|
PropertyId nPropId( impl_getPropertyId_throwUnknownProperty( _rPropertyName ) );
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
OSL_ENSURE( ( PROPERTY_ID_BINDING_NAME == nPropId )
|
|
|
|
|| ( PROPERTY_ID_BIND_EXPRESSION == nPropId )
|
|
|
|
|| ( PROPERTY_ID_XSD_REQUIRED == nPropId )
|
|
|
|
|| ( PROPERTY_ID_XSD_RELEVANT == nPropId )
|
|
|
|
|| ( PROPERTY_ID_XSD_READONLY == nPropId )
|
|
|
|
|| ( PROPERTY_ID_XSD_CONSTRAINT == nPropId )
|
|
|
|
|| ( PROPERTY_ID_XSD_CALCULATION == nPropId ), "EFormsPropertyHandler::onInteractivePropertySelection: unexpected!" );
|
2004-11-16 11:05:03 +00:00
|
|
|
|
|
|
|
try
|
|
|
|
{
|
|
|
|
Reference< XExecutableDialog > xDialog;
|
2013-06-03 15:34:00 +02:00
|
|
|
xDialog.set( m_xContext->getServiceManager()->createInstanceWithContext( "com.sun.star.xforms.ui.dialogs.AddCondition", m_xContext ), UNO_QUERY );
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
Reference< XPropertySet > xDialogProps( xDialog, UNO_QUERY_THROW );
|
2004-11-16 11:05:03 +00:00
|
|
|
|
|
|
|
// the model for the dialog to work with
|
|
|
|
Reference< xforms::XModel > xModel( m_pHelper->getCurrentFormModel() );
|
|
|
|
// the binding for the dialog to work with
|
|
|
|
Reference< XPropertySet > xBinding( m_pHelper->getCurrentBinding() );
|
|
|
|
// the aspect of the binding which the dialog should modify
|
2016-04-12 16:39:03 +02:00
|
|
|
const OUString& sFacetName( _rPropertyName );
|
2004-11-16 11:05:03 +00:00
|
|
|
|
2011-12-22 15:35:41 -02:00
|
|
|
OSL_ENSURE( xModel.is() && xBinding.is() && !sFacetName.isEmpty(),
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
"EFormsPropertyHandler::onInteractivePropertySelection: something is missing for the dialog initialization!" );
|
2011-12-22 15:35:41 -02:00
|
|
|
if ( !( xModel.is() && xBinding.is() && !sFacetName.isEmpty() ) )
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
return InteractiveSelectionResult_Cancelled;
|
2004-11-16 11:05:03 +00:00
|
|
|
|
2013-06-29 21:24:12 +02:00
|
|
|
xDialogProps->setPropertyValue("FormModel", makeAny( xModel ) );
|
|
|
|
xDialogProps->setPropertyValue("Binding", makeAny( xBinding ) );
|
|
|
|
xDialogProps->setPropertyValue("FacetName", makeAny( sFacetName ) );
|
2004-11-16 11:05:03 +00:00
|
|
|
|
|
|
|
if ( !xDialog->execute() )
|
|
|
|
// cancelled
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
return InteractiveSelectionResult_Cancelled;
|
2004-11-16 11:05:03 +00:00
|
|
|
|
2013-06-29 21:24:12 +02:00
|
|
|
_rData = xDialogProps->getPropertyValue("ConditionValue");
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
return InteractiveSelectionResult_ObtainedValue;
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
catch( const Exception& )
|
|
|
|
{
|
2011-03-19 14:06:18 +01:00
|
|
|
OSL_FAIL( "EFormsPropertyHandler::onInteractivePropertySelection: caught an exception!" );
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// something went wrong here ...(but has been asserted already)
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
return InteractiveSelectionResult_Cancelled;
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
void SAL_CALL EFormsPropertyHandler::addPropertyChangeListener( const Reference< XPropertyChangeListener >& _rxListener )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
|
|
|
EFormsPropertyHandler_Base::addPropertyChangeListener( _rxListener );
|
2018-10-16 15:23:12 +02:00
|
|
|
if (m_pHelper)
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
m_pHelper->registerBindingListener( _rxListener );
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
void SAL_CALL EFormsPropertyHandler::removePropertyChangeListener( const Reference< XPropertyChangeListener >& _rxListener )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2018-10-16 15:23:12 +02:00
|
|
|
if (m_pHelper)
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
m_pHelper->revokeBindingListener( _rxListener );
|
|
|
|
EFormsPropertyHandler_Base::removePropertyChangeListener( _rxListener );
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
void SAL_CALL EFormsPropertyHandler::actuatingPropertyChanged( const OUString& _rActuatingPropertyName, const Any& _rNewValue, const Any& /*_rOldValue*/, const Reference< XObjectInspectorUI >& _rxInspectorUI, sal_Bool )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
if ( !_rxInspectorUI.is() )
|
|
|
|
throw NullPointerException();
|
2004-11-16 11:05:03 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
::osl::MutexGuard aGuard( m_aMutex );
|
2014-06-13 13:19:14 +01:00
|
|
|
PropertyId nActuatingPropId( impl_getPropertyId_throwRuntime( _rActuatingPropertyName ) );
|
2019-06-10 16:56:38 +00:00
|
|
|
OSL_PRECOND(m_pHelper, "EFormsPropertyHandler::actuatingPropertyChanged: inconsistency!");
|
2018-10-16 15:23:12 +02:00
|
|
|
// if we survived impl_getPropertyId_throwRuntime, we should have a helper, since no helper implies no properties
|
2004-11-16 11:05:03 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
DBG_ASSERT( _rxInspectorUI.is(), "EFormsPropertyHandler::actuatingPropertyChanged: invalid callback!" );
|
|
|
|
if ( !_rxInspectorUI.is() )
|
2004-11-16 11:05:03 +00:00
|
|
|
return;
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
switch ( nActuatingPropId )
|
2004-11-16 11:05:03 +00:00
|
|
|
{
|
|
|
|
case PROPERTY_ID_XML_DATA_MODEL:
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
if ( m_bSimulatingModelChange )
|
|
|
|
break;
|
2013-04-07 12:06:47 +02:00
|
|
|
OUString sDataModelName;
|
2004-11-16 11:05:03 +00:00
|
|
|
OSL_VERIFY( _rNewValue >>= sDataModelName );
|
2014-04-30 11:46:15 +02:00
|
|
|
bool bBoundToSomeModel = !sDataModelName.isEmpty();
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
_rxInspectorUI->rebuildPropertyUI( PROPERTY_BINDING_NAME );
|
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_BINDING_NAME, bBoundToSomeModel );
|
2018-12-08 09:46:01 +01:00
|
|
|
[[fallthrough]];
|
2005-07-01 10:50:00 +00:00
|
|
|
}
|
2004-11-16 11:05:03 +00:00
|
|
|
|
2005-07-01 10:50:00 +00:00
|
|
|
case PROPERTY_ID_BINDING_NAME:
|
|
|
|
{
|
2014-04-30 11:46:15 +02:00
|
|
|
bool bHaveABinding = !m_pHelper->getCurrentBindingName().isEmpty();
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_BIND_EXPRESSION, bHaveABinding );
|
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_XSD_REQUIRED, bHaveABinding );
|
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_XSD_RELEVANT, bHaveABinding );
|
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_XSD_READONLY, bHaveABinding );
|
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_XSD_CONSTRAINT, bHaveABinding );
|
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_XSD_CALCULATION, bHaveABinding );
|
|
|
|
_rxInspectorUI->enablePropertyUI( PROPERTY_XSD_DATA_TYPE, bHaveABinding );
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2011-03-01 17:55:09 +01:00
|
|
|
OSL_FAIL( "EFormsPropertyHandler::actuatingPropertyChanged: cannot handle this property!" );
|
INTEGRATION: CWS pbrwuno (1.4.38); FILE MERGED
2006/03/13 07:35:14 fs 1.4.38.17: more help ids
2006/02/15 07:25:53 fs 1.4.38.16: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:39 fs 1.4.38.15: #i10000# exception specifications
2005/10/25 07:13:09 fs 1.4.38.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:13 fs 1.4.38.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:18:58 fs 1.4.38.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:16 fs 1.4.38.11: some mutex locking
2005/10/14 12:43:44 fs 1.4.38.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:01 fs 1.4.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:03 fs 1.4.38.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 06:54:27 fs 1.4.38.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:48 fs 1.4.38.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:27 fs 1.4.38.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:38:59 fs 1.4.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 fs 1.4.38.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:44 fs 1.4.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:57 fs 1.4.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:21:39 +00:00
|
|
|
break;
|
2004-11-16 11:05:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2004-11-16 11:05:03 +00:00
|
|
|
} // namespace pcr
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2004-11-16 11:05:03 +00:00
|
|
|
|
2010-10-12 15:57:08 +02:00
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|