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

638 lines
28 KiB
C++
Raw Normal View History

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
*
* $RCSfile: eformspropertyhandler.cxx,v $
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
*
* $Revision: 1.8 $
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
*
* last change: $Author: obo $ $Date: 2006-09-16 13:16:19 $
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 Contents of this file are made available subject to
* the terms of GNU Lesser General Public License Version 2.1.
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
*
*
* GNU Lesser General Public License Version 2.1
* =============================================
* Copyright 2005 by Sun Microsystems, Inc.
* 901 San Antonio Road, Palo Alto, CA 94303, USA
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 library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License version 2.1, 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
*
* This library 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 for more details.
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 along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
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
*
************************************************************************/
// MARKER(update_precomp.py): autogen include statement, do not remove
#include "precompiled_extensions.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
#ifndef EXTENSIONS_SOURCE_PROPCTRLR_EFORMSPROPERTYHANDLER_HXX
#include "eformspropertyhandler.hxx"
#endif
#ifndef _EXTENSIONS_FORMSCTRLR_FORMSTRINGS_HXX_
#include "formstrings.hxx"
#endif
#ifndef _EXTENSIONS_PROPCTRLR_FORMMETADATA_HXX_
#include "formmetadata.hxx"
#endif
#ifndef EXTENSIONS_INC_EXTENSIO_HRC
#include "extensio.hrc"
#endif
#ifndef _EXTENSIONS_FORMSCTRLR_FORMBROWSERTOOLS_HXX_
#include "formbrowsertools.hxx"
#endif
#ifndef EXTENSIONS_SOURCE_PROPCTRLR_EFORMSHELPER_HXX
#include "eformshelper.hxx"
#endif
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
#ifndef EXTENSIONS_SOURCE_PROPCTRLR_HANDLERHELPER_HXX
#include "handlerhelper.hxx"
#endif
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
/** === begin UNO includes === **/
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
#ifndef _COM_SUN_STAR_UI_DIALOGS_XEXECUTABLEDIALOG_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 <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
#endif
#ifndef _COM_SUN_STAR_INSPECTION_PROPERTYCONTROLTYPE_HPP_
#include <com/sun/star/inspection/PropertyControlType.hpp>
#endif
#ifndef _COM_SUN_STAR_INSPECTION_XOBJECTINSPECTORUI_HPP_
#include <com/sun/star/inspection/XObjectInspectorUI.hpp>
#endif
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
/** === end UNO includes === **/
#ifndef _TOOLS_DEBUG_HXX
#include <tools/debug.hxx>
#endif
#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.getLength() )
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:
DBG_ERROR( "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_ENSURE( sal_False, sMessage.getStr() );
#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.getLength() )
// 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:
DBG_ERROR( "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_ENSURE( sal_False, "EFormsPropertyHandler::setPropertyValue: caught an exception!" );
}
}
//--------------------------------------------------------------------
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
}
//--------------------------------------------------------------------
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.getLength() )
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 = UID_PROP_DLG_BIND_EXPRESSION; break;
case PROPERTY_ID_XSD_REQUIRED: aDescriptor.PrimaryButtonId = UID_PROP_DLG_XSD_REQUIRED; break;
case PROPERTY_ID_XSD_RELEVANT: aDescriptor.PrimaryButtonId = UID_PROP_DLG_XSD_RELEVANT; break;
case PROPERTY_ID_XSD_READONLY: aDescriptor.PrimaryButtonId = UID_PROP_DLG_XSD_READONLY; break;
case PROPERTY_ID_XSD_CONSTRAINT: aDescriptor.PrimaryButtonId = UID_PROP_DLG_XSD_CONSTRAINT; break;
case PROPERTY_ID_XSD_CALCULATION: aDescriptor.PrimaryButtonId = UID_PROP_DLG_XSD_CALCULATION; break;
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:
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_ERROR( "EFormsPropertyHandler::describePropertyLine: cannot handle this property!" );
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 );
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 );
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 ) );
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( ( 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.getLength(),
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!" );
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 ( !( xModel.is() && xBinding.is() && sFacetName.getLength() ) )
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& )
{
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( sal_False, "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 );
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_Bool bBoundToSomeModel = 0 != sDataModelName.getLength();
_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:
{
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_Bool bHaveABinding = ( m_pHelper->getCurrentBindingName().getLength() > 0 );
_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:
DBG_ERROR( "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
//........................................................................