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

615 lines
28 KiB
C++
Raw Normal View History

/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
/*************************************************************************
*
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
*
* Copyright 2000, 2010 Oracle and/or its affiliates.
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
*
* OpenOffice.org - a multi-platform office productivity suite
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
*
* This file is part of OpenOffice.org.
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
*
* OpenOffice.org is free software: you can redistribute it and/or modify
* it under the terms of the GNU Lesser General Public License version 3
* only, as published by the Free Software Foundation.
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
*
* OpenOffice.org is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Lesser General Public License version 3 for more details
* (a copy is included in the LICENSE file that accompanied this code).
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
*
* You should have received a copy of the GNU Lesser General Public License
* version 3 along with OpenOffice.org. If not, see
* <http://www.openoffice.org/license.html>
* for a copy of the LGPLv3 License.
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
*
************************************************************************/
#include "eformspropertyhandler.hxx"
#include "formstrings.hxx"
#include "formmetadata.hxx"
dba33a: summary migration from SVN 2009-11-06 13:10:39 +0000 msc r277387 : minor fix for automatic test 2009-11-06 13:09:33 +0000 msc r277385 : minor fix for automatic test 2009-11-06 12:30:57 +0000 fs r277383 : argh. On some virtual machines, waiting 5 seconds for the event to arrive is not enough. Increasing the timeout ... 2009-11-06 12:13:34 +0000 fs r277382 : this diagnostic code should not have slipped in 2009-11-05 13:21:06 +0000 fs r277369 : SHL2NOCHECK=TRUE (requested by hjs) 2009-11-04 14:09:46 +0000 msc r277355 : minor fix for automatic testing 2009-11-04 13:23:02 +0000 msc r277352 : minor fix for automatic testing 2009-11-04 10:53:28 +0000 msc r277341 : minor fix for automated testscript 2009-11-04 08:30:58 +0000 msc r277333 : minor fix for automatic test 2009-11-04 08:15:43 +0000 msc r277332 : minor fix for automatic test 2009-11-03 14:25:44 +0000 fs r277324 : #i10000# 2009-11-03 09:47:47 +0000 fs r277315 : found yet another help ID zombie ... moved formhelpid.hrc content to propctrlr.hrc, where it belongs 2009-11-03 08:50:24 +0000 fs r277312 : use createTempFileURL, which cares for some more specialities ... 2009-11-03 08:44:55 +0000 fs r277311 : when creating a temp file for purpose of getting a temp file URL, the delete the file immediately. On some machines/JVMs, the file exists, with write access denied, which isn't Good (TM) 2009-10-22 13:06:17 +0000 fs r277126 : removed wrong assertion 2009-10-21 08:10:35 +0000 fs r277077 : reverted the previous change, which was nonsense 2009-10-21 07:19:43 +0000 fs r277076 : export the component_foo functions, now that some of the objects are built with VISIBILITY_HIDDEN=TRUE 2009-10-21 07:08:35 +0000 fs r277075 : spare useless call 2009-10-20 21:26:31 +0000 fs r277072 : #i10000# 2009-10-20 08:06:04 +0000 fs r277039 : CWS-TOOLING: rebase CWS dba33a to trunk@277035 (milestone: DEV300:m62) 2009-10-16 09:55:25 +0000 fs r276960 : remove one of the superfluous implts_doLayout calls introduced with the previous patch 2009-10-15 13:18:52 +0000 fs r276941 : removed the basic tests. According to cn, they're not used anymore (for a long time), and according to 'du -h', they take up 6.0M on my hard disc. For too much for useless code, /me thinks. 2009-10-15 13:06:51 +0000 fs r276940 : #i10000# remove useless include (otherwise the compiler warning it provokes would need to be fixed by declaring VISIBILITY_HIDDEN=TRUE in the makefile.mk) 2009-10-15 12:52:39 +0000 fs r276939 : #i10000# 2009-10-15 12:44:26 +0000 fs r276938 : #i10000# 2009-10-15 12:00:33 +0000 fs r276936 : #i10000# 2009-10-15 10:31:37 +0000 fs r276934 : #i105259# prepare for the Hidden arg 2009-10-15 10:31:05 +0000 fs r276933 : IsMaximized -> const 2009-10-15 09:50:15 +0000 fs r276932 : during #i105259#: introduce an option to the layout manager to preserve, if possible, the size of the content window when layouting. Enable this option for embedded (SFX-based) documents opened for outplace editing. (the option is incompatible with in-place editing, anyway) This is because such embedded objects couple the (content) window size to the VisAreaSize, in that both are used interchangeably. When an embedded object is closed, it remembers the VisAreaSize, and restores it upon next open. This, however, leads to different content window sizes when the window is closed with another toolbar set than used during opening. This patch here prevents those different content window sizes. Also, now the content window size doesn't change when, explicitly or implicitly, a toolbar is shown or hidden. Instead, the content window size stays the same, and the container window size is adjusted. 2009-10-15 09:32:41 +0000 fs r276931 : during #i105259#: UNO access to more attributes of top windows 2009-10-15 09:30:28 +0000 fs r276930 : indention corrected (better readable) 2009-10-15 09:26:46 +0000 fs r276929 : during #i105259#: access to more attributes of top windows 2009-10-14 10:04:39 +0000 fs r276889 : connecting via services manager, not naming service 2009-10-12 11:31:08 +0000 fs r276831 : during #i105806# FillPropertySet: do not attempt to set *AutoStyleName if it doesn't exist 2009-10-12 11:24:44 +0000 fs r276830 : #i105806# getPropertyValue: throw an UnknownPropertyException for, well, unknown properties 2009-10-08 08:20:58 +0000 fs r276774 : implSubmit: re-throw WrappedTargetExceptions unmodified 2009-10-07 19:19:42 +0000 fs r276770 : #i105198# do not pass an CommandType if we do not have a command 2009-10-07 17:39:36 +0000 fs r276768 : export the OWeakObject::disposeWeakConnectionPoint symbol 2009-10-07 12:59:17 +0000 fs r276754 : #i87693# 2009-10-07 11:19:22 +0000 fs r276752 : #i10000# 2009-10-07 10:21:08 +0000 fs r276748 : #105482# do not require a controller, at least not in *all* circumstances (executed reports have a model, the ReportDefinition, but no Controller) 2009-10-07 10:04:08 +0000 fs r276747 : copying the changes from CWS fwk121 herein, in particular the fix for issue #i105371# 2009-10-07 09:58:30 +0000 fs r276746 : copying the changes from CWS fwk121 herein, in particular the fix for issue #i105371# 2009-10-07 09:48:14 +0000 fs r276744 : removed (now) pointless assertion 2009-10-07 06:59:19 +0000 fs r276740 : export the OWeakObject::disposeWeakConnectionPoint symbol 2009-10-07 06:44:43 +0000 fs r276739 : OComponentHelper::release & WeakAggComponentImplHelperBase::release: when our ref count drops to 0, call OWeakObject's disposeWeakConnectionPoint before (temporarily) incrementing the ref count, again. This ensures that our adapter cannot create references to the dying object anymore. (A complex test case in dbaccess (#i105505#) triggered such a situation, but in another class using an analogous release/dispose/destroy pattern, namely WeakComponentImplHelperBase) 2009-10-07 06:37:20 +0000 fs r276738 : found during some new complex test cases: call disposeWeakConnectionPoint before actually starting to destroy the object, this ensures no other threads will resurrect it while it is dying 2009-10-06 21:58:24 +0000 fs r276734 : oops, two small corrections to the previous fix (hey, complex test cases are cool) 2009-10-06 21:51:16 +0000 fs r276733 : log the name of the data source which cannot be revoked 2009-10-06 21:50:41 +0000 fs r276732 : more detailed error message when cleanup fails 2009-10-06 21:50:01 +0000 fs r276731 : reworked the ModelImpl caching. The new and improved UNO API test for css.sdb.RowSet revealed some inconsistencies, in whether the objects are cached by their URL, or by their registration name. This has been changed to caching by registration name. 2009-10-06 13:50:34 +0000 fs r276714 : print diagnostics when we cannot clean up the test case 2009-10-06 13:45:02 +0000 fs r276713 : this test failed all the time, since the core (rightfully) threw an exception. Disabled it for the moment, until issue 84253 is fixed 2009-10-06 12:52:46 +0000 fs r276711 : rewrote this test. Now we do not re-use the same .odb across different test cases, as this leads to unreliable (timing-dependent) results/failures. Instead, every test sets up a new odb file. Also, did some re-factoring, improved the cleanup code, and caught a few more errors. 2009-10-06 12:51:07 +0000 fs r276710 : DBTools taking a logger now 2009-10-06 12:50:42 +0000 fs r276709 : taking a PrintWriter for logging purpose 2009-10-06 12:50:03 +0000 fs r276708 : DBTools taking a logger now 2009-10-06 12:49:22 +0000 fs r276707 : typo 2009-10-06 12:49:03 +0000 fs r276706 : typo 2009-10-06 12:48:52 +0000 fs r276705 : wrappers around some database-related services - initial versions only, to evolve over time, and intended to finally replace the DBTools class 2009-10-06 12:48:02 +0000 fs r276704 : typo 2009-10-06 12:38:42 +0000 fs r276702 : some better diagnostics, done during getting the API tests to work more reliably 2009-10-06 10:35:51 +0000 fs r276698 : when living in, e.g., the DataSourceBrowser, we can't expect to find an XModifiable2, so don't assert its existence 2009-10-05 12:47:52 +0000 oj r276677 : #i105607# check for read moved into if scope 2009-10-05 11:37:06 +0000 fs r276676 : when saving a file fails, retrieve the error message from the InteractionRequestStringResolver - this is better than any generic message we can create 2009-10-05 10:04:23 +0000 oj r276673 : #i105607# check for read moved into if scope 2009-10-05 09:46:17 +0000 fs r276671 : #i10000# 2009-10-05 08:43:58 +0000 fs r276664 : #i105505# release: dispose the (base classes) weak connection point before disposing ourself, and in particular before temporarily incrementing our ref count, again. This way, we prevent that a separate thread re-surrects us (using the weak connection point's queryAdapted) while we're in the process of destruction 2009-10-05 08:41:49 +0000 fs r276663 : #i105505# +disposeWeakConnectionPoint (outsourced into dedicated method from ::release) 2009-10-05 08:40:26 +0000 fs r276662 : no need to derived from OSubComponent, its features are not used, directly derive from WeakComponentImplFoo instead 2009-10-05 08:39:38 +0000 fs r276661 : #i105505# diagnostics 2009-10-05 08:39:16 +0000 fs r276660 : #i105505# +testDocumentRevenants 2009-10-05 08:36:01 +0000 fs r276659 : #i105560# reverted the removal of GenericController::openHelpAgent - this is needed in module reportdesign 2009-10-04 19:53:30 +0000 fs r276657 : #105560# remove unused code thanks to cmc@openoffice.org for submitting the patch 2009-10-04 19:50:28 +0000 fs r276656 : #i105550# remove unused 'fire' method (thanks to cmc) 2009-10-03 16:13:15 +0000 fs r276655 : CWS-TOOLING: rebase CWS dba33a to trunk@276429 (milestone: DEV300:m60) 2009-10-02 19:20:48 +0000 fs r276651 : #i104117# lotta changed IDs ... 2009-10-02 10:52:24 +0000 fs r276634 : #i105505# If a model is created, and is a revenant of a previous incarnation, then ensure it is properly initialized. In particular, in its ctor, set the state to "Initializing", not "Initialized", and then let the ModelImpl call attachResource. This ensures that the model is initialized completely, including firing the necessary events. 2009-10-02 10:51:08 +0000 fs r276633 : #i105505# always do an attachResource at the newly loaded model, even if it (internally) was not really loaded, but only a revenant of a previous incarnation of this document 2009-10-01 11:10:13 +0000 fs r276597 : do not rely on the name 'Standard' for the one and only form in a document 2009-10-01 10:36:29 +0000 fs r276590 : #i105509# don't rely on default form component names, use indexes 2009-10-01 09:12:20 +0000 fs r276582 : #i105505# 2009-09-30 07:55:21 +0000 fs r276542 : removed some unsed methods / spared some unnecessary pixel<->logic conversion 2009-09-30 07:53:22 +0000 fs r276541 : removed unneeded methods 2009-09-30 06:35:59 +0000 fs r276538 : #i10000# 2009-09-29 13:45:02 +0000 fs r276531 : refactored the Roadmap* classes, to be able to fix above-mentioned #i105113# 2009-09-29 10:27:10 +0000 fs r276520 : #i105367# 2009-09-29 08:46:45 +0000 fs r276510 : #i104956# cleaned up the makefiles 2009-09-28 21:00:07 +0000 fs r276505 : #i104117# sourced those IDs out from extension.hrc 2009-09-28 20:59:05 +0000 fs r276504 : no need to let one FREE... 2009-09-28 20:53:36 +0000 fs r276503 : #i104117# cleaned up the mess with help IDs in module extensions. Formerly, extensions used to use help IDs which were declared in module svx, and vice versa. Also, help ID ranges were not respected. 2009-09-28 11:25:36 +0000 fs r276489 : typo 2009-09-28 11:25:10 +0000 fs r276488 : #i105235# 2009-09-24 11:53:16 +0000 fs r276423 : #i105234# do not zoom the control when they view information is still uninitialized (happens at least in Writer when opening a form document) 2009-09-24 09:42:28 +0000 fs r276415 : #i105234# proper zoom handling for the nav bar 2009-09-24 09:42:19 +0000 fs r276414 : #i105234# setZoom: care for precision errors caused by implicit conversion float->double 2009-09-16 11:11:43 +0000 fs r276195 : #i105082# consolidated the sub storage handling, by delegating more functionality into the DocumentStorageAccess class. As a result, there won't be that many unnecessary commits anymore. Also, the two different storage caches (in ModelImpl::m_aStorages and DocumentStorageAccess::m_aExposedStorages) have been consolidated. This is not really part of the fix of issue 105082, but it helped reducing the calls to the storage/package implementation. 2009-09-15 21:42:27 +0000 fs r276190 : don't calculate space for BOLD if the text is not really bold (speeds up rendering for large tree structures) 2009-09-15 20:20:23 +0000 fs r276188 : getTypeInfo: fill m_aTypeInfoRows only if really all type infos could be retrieved 2009-09-15 20:19:29 +0000 fs r276187 : do not continue loading when the controller initialization throws an error 2009-09-14 12:25:57 +0000 fs r276119 : oops, this patch was not intended for this CWS 2009-09-14 12:13:57 +0000 fs r276114 : #cr6875455# introduce a ReferenceDevice property for various control models 2009-09-14 10:33:02 +0000 fs r276106 : removed dead file 2009-09-09 08:37:31 +0000 fs r275972 : remove OSL_TRACE in VCLXButton dtor 2009-09-08 11:19:17 +0000 oj r275926 : i76534# remove mnemonic from fixed text 2009-09-07 08:39:37 +0000 fs r275874 : create CWS dba33a from cws/dba32g@275857 (CWS: dba32g)
2009-11-27 12:39:32 +00:00
#include "propctrlr.hrc"
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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"
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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>
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
#include <tools/debug.hxx>
#include <functional>
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
//------------------------------------------------------------------------
extern "C" void SAL_CALL createRegistryInfo_EFormsPropertyHandler()
{
::pcr::EFormsPropertyHandler::registerImplementation();
}
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
//........................................................................
namespace pcr
{
//........................................................................
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;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
//====================================================================
//= 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
DBG_NAME( EFormsPropertyHandler )
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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
EFormsPropertyHandler::EFormsPropertyHandler( const Reference< XComponentContext >& _rxContext )
:EFormsPropertyHandler_Base( _rxContext )
,m_bSimulatingModelChange( false )
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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_CTOR( EFormsPropertyHandler, NULL );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
}
//--------------------------------------------------------------------
EFormsPropertyHandler::~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
DBG_DTOR( EFormsPropertyHandler, NULL );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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
::rtl::OUString SAL_CALL EFormsPropertyHandler::getImplementationName_static( ) throw (RuntimeException)
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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
return ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "com.sun.star.comp.extensions.EFormsPropertyHandler" ) );
}
//--------------------------------------------------------------------
Sequence< ::rtl::OUString > SAL_CALL EFormsPropertyHandler::getSupportedServiceNames_static( ) throw (RuntimeException)
{
Sequence< ::rtl::OUString > aSupported( 1 );
aSupported[0] = ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "com.sun.star.form.inspection.XMLFormsPropertyHandler" ) );
return aSupported;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
}
//--------------------------------------------------------------------
::rtl::OUString EFormsPropertyHandler::getModelNamePropertyValue() const
{
::rtl::OUString sModelName = m_pHelper->getCurrentFormModelName();
if ( sModelName.isEmpty() )
sModelName = m_sBindingLessModelName;
return sModelName;
}
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 SAL_CALL EFormsPropertyHandler::getPropertyValue( const ::rtl::OUString& _rPropertyName ) throw (UnknownPropertyException, RuntimeException)
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 );
PropertyId nPropId( impl_getPropertyId_throw( _rPropertyName ) );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
OSL_ENSURE( m_pHelper.get(), "EFormsPropertyHandler::getPropertyValue: we don't have any SupportedProperties!" );
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 we survived impl_getPropertyId_throw, we should have a helper, since no helper implies no properties
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 )
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
{
case PROPERTY_ID_LIST_BINDING:
aReturn <<= m_pHelper->getCurrentListSourceBinding();
break;
case PROPERTY_ID_XML_DATA_MODEL:
aReturn <<= getModelNamePropertyValue();
break;
case PROPERTY_ID_BINDING_NAME:
aReturn <<= m_pHelper->getCurrentBindingName();
break;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
DBG_ASSERT( aReturn.getValueType().equals( ::getCppuType( static_cast< ::rtl::OUString* >( NULL ) ) ),
"EFormsPropertyHandler::getPropertyValue: invalid BindingExpression value type!" );
}
else
aReturn <<= ::rtl::OUString();
}
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;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
}
}
catch( const Exception& )
{
#if OSL_DEBUG_LEVEL > 0
::rtl::OString sMessage( "EFormsPropertyHandler::getPropertyValue: caught an exception!" );
sMessage += "\n(have been asked for the \"";
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
sMessage += ::rtl::OString( _rPropertyName.getStr(), _rPropertyName.getLength(), RTL_TEXTENCODING_ASCII_US );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
sMessage += "\" property.)";
OSL_FAIL( sMessage.getStr() );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
#endif
}
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
void SAL_CALL EFormsPropertyHandler::setPropertyValue( const ::rtl::OUString& _rPropertyName, const Any& _rValue ) throw (UnknownPropertyException, RuntimeException)
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 );
PropertyId nPropId( impl_getPropertyId_throw( _rPropertyName ) );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
OSL_ENSURE( m_pHelper.get(), "EFormsPropertyHandler::setPropertyValue: we don't have any SupportedProperties!" );
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 we survived impl_getPropertyId_throw, we should have a helper, since no helper implies no properties
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 )
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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:
{
OSL_VERIFY( _rValue >>= m_sBindingLessModelName );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
// if the model changed, reset the binding to NULL
if ( m_pHelper->getCurrentFormModelName() != m_sBindingLessModelName )
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
{
::rtl::OUString sOldBindingName = m_pHelper->getCurrentBindingName();
m_pHelper->setBinding( NULL );
firePropertyChange( PROPERTY_BINDING_NAME, PROPERTY_ID_BINDING_NAME,
makeAny( sOldBindingName ), makeAny( ::rtl::OUString() ) );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
}
}
break;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
case PROPERTY_ID_BINDING_NAME:
{
::rtl::OUString sNewBindingName;
OSL_VERIFY( _rValue >>= sNewBindingName );
bool bPreviouslyEmptyModel = !m_pHelper->getCurrentFormModel().is();
Reference< XPropertySet > xNewBinding;
if ( !sNewBindingName.isEmpty() )
// 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
//
// 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;
firePropertyChange( PROPERTY_XML_DATA_MODEL, PROPERTY_ID_XML_DATA_MODEL,
makeAny( ::rtl::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;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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() )
{
DBG_ASSERT( _rValue.getValueType().equals( ::getCppuType( static_cast< ::rtl::OUString* >( NULL ) ) ),
"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 );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
}
catch( const Exception& )
{
OSL_FAIL( "EFormsPropertyHandler::setPropertyValue: caught an exception!" );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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
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
m_pHelper.reset( NULL );
}
//--------------------------------------------------------------------
Sequence< Property > SAL_CALL EFormsPropertyHandler::doDescribeSupportedProperties() const
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
{
::std::vector< Property > aProperties;
if ( m_pHelper.get() )
{
if ( m_pHelper->canBindToAnyDataType() )
{
aProperties.reserve( 7 );
addStringPropertyDescription( aProperties, PROPERTY_XML_DATA_MODEL );
addStringPropertyDescription( aProperties, PROPERTY_BINDING_NAME );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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,
::getCppuType( static_cast< Reference< XListEntrySource > * >( NULL ) ) );
}
}
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 >();
return Sequence< Property >( &(*aProperties.begin()), aProperties.size() );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 SAL_CALL EFormsPropertyHandler::convertToPropertyValue( const ::rtl::OUString& _rPropertyName, const Any& _rControlValue ) throw (UnknownPropertyException, RuntimeException)
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
Any 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
OSL_ENSURE( m_pHelper.get(), "EFormsPropertyHandler::convertToPropertyValue: we have no SupportedProperties!" );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
if ( !m_pHelper.get() )
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 ) );
::rtl::OUString sControlValue;
switch ( nPropId )
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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!" );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
break;
}
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
Any SAL_CALL EFormsPropertyHandler::convertToControlValue( const ::rtl::OUString& _rPropertyName, const Any& _rPropertyValue, const Type& _rControlValueType ) throw (UnknownPropertyException, RuntimeException)
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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( m_pHelper.get(), "EFormsPropertyHandler::convertToControlValue: we have no SupportedProperties!" );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
if ( !m_pHelper.get() )
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 ) );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 )
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
if ( xListSourceBinding.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 <<= m_pHelper->getModelElementUIName( EFormsHelper::Binding, xListSourceBinding );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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
Sequence< ::rtl::OUString > SAL_CALL EFormsPropertyHandler::getActuatingProperties( ) throw (RuntimeException)
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
if ( !m_pHelper.get() )
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 Sequence< ::rtl::OUString >();
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
::std::vector< ::rtl::OUString > aInterestedInActuations( 2 );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
aInterestedInActuations[ 0 ] = PROPERTY_XML_DATA_MODEL;
aInterestedInActuations[ 1 ] = PROPERTY_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
return Sequence< ::rtl::OUString >( &(*aInterestedInActuations.begin()), aInterestedInActuations.size() );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
}
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
//--------------------------------------------------------------------
Sequence< ::rtl::OUString > SAL_CALL EFormsPropertyHandler::getSupersededProperties( ) throw (RuntimeException)
{
::osl::MutexGuard aGuard( m_aMutex );
if ( !m_pHelper.get() )
return Sequence< ::rtl::OUString >();
Sequence< ::rtl::OUString > aReturn( 1 );
aReturn[ 0 ] = PROPERTY_INPUT_REQUIRED;
return aReturn;
}
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
//--------------------------------------------------------------------
LineDescriptor SAL_CALL EFormsPropertyHandler::describePropertyLine( const ::rtl::OUString& _rPropertyName,
const Reference< XPropertyControlFactory >& _rxControlFactory )
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 (UnknownPropertyException, NullPointerException, RuntimeException)
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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();
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
if ( !m_pHelper.get() )
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();
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +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;
::std::vector< ::rtl::OUString > aListEntries;
PropertyId nPropId( impl_getPropertyId_throw( _rPropertyName ) );
switch ( nPropId )
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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;
const_cast< EFormsHelper* >( m_pHelper.get() )->getAllElementUINames( EFormsHelper::Binding, aListEntries, true );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
break;
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;
::rtl::OUString sCurrentModel( getModelNamePropertyValue() );
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 );
}
break;
case PROPERTY_ID_BIND_EXPRESSION: aDescriptor.PrimaryButtonId = rtl::OUString::createFromAscii(UID_PROP_DLG_BIND_EXPRESSION); break;
case PROPERTY_ID_XSD_REQUIRED: aDescriptor.PrimaryButtonId = rtl::OUString::createFromAscii(UID_PROP_DLG_XSD_REQUIRED); break;
case PROPERTY_ID_XSD_RELEVANT: aDescriptor.PrimaryButtonId = rtl::OUString::createFromAscii(UID_PROP_DLG_XSD_RELEVANT); break;
case PROPERTY_ID_XSD_READONLY: aDescriptor.PrimaryButtonId = rtl::OUString::createFromAscii(UID_PROP_DLG_XSD_READONLY); break;
case PROPERTY_ID_XSD_CONSTRAINT: aDescriptor.PrimaryButtonId = rtl::OUString::createFromAscii(UID_PROP_DLG_XSD_CONSTRAINT); break;
case PROPERTY_ID_XSD_CALCULATION: aDescriptor.PrimaryButtonId = rtl::OUString::createFromAscii(UID_PROP_DLG_XSD_CALCULATION); break;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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:
aDescriptor.Control = PropertyHandlerHelper::createListBoxControl( _rxControlFactory, aListEntries, sal_False, sal_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:
aDescriptor.Control = PropertyHandlerHelper::createComboBoxControl( _rxControlFactory, aListEntries, sal_False, sal_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:
aDescriptor.Control = _rxControlFactory->createPropertyControl( nControlType, sal_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;
}
aDescriptor.DisplayName = m_pInfoService->getPropertyTranslation( nPropId );
aDescriptor.Category = ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "Data" ) );
aDescriptor.HelpURL = HelpIdUrl::getHelpURL( m_pInfoService->getPropertyHelpId( nPropId ) );
return aDescriptor;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
}
//--------------------------------------------------------------------
InteractiveSelectionResult SAL_CALL EFormsPropertyHandler::onInteractivePropertySelection( const ::rtl::OUString& _rPropertyName, sal_Bool /*_bPrimary*/, Any& _rData, const Reference< XObjectInspectorUI >& _rxInspectorUI ) throw (UnknownPropertyException, NullPointerException, RuntimeException)
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 );
OSL_ENSURE( m_pHelper.get(), "EFormsPropertyHandler::onInteractivePropertySelection: we do not have any SupportedProperties!" );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
if ( !m_pHelper.get() )
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;
PropertyId nPropId( impl_getPropertyId_throw( _rPropertyName ) );
(void)nPropId;
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!" );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
try
{
Reference< XExecutableDialog > xDialog;
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_aContext.createComponent( "com.sun.star.xforms.ui.dialogs.AddCondition", xDialog );
Reference< XPropertySet > xDialogProps( xDialog, UNO_QUERY_THROW );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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
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
::rtl::OUString sFacetName( _rPropertyName );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00: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!" );
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;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
xDialogProps->setPropertyValue( ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "FormModel" ) ), makeAny( xModel ) );
xDialogProps->setPropertyValue( ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "Binding" ) ), makeAny( xBinding ) );
xDialogProps->setPropertyValue( ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "FacetName" ) ), makeAny( sFacetName ) );
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;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
_rData = xDialogProps->getPropertyValue( ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "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;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
}
catch( const Exception& )
{
OSL_FAIL( "EFormsPropertyHandler::onInteractivePropertySelection: caught an exception!" );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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
void SAL_CALL EFormsPropertyHandler::addPropertyChangeListener( const Reference< XPropertyChangeListener >& _rxListener ) throw (RuntimeException)
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 );
if ( m_pHelper.get() )
m_pHelper->registerBindingListener( _rxListener );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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
void SAL_CALL EFormsPropertyHandler::removePropertyChangeListener( const Reference< XPropertyChangeListener >& _rxListener ) throw (RuntimeException)
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 ( m_pHelper.get() )
m_pHelper->revokeBindingListener( _rxListener );
EFormsPropertyHandler_Base::removePropertyChangeListener( _rxListener );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
}
//--------------------------------------------------------------------
void SAL_CALL EFormsPropertyHandler::actuatingPropertyChanged( const ::rtl::OUString& _rActuatingPropertyName, const Any& _rNewValue, const Any& /*_rOldValue*/, const Reference< XObjectInspectorUI >& _rxInspectorUI, sal_Bool ) throw (NullPointerException, RuntimeException)
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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();
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 );
PropertyId nActuatingPropId( impl_getPropertyId_throw( _rActuatingPropertyName ) );
OSL_PRECOND( m_pHelper.get(), "EFormsPropertyHandler::actuatingPropertyChanged: inconsistentcy!" );
// if we survived impl_getPropertyId_throw, we should have a helper, since no helper implies no properties
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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() )
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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 )
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
::rtl::OUString sDataModelName;
OSL_VERIFY( _rNewValue >>= sDataModelName );
sal_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 );
}
// NO break
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
case PROPERTY_ID_BINDING_NAME:
{
sal_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 );
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
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;
INTEGRATION: CWS eforms2 (1.1.2); FILE ADDED 2004/10/01 10:47:00 fs 1.1.2.16: #i34792# ConditionDialog does not automatically set the condition value at the binding, anymore 2004/08/04 13:45:57 fs 1.1.2.15: new logical name for a newly created binding / also allow de-selecting a binding-list-source 2004/08/04 13:00:11 fs 1.1.2.14: #i31958# use the XFormsUIHelper1 when generating UI names for submissions and bindings 2004/08/04 11:55:29 fs 1.1.2.13: #i31958# preliminary support for filling list and combo boxes from XML bindings 2004/08/04 08:28:12 fs 1.1.2.12: dialog for entering a binding expression changed in its API 2004/07/26 10:24:01 fs 1.1.2.11: #i31958# bind controls only to certain supported XSD data types 2004/07/23 13:27:01 fs 1.1.2.10: #i31958# 2004/07/23 13:04:01 fs 1.1.2.9: #i31958# bind the browse button 2004/07/22 10:37:28 fs 1.1.2.8: #i31762# pass the context document of the introspectee to some handlers 2004/07/22 09:04:45 fs 1.1.2.7: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition) 2004/07/20 12:11:36 fs 1.1.2.6: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for 2004/07/15 07:41:04 fs 1.1.2.5: #114856# cache supported properties 2004/07/12 14:27:11 fs 1.1.2.4: #114856# 2004/06/04 13:59:56 dvo 1.1.2.3: #114856# adapt propertycontroller to new API 2004/04/27 14:15:46 fs 1.1.2.2: property handlers can now express interest in actuating properties other than their own 2004/04/26 11:45:31 fs 1.1.2.1: handler for properties related to controls living in eForms
2004-11-16 11:05:03 +00:00
}
}
//........................................................................
} // namespace pcr
//........................................................................
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */