mir/libreoffice
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
4bc7e5d45849b1df37020c5aada63f3030f7268f
libreoffice/extensions/source/propctrlr/eventhandler.cxx

1216 lines
56 KiB
C++
Raw Normal View History

INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
/*************************************************************************
*
INTEGRATION: CWS changefileheader (1.12.14); FILE MERGED 2008/03/31 12:31:41 rt 1.12.14.1: #i87441# Change license header to LPGL v3.
2008-04-11 09:47:33 +00:00
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
*
INTEGRATION: CWS changefileheader (1.12.14); FILE MERGED 2008/03/31 12:31:41 rt 1.12.14.1: #i87441# Change license header to LPGL v3.
2008-04-11 09:47:33 +00:00
* Copyright 2008 by Sun Microsystems, Inc.
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
*
INTEGRATION: CWS changefileheader (1.12.14); FILE MERGED 2008/03/31 12:31:41 rt 1.12.14.1: #i87441# Change license header to LPGL v3.
2008-04-11 09:47:33 +00:00
* OpenOffice.org - a multi-platform office productivity suite
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
*
INTEGRATION: CWS changefileheader (1.12.14); FILE MERGED 2008/03/31 12:31:41 rt 1.12.14.1: #i87441# Change license header to LPGL v3.
2008-04-11 09:47:33 +00:00
* $RCSfile: eventhandler.cxx,v $
* $Revision: 1.13 $
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
*
INTEGRATION: CWS changefileheader (1.12.14); FILE MERGED 2008/03/31 12:31:41 rt 1.12.14.1: #i87441# Change license header to LPGL v3.
2008-04-11 09:47:33 +00:00
* This file is part of OpenOffice.org.
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
*
INTEGRATION: CWS changefileheader (1.12.14); FILE MERGED 2008/03/31 12:31:41 rt 1.12.14.1: #i87441# Change license header to LPGL v3.
2008-04-11 09:47:33 +00:00
* OpenOffice.org is free software: you can redistribute it and/or modify
* it under the terms of the GNU Lesser General Public License version 3
* only, as published by the Free Software Foundation.
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
*
INTEGRATION: CWS changefileheader (1.12.14); FILE MERGED 2008/03/31 12:31:41 rt 1.12.14.1: #i87441# Change license header to LPGL v3.
2008-04-11 09:47:33 +00:00
* OpenOffice.org is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Lesser General Public License version 3 for more details
* (a copy is included in the LICENSE file that accompanied this code).
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
*
INTEGRATION: CWS changefileheader (1.12.14); FILE MERGED 2008/03/31 12:31:41 rt 1.12.14.1: #i87441# Change license header to LPGL v3.
2008-04-11 09:47:33 +00:00
* You should have received a copy of the GNU Lesser General Public License
* version 3 along with OpenOffice.org. If not, see
* <http://www.openoffice.org/license.html>
* for a copy of the LGPLv3 License.
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
*
************************************************************************/
INTEGRATION: CWS pchfix02 (1.6.14); FILE MERGED 2006/09/01 17:26:40 kaib 1.6.14.1: #i68856# Added header markers and pch files
2006-09-16 12:16:34 +00:00
// MARKER(update_precomp.py): autogen include statement, do not remove
#include "precompiled_extensions.hxx"
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
#include "eventhandler.hxx"
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
#include "extensio.hrc"
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
#include "formbrowsertools.hxx"
#include "formresid.hrc"
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
#include "formstrings.hxx"
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
#include "handlerhelper.hxx"
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
#include "modulepcr.hxx"
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
#include "pcrcommon.hxx"
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
#include "pcrstrings.hxx"
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
/** === begin UNO includes === **/
#include <com/sun/star/awt/XTabControllerModel.hpp>
#include <com/sun/star/beans/PropertyAttribute.hpp>
#include <com/sun/star/beans/UnknownPropertyException.hpp>
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
#include <com/sun/star/beans/XIntrospection.hpp>
#include <com/sun/star/beans/XIntrospectionAccess.hpp>
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
#include <com/sun/star/container/NoSuchElementException.hpp>
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
#include <com/sun/star/container/XChild.hpp>
#include <com/sun/star/container/XIndexAccess.hpp>
#include <com/sun/star/container/XNameContainer.hpp>
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
#include <com/sun/star/container/XNameReplace.hpp>
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
#include <com/sun/star/form/XForm.hpp>
#include <com/sun/star/form/XFormController.hpp>
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
#include <com/sun/star/inspection/PropertyControlType.hpp>
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
#include <com/sun/star/lang/NullPointerException.hpp>
#include <com/sun/star/script/XEventAttacherManager.hpp>
#include <com/sun/star/script/XScriptEventsSupplier.hpp>
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
#include <com/sun/star/util/XModifiable.hpp>
/** === end UNO includes === **/
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
#include <comphelper/namedvaluecollection.hxx>
INTEGRATION: CWS odbmacros2 (1.10.8); FILE MERGED 2008/02/04 13:09:22 fs 1.10.8.2: RESYNC: (1.10-1.11); FILE MERGED 2007/12/12 14:36:04 fs 1.10.8.1: #i49133# when invoking the macro assignment dialog, pass it the frame of our context document
2008-03-06 17:42:26 +00:00
#include <comphelper/types.hxx>
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
#include <cppuhelper/implbase1.hxx>
#include <rtl/ref.hxx>
#include <rtl/ustrbuf.hxx>
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
#include <sfx2/app.hxx>
INTEGRATION: CWS ab28 (1.3.30); FILE MERGED 2006/07/10 13:43:15 ab 1.3.30.1: #i66948# Pass m_bIsDialogElement to AssignMacro dialog using ItemSet
2006-07-14 06:21:10 +00:00
#include <svtools/eitem.hxx>
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
#include <svtools/itemset.hxx>
#include <svx/svxdlg.hxx>
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
#include <svx/svxids.hrc>
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
#include <tools/diagnose_ex.h>
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
INTEGRATION: CWS dba23c (1.8.148); FILE MERGED 2007/07/20 21:02:54 fs 1.8.148.1: #i79731# remove ROW_HEIGHT, it is already present as ROWHEIGHT
2007-07-31 13:07:23 +00:00
#include <map>
INTEGRATION: CWS odbmacros2 (1.10.8); FILE MERGED 2008/02/04 13:09:22 fs 1.10.8.2: RESYNC: (1.10-1.11); FILE MERGED 2007/12/12 14:36:04 fs 1.10.8.1: #i49133# when invoking the macro assignment dialog, pass it the frame of our context document
2008-03-06 17:42:26 +00:00
#include <algorithm>
INTEGRATION: CWS dba23c (1.8.148); FILE MERGED 2007/07/20 21:02:54 fs 1.8.148.1: #i79731# remove ROW_HEIGHT, it is already present as ROWHEIGHT
2007-07-31 13:07:23 +00:00
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
//------------------------------------------------------------------------
extern "C" void SAL_CALL createRegistryInfo_EventHandler()
{
::pcr::OAutoRegistration< ::pcr::EventHandler > aAutoRegistration;
}
//........................................................................
namespace pcr
{
//........................................................................
/** === begin UNO using === **/
using ::com::sun::star::uno::Reference;
using ::com::sun::star::uno::XComponentContext;
using ::com::sun::star::beans::XPropertySet;
using ::com::sun::star::uno::Any;
using ::com::sun::star::uno::TypeClass_STRING;
using ::com::sun::star::uno::Type;
using ::com::sun::star::beans::XPropertyChangeListener;
using ::com::sun::star::beans::Property;
using ::com::sun::star::beans::PropertyState;
using ::com::sun::star::beans::PropertyState_DIRECT_VALUE;
using ::com::sun::star::uno::Sequence;
using ::com::sun::star::script::ScriptEventDescriptor;
using ::com::sun::star::script::XScriptEventsSupplier;
using ::com::sun::star::lang::NullPointerException;
using ::com::sun::star::uno::Exception;
using ::com::sun::star::container::XChild;
using ::com::sun::star::container::XIndexAccess;
using ::com::sun::star::script::XEventAttacherManager;
using ::com::sun::star::uno::UNO_QUERY;
using ::com::sun::star::uno::UNO_QUERY_THROW;
using ::com::sun::star::uno::XInterface;
using ::com::sun::star::beans::XIntrospection;
using ::com::sun::star::beans::XIntrospectionAccess;
using ::com::sun::star::container::XNameContainer;
using ::com::sun::star::awt::XTabControllerModel;
using ::com::sun::star::form::XForm;
using ::com::sun::star::form::XFormController;
using ::com::sun::star::beans::UnknownPropertyException;
using ::com::sun::star::uno::makeAny;
using ::com::sun::star::container::NoSuchElementException;
using ::com::sun::star::beans::XPropertySetInfo;
using ::com::sun::star::container::XNameReplace;
using ::com::sun::star::lang::IllegalArgumentException;
using ::com::sun::star::lang::WrappedTargetException;
using ::com::sun::star::uno::RuntimeException;
using ::com::sun::star::beans::PropertyValue;
using ::com::sun::star::inspection::LineDescriptor;
using ::com::sun::star::inspection::XPropertyControlFactory;
using ::com::sun::star::inspection::InteractiveSelectionResult;
using ::com::sun::star::inspection::InteractiveSelectionResult_Cancelled;
using ::com::sun::star::inspection::InteractiveSelectionResult_Success;
using ::com::sun::star::inspection::XObjectInspectorUI;
using ::com::sun::star::util::XModifiable;
using ::com::sun::star::beans::PropertyChangeEvent;
INTEGRATION: CWS odbmacros2 (1.10.8); FILE MERGED 2008/02/04 13:09:22 fs 1.10.8.2: RESYNC: (1.10-1.11); FILE MERGED 2007/12/12 14:36:04 fs 1.10.8.1: #i49133# when invoking the macro assignment dialog, pass it the frame of our context document
2008-03-06 17:42:26 +00:00
using ::com::sun::star::frame::XFrame;
using ::com::sun::star::frame::XModel;
using ::com::sun::star::frame::XController;
using ::com::sun::star::uno::UNO_SET_THROW;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
/** === end UNO using === **/
namespace PropertyControlType = ::com::sun::star::inspection::PropertyControlType;
namespace PropertyAttribute = ::com::sun::star::beans::PropertyAttribute;
//====================================================================
//= EventDescription
//====================================================================
EventDescription::EventDescription( EventId _nId, const sal_Char* _pListenerNamespaceAscii, const sal_Char* _pListenerClassAsciiName,
const sal_Char* _pListenerMethodAsciiName, sal_uInt16 _nDisplayNameResId, sal_Int32 _nHelpId, sal_Int32 _nUniqueBrowseId )
INTEGRATION: CWS wae4extensions (1.9.30); FILE MERGED 2008/01/09 20:35:42 ericb 1.9.30.2: #i81612# a try to fix conflicts for resync with m242 2007/09/27 07:18:24 fs 1.9.30.1: #i81612# warning-free code
2008-01-14 13:57:12 +00:00
:sDisplayName( String( PcrRes( _nDisplayNameResId ) ) )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
,sListenerMethodName( ::rtl::OUString::createFromAscii( _pListenerMethodAsciiName ) )
,nHelpId( _nHelpId )
,nUniqueBrowseId( _nUniqueBrowseId )
INTEGRATION: CWS wae4extensions (1.9.30); FILE MERGED 2008/01/09 20:35:42 ericb 1.9.30.2: #i81612# a try to fix conflicts for resync with m242 2007/09/27 07:18:24 fs 1.9.30.1: #i81612# warning-free code
2008-01-14 13:57:12 +00:00
,nId( _nId )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
{
::rtl::OUStringBuffer aQualifiedListenerClass;
aQualifiedListenerClass.appendAscii( "com.sun.star." );
aQualifiedListenerClass.appendAscii( _pListenerNamespaceAscii );
aQualifiedListenerClass.appendAscii( "." );
aQualifiedListenerClass.appendAscii( _pListenerClassAsciiName );
sListenerClassName = aQualifiedListenerClass.makeStringAndClear();
}
//========================================================================
//= helper
//========================================================================
namespace
{
//....................................................................
Sequence< ::rtl::OUString > lcl_getListenerMethodsForType( const Type& type )
{
typelib_InterfaceTypeDescription *pType=0;
type.getDescription( (typelib_TypeDescription**)&pType);
if ( !pType )
return Sequence< ::rtl::OUString>();
Sequence< ::rtl::OUString > aNames( pType->nMembers );
::rtl::OUString* pNames = aNames.getArray();
for ( sal_Int32 i = 0; i < pType->nMembers; ++i, ++pNames)
{
// the decription reference
typelib_TypeDescriptionReference* pMemberDescriptionReference = pType->ppMembers[i];
// the description for the reference
typelib_TypeDescription* pMemberDescription = NULL;
typelib_typedescriptionreference_getDescription( &pMemberDescription, pMemberDescriptionReference );
if ( pMemberDescription )
{
typelib_InterfaceMemberTypeDescription* pRealMemberDescription =
reinterpret_cast<typelib_InterfaceMemberTypeDescription*>(pMemberDescription);
*pNames = pRealMemberDescription->pMemberName;
}
}
typelib_typedescription_release( (typelib_TypeDescription*)pType );
return aNames;
}
//....................................................................
#define DESCRIBE_EVENT( asciinamespace, asciilistener, asciimethod, id_postfix ) \
s_aKnownEvents.insert( EventMap::value_type( \
::rtl::OUString::createFromAscii( asciimethod ), \
EventDescription( ++nEventId, asciinamespace, asciilistener, asciimethod, RID_STR_EVT_##id_postfix, HID_EVT_##id_postfix, UID_BRWEVT_##id_postfix ) ) )
//....................................................................
bool lcl_getEventDescriptionForMethod( const ::rtl::OUString& _rMethodName, EventDescription& _out_rDescription )
{
static EventMap s_aKnownEvents;
if ( s_aKnownEvents.empty() )
{
::osl::MutexGuard aGuard( ::osl::Mutex::getGlobalMutex() );
if ( s_aKnownEvents.empty() )
{
static sal_Int32 nEventId = 0;
DESCRIBE_EVENT( "form", "XApproveActionListener", "approveAction", APPROVEACTIONPERFORMED );
DESCRIBE_EVENT( "awt", "XActionListener", "actionPerformed", ACTIONPERFORMED );
DESCRIBE_EVENT( "form", "XChangeListener", "changed", CHANGED );
DESCRIBE_EVENT( "awt", "XTextListener", "textChanged", TEXTCHANGED );
DESCRIBE_EVENT( "awt", "XItemListener", "itemStateChanged", ITEMSTATECHANGED );
DESCRIBE_EVENT( "awt", "XFocusListener", "focusGained", FOCUSGAINED );
DESCRIBE_EVENT( "awt", "XFocusListener", "focusLost", FOCUSLOST );
DESCRIBE_EVENT( "awt", "XKeyListener", "keyPressed", KEYTYPED );
DESCRIBE_EVENT( "awt", "XKeyListener", "keyReleased", KEYUP );
DESCRIBE_EVENT( "awt", "XMouseListener", "mouseEntered", MOUSEENTERED );
DESCRIBE_EVENT( "awt", "XMouseMotionListener", "mouseDragged", MOUSEDRAGGED );
DESCRIBE_EVENT( "awt", "XMouseMotionListener", "mouseMoved", MOUSEMOVED );
DESCRIBE_EVENT( "awt", "XMouseListener", "mousePressed", MOUSEPRESSED );
DESCRIBE_EVENT( "awt", "XMouseListener", "mouseReleased", MOUSERELEASED );
DESCRIBE_EVENT( "awt", "XMouseListener", "mouseExited", MOUSEEXITED );
DESCRIBE_EVENT( "form", "XResetListener", "approveReset", APPROVERESETTED );
INTEGRATION: CWS dba203c (1.2.12); FILE MERGED 2006/04/20 07:47:38 fs 1.2.12.3: #i64196# use FormController as secondary component only if it's really a form 2006/04/20 07:17:03 fs 1.2.12.2: proper fix for #ii64511#: XRowSetListener is in sdbc, not sdb 2006/04/19 13:33:11 fs 1.2.12.1: #i64511# proper event name in AddEvent call
2006-05-04 08:01:11 +00:00
DESCRIBE_EVENT( "form", "XResetListener", "resetted", RESETTED );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
DESCRIBE_EVENT( "form", "XSubmitListener", "approveSubmit", SUBMITTED );
DESCRIBE_EVENT( "form", "XUpdateListener", "approveUpdate", BEFOREUPDATE );
DESCRIBE_EVENT( "form", "XUpdateListener", "updated", AFTERUPDATE );
DESCRIBE_EVENT( "form", "XLoadListener", "loaded", LOADED );
DESCRIBE_EVENT( "form", "XLoadListener", "reloading", RELOADING );
DESCRIBE_EVENT( "form", "XLoadListener", "reloaded", RELOADED );
DESCRIBE_EVENT( "form", "XLoadListener", "unloading", UNLOADING );
DESCRIBE_EVENT( "form", "XLoadListener", "unloaded", UNLOADED );
DESCRIBE_EVENT( "form", "XConfirmDeleteListener", "confirmDelete", CONFIRMDELETE );
DESCRIBE_EVENT( "sdb", "XRowSetApproveListener", "approveRowChange", APPROVEROWCHANGE );
INTEGRATION: CWS dba203c (1.2.12); FILE MERGED 2006/04/20 07:47:38 fs 1.2.12.3: #i64196# use FormController as secondary component only if it's really a form 2006/04/20 07:17:03 fs 1.2.12.2: proper fix for #ii64511#: XRowSetListener is in sdbc, not sdb 2006/04/19 13:33:11 fs 1.2.12.1: #i64511# proper event name in AddEvent call
2006-05-04 08:01:11 +00:00
DESCRIBE_EVENT( "sdbc", "XRowSetListener", "rowChanged", ROWCHANGE );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
DESCRIBE_EVENT( "sdb", "XRowSetApproveListener", "approveCursorMove", POSITIONING );
INTEGRATION: CWS dba203c (1.2.12); FILE MERGED 2006/04/20 07:47:38 fs 1.2.12.3: #i64196# use FormController as secondary component only if it's really a form 2006/04/20 07:17:03 fs 1.2.12.2: proper fix for #ii64511#: XRowSetListener is in sdbc, not sdb 2006/04/19 13:33:11 fs 1.2.12.1: #i64511# proper event name in AddEvent call
2006-05-04 08:01:11 +00:00
DESCRIBE_EVENT( "sdbc", "XRowSetListener", "cursorMoved", POSITIONED );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
DESCRIBE_EVENT( "form", "XDatabaseParameterListener", "approveParameter", APPROVEPARAMETER );
DESCRIBE_EVENT( "sdb", "XSQLErrorListener", "errorOccured", ERROROCCURED );
DESCRIBE_EVENT( "awt", "XAdjustmentListener", "adjustmentValueChanged", ADJUSTMENTVALUECHANGED );
}
}
EventMap::const_iterator pos = s_aKnownEvents.find( _rMethodName );
if ( pos == s_aKnownEvents.end() )
return false;
_out_rDescription = pos->second;
return true;
}
//....................................................................
::rtl::OUString lcl_getEventPropertyName( const ::rtl::OUString& _rListenerClassName, const ::rtl::OUString& _rMethodName )
{
::rtl::OUStringBuffer aPropertyName;
aPropertyName.append( _rListenerClassName );
aPropertyName.append( (sal_Unicode)';' );
aPropertyName.append( _rMethodName.getStr() );
return aPropertyName.makeStringAndClear();
}
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
//................................................................
ScriptEventDescriptor lcl_getAssignedScriptEvent( const EventDescription& _rEvent, const Sequence< ScriptEventDescriptor >& _rAllAssignedMacros )
{
ScriptEventDescriptor aScriptEvent;
// for the case there is actually no event assigned, initialize at least ListenerType and MethodName,
// so this ScriptEventDescriptor properly describes the given event
aScriptEvent.ListenerType = _rEvent.sListenerClassName;
aScriptEvent.EventMethod = _rEvent.sListenerMethodName;
const ScriptEventDescriptor* pAssignedEvent = _rAllAssignedMacros.getConstArray();
sal_Int32 assignedEventCount( _rAllAssignedMacros.getLength() );
for ( sal_Int32 assignedEvent = 0; assignedEvent < assignedEventCount; ++assignedEvent, ++pAssignedEvent )
{
if ( ( pAssignedEvent->ListenerType != _rEvent.sListenerClassName )
|| ( pAssignedEvent->EventMethod != _rEvent.sListenerMethodName )
)
continue;
if ( ( pAssignedEvent->ScriptCode.getLength() == 0 )
|| ( pAssignedEvent->ScriptType.getLength() == 0 )
)
{
DBG_ERROR( "lcl_getAssignedScriptEvent: me thinks this should not happen!" );
continue;
}
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
aScriptEvent = *pAssignedEvent;
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
if ( !aScriptEvent.ScriptType.equalsAscii( "StarBasic" ) )
continue;
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
// this is an old-style macro specification:
// [document|application]:Library.Module.Function
// we need to translate this to the new-style macro specification
// vnd.sun.star.script:Library.Module.Function?language=Basic&location=[document|application]
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
sal_Int32 nPrefixLen = aScriptEvent.ScriptCode.indexOf( ':' );
OSL_ENSURE( nPrefixLen > 0, "lcl_getAssignedScriptEvent: illegal location!" );
::rtl::OUString sLocation = aScriptEvent.ScriptCode.copy( 0, nPrefixLen );
::rtl::OUString sMacroPath = aScriptEvent.ScriptCode.copy( nPrefixLen + 1 );
::rtl::OUStringBuffer aNewStyleSpec;
aNewStyleSpec.appendAscii( "vnd.sun.star.script:" );
aNewStyleSpec.append ( sMacroPath );
aNewStyleSpec.appendAscii( "?language=Basic&location=" );
aNewStyleSpec.append ( sLocation );
aScriptEvent.ScriptCode = aNewStyleSpec.makeStringAndClear();
// also, this new-style spec requires the script code to be "Script" instead of "StarBasic"
aScriptEvent.ScriptType = ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "Script" ) );
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
}
return aScriptEvent;
}
//................................................................
::rtl::OUString lcl_getQualifiedKnownListenerName( const ScriptEventDescriptor& _rFormComponentEventDescriptor )
{
EventDescription aKnownEvent;
if ( lcl_getEventDescriptionForMethod( _rFormComponentEventDescriptor.EventMethod, aKnownEvent ) )
return aKnownEvent.sListenerClassName;
DBG_ERROR( "lcl_getQualifiedKnownListenerName: unknown method name!" );
// somebody assigned an script to a form component event which we don't know
// Speaking strictly, this is not really an error - it is possible to do
// this programmatically -, but it should rarely happen, since it's not possible
// via UI
return _rFormComponentEventDescriptor.ListenerType;
}
//................................................................
typedef ::std::set< Type, TypeLessByName > TypeBag;
//................................................................
void lcl_addListenerTypesFor_throw( const Reference< XInterface >& _rxComponent,
const Reference< XIntrospection >& _rxIntrospection, TypeBag& _out_rTypes )
{
if ( !_rxComponent.is() )
return;
OSL_PRECOND( _rxIntrospection.is(), "lcl_addListenerTypesFor_throw: this will crash!" );
Reference< XIntrospectionAccess > xIntrospectionAccess(
_rxIntrospection->inspect( makeAny( _rxComponent ) ), UNO_QUERY_THROW );
Sequence< Type > aListeners( xIntrospectionAccess->getSupportedListeners() );
::std::copy( aListeners.getConstArray(), aListeners.getConstArray() + aListeners.getLength(),
::std::insert_iterator< TypeBag >( _out_rTypes, _out_rTypes.begin() ) );
}
//................................................................
bool operator ==( const ScriptEventDescriptor _lhs, const ScriptEventDescriptor _rhs )
{
return ( ( _lhs.ListenerType == _rhs.ListenerType )
&& ( _lhs.EventMethod == _rhs.EventMethod )
&& ( _lhs.AddListenerParam == _rhs.AddListenerParam )
&& ( _lhs.ScriptType == _rhs.ScriptType )
&& ( _lhs.ScriptCode == _rhs.ScriptCode )
);
}
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
}
//====================================================================
//= EventHandler
//====================================================================
typedef ::cppu::WeakImplHelper1 < ::com::sun::star::container::XNameReplace
> EventHolder_Base;
/** a UNO component holding assigned event descriptions, for use with a SvxMacroAssignDlg
*/
class EventHolder : public EventHolder_Base
{
private:
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
typedef ::std::hash_map< ::rtl::OUString, ScriptEventDescriptor, ::rtl::OUStringHash > EventMap;
typedef ::std::map< EventId, EventMap::iterator > EventMapIndexAccess;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
EventMap m_aEventNameAccess;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
EventMapIndexAccess m_aEventIndexAccess;
public:
EventHolder( );
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
void addEvent( EventId _nId, const ::rtl::OUString& _rEventName, const ScriptEventDescriptor& _rScriptEvent );
/** effectively the same as getByName, but instead of converting the ScriptEventDescriptor to the weird
format used by the macro assignment dialog, it is returned directly
*/
ScriptEventDescriptor getNormalizedDescriptorByName( const ::rtl::OUString& _rEventName ) const;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
// XNameReplace
virtual void SAL_CALL replaceByName( const ::rtl::OUString& _rName, const Any& aElement ) throw (IllegalArgumentException, NoSuchElementException, WrappedTargetException, RuntimeException);
virtual Any SAL_CALL getByName( const ::rtl::OUString& _rName ) throw (NoSuchElementException, WrappedTargetException, RuntimeException);
virtual Sequence< ::rtl::OUString > SAL_CALL getElementNames( ) throw (RuntimeException);
virtual ::sal_Bool SAL_CALL hasByName( const ::rtl::OUString& _rName ) throw (RuntimeException);
virtual Type SAL_CALL getElementType( ) throw (RuntimeException);
virtual ::sal_Bool SAL_CALL hasElements( ) throw (RuntimeException);
protected:
~EventHolder( );
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
private:
ScriptEventDescriptor impl_getDescriptor_throw( const ::rtl::OUString& _rEventName ) const;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
};
DBG_NAME( EventHolder )
//------------------------------------------------------------------------
EventHolder::EventHolder()
{
DBG_CTOR( EventHolder, NULL );
}
//------------------------------------------------------------------------
EventHolder::~EventHolder()
{
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
m_aEventNameAccess.clear();
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
m_aEventIndexAccess.clear();
DBG_DTOR( EventHolder, NULL );
}
//------------------------------------------------------------------------
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
void EventHolder::addEvent( EventId _nId, const ::rtl::OUString& _rEventName, const ScriptEventDescriptor& _rScriptEvent )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
{
::std::pair< EventMap::iterator, bool > insertionResult =
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
m_aEventNameAccess.insert( EventMap::value_type( _rEventName, _rScriptEvent ) );
OSL_ENSURE( insertionResult.second, "EventHolder::addEvent: there already was a MacroURL for this event!" );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
m_aEventIndexAccess[ _nId ] = insertionResult.first;
}
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
//------------------------------------------------------------------------
ScriptEventDescriptor EventHolder::getNormalizedDescriptorByName( const ::rtl::OUString& _rEventName ) const
{
return impl_getDescriptor_throw( _rEventName );
}
//------------------------------------------------------------------------
ScriptEventDescriptor EventHolder::impl_getDescriptor_throw( const ::rtl::OUString& _rEventName ) const
{
EventMap::const_iterator pos = m_aEventNameAccess.find( _rEventName );
if ( pos == m_aEventNameAccess.end() )
throw NoSuchElementException( ::rtl::OUString(), *const_cast< EventHolder* >( this ) );
return pos->second;
}
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
//------------------------------------------------------------------------
void SAL_CALL EventHolder::replaceByName( const ::rtl::OUString& _rName, const Any& _rElement ) throw (IllegalArgumentException, NoSuchElementException, WrappedTargetException, RuntimeException)
{
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
EventMap::iterator pos = m_aEventNameAccess.find( _rName );
if ( pos == m_aEventNameAccess.end() )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
throw NoSuchElementException( ::rtl::OUString(), *this );
Sequence< PropertyValue > aScriptDescriptor;
OSL_VERIFY( _rElement >>= aScriptDescriptor );
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
::comphelper::NamedValueCollection aExtractor( aScriptDescriptor );
pos->second.ScriptType = aExtractor.getOrDefault( "EventType", ::rtl::OUString() );
pos->second.ScriptCode = aExtractor.getOrDefault( "Script", ::rtl::OUString() );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
}
//------------------------------------------------------------------------
Any SAL_CALL EventHolder::getByName( const ::rtl::OUString& _rName ) throw (NoSuchElementException, WrappedTargetException, RuntimeException)
{
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
ScriptEventDescriptor aDescriptor( impl_getDescriptor_throw( _rName ) );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
Any aRet;
Sequence< PropertyValue > aScriptDescriptor( 2 );
aScriptDescriptor[0].Name = ::rtl::OUString::createFromAscii( "EventType" );
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
aScriptDescriptor[0].Value <<= aDescriptor.ScriptType;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
aScriptDescriptor[1].Name = ::rtl::OUString::createFromAscii( "Script" );
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
aScriptDescriptor[1].Value <<= aDescriptor.ScriptCode;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
return makeAny( aScriptDescriptor );
}
//------------------------------------------------------------------------
Sequence< ::rtl::OUString > SAL_CALL EventHolder::getElementNames( ) throw (RuntimeException)
{
Sequence< ::rtl::OUString > aReturn( m_aEventIndexAccess.size() );
::rtl::OUString* pReturn = aReturn.getArray();
// SvxMacroAssignDlg has a weird API: It expects a XNameReplace, means a container whose
// main access method is by name. In it's UI, it shows the possible events in exactly the
// order in which XNameAccess::getElementNames returns them.
// However, SvxMacroAssignDlg *also* takes an index for the initial selection, which is
// relative to the sequence returned by XNameAccess::getElementNames.
// This is IMO weird, since it mixes index access with name access, which decreases efficiency
// of the implementation.
// Well, it means we're forced to return the events in getElementNames in exactly the same as they
// appear in the property browser UI.
for ( EventMapIndexAccess::const_iterator loop = m_aEventIndexAccess.begin();
loop != m_aEventIndexAccess.end();
++loop, ++pReturn
)
*pReturn = loop->second->first;
return aReturn;
}
//------------------------------------------------------------------------
sal_Bool SAL_CALL EventHolder::hasByName( const ::rtl::OUString& _rName ) throw (RuntimeException)
{
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
EventMap::const_iterator pos = m_aEventNameAccess.find( _rName );
return pos != m_aEventNameAccess.end();
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
}
//------------------------------------------------------------------------
Type SAL_CALL EventHolder::getElementType( ) throw (RuntimeException)
{
return ::getCppuType( static_cast< Sequence< PropertyValue >* >( NULL ) );
}
//------------------------------------------------------------------------
sal_Bool SAL_CALL EventHolder::hasElements( ) throw (RuntimeException)
{
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
return !m_aEventNameAccess.empty();
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
}
//====================================================================
//= EventHandler
//====================================================================
DBG_NAME( EventHandler )
//--------------------------------------------------------------------
EventHandler::EventHandler( const Reference< XComponentContext >& _rxContext )
:EventHandler_Base( m_aMutex )
,m_aContext( _rxContext )
INTEGRATION: CWS wae4extensions (1.9.30); FILE MERGED 2008/01/09 20:35:42 ericb 1.9.30.2: #i81612# a try to fix conflicts for resync with m242 2007/09/27 07:18:24 fs 1.9.30.1: #i81612# warning-free code
2008-01-14 13:57:12 +00:00
,m_aPropertyListeners( m_aMutex )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
,m_bEventsMapInitialized( false )
,m_bIsDialogElement( false )
{
DBG_CTOR( EventHandler, NULL );
}
//--------------------------------------------------------------------
EventHandler::~EventHandler()
{
DBG_DTOR( EventHandler, NULL );
}
//--------------------------------------------------------------------
::rtl::OUString SAL_CALL EventHandler::getImplementationName( ) throw (RuntimeException)
{
return getImplementationName_static();
}
//--------------------------------------------------------------------
::sal_Bool SAL_CALL EventHandler::supportsService( const ::rtl::OUString& ServiceName ) throw (RuntimeException)
{
StlSyntaxSequence< ::rtl::OUString > aAllServices( getSupportedServiceNames() );
return ::std::find( aAllServices.begin(), aAllServices.end(), ServiceName ) != aAllServices.end();
}
//--------------------------------------------------------------------
Sequence< ::rtl::OUString > SAL_CALL EventHandler::getSupportedServiceNames( ) throw (RuntimeException)
{
return getSupportedServiceNames_static();
}
//--------------------------------------------------------------------
::rtl::OUString SAL_CALL EventHandler::getImplementationName_static( ) throw (RuntimeException)
{
return ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "com.sun.star.comp.extensions.EventHandler" ) );
}
//--------------------------------------------------------------------
Sequence< ::rtl::OUString > SAL_CALL EventHandler::getSupportedServiceNames_static( ) throw (RuntimeException)
{
Sequence< ::rtl::OUString > aSupported( 1 );
aSupported[0] = ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "com.sun.star.form.inspection.EventHandler" ) );
return aSupported;
}
//--------------------------------------------------------------------
Reference< XInterface > SAL_CALL EventHandler::Create( const Reference< XComponentContext >& _rxContext )
{
return *( new EventHandler( _rxContext ) );
}
//--------------------------------------------------------------------
void SAL_CALL EventHandler::inspect( const Reference< XInterface >& _rxIntrospectee ) throw (RuntimeException, NullPointerException)
{
::osl::MutexGuard aGuard( m_aMutex );
if ( !_rxIntrospectee.is() )
throw NullPointerException();
m_xComponent = Reference< XPropertySet >( _rxIntrospectee, UNO_QUERY_THROW );
m_bEventsMapInitialized = false;
EventMap aEmpty;
m_aEvents.swap( aEmpty );
m_bIsDialogElement = false;
try
{
Reference< XPropertySetInfo > xPSI( m_xComponent->getPropertySetInfo() );
m_bIsDialogElement = xPSI.is()
&& xPSI->hasPropertyByName( PROPERTY_WIDTH )
&& xPSI->hasPropertyByName( PROPERTY_HEIGHT )
&& xPSI->hasPropertyByName( PROPERTY_POSITIONX )
&& xPSI->hasPropertyByName( PROPERTY_POSITIONY );
}
catch( const Exception& )
{
OSL_ENSURE( false, "EventHandler::EventHandler: caught an exception while classifying the component!" );
}
}
//--------------------------------------------------------------------
Any SAL_CALL EventHandler::getPropertyValue( const ::rtl::OUString& _rPropertyName ) throw (UnknownPropertyException, RuntimeException)
{
::osl::MutexGuard aGuard( m_aMutex );
const EventDescription& rEvent = impl_getEventForName_throw( _rPropertyName );
Sequence< ScriptEventDescriptor > aEvents;
impl_getComponentScriptEvents_nothrow( aEvents );
sal_Int32 nEventCount = aEvents.getLength();
const ScriptEventDescriptor* pEvents = aEvents.getConstArray();
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
ScriptEventDescriptor aPropertyValue;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
for ( sal_Int32 event = 0; event < nEventCount; ++event, ++pEvents )
{
if ( rEvent.sListenerClassName == pEvents->ListenerType
&& rEvent.sListenerMethodName == pEvents->EventMethod
)
{
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
aPropertyValue = *pEvents;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
break;
}
}
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
return makeAny( aPropertyValue );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
}
//--------------------------------------------------------------------
void SAL_CALL EventHandler::setPropertyValue( const ::rtl::OUString& _rPropertyName, const Any& _rValue ) throw (UnknownPropertyException, RuntimeException)
{
::osl::MutexGuard aGuard( m_aMutex );
const EventDescription& rEvent = impl_getEventForName_throw( _rPropertyName );
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
ScriptEventDescriptor aNewScriptEvent;
OSL_VERIFY( _rValue >>= aNewScriptEvent );
ScriptEventDescriptor aOldScriptEvent;
OSL_VERIFY( getPropertyValue( _rPropertyName ) >>= aOldScriptEvent );
if ( aOldScriptEvent == aNewScriptEvent )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
return;
if ( m_bIsDialogElement )
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
impl_setDialogElementScriptEvent_nothrow( aNewScriptEvent );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
else
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
impl_setFormComponentScriptEvent_nothrow( aNewScriptEvent );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
Reference< XModifiable > xDoc( m_aContext.getContextValueByAsciiName( "ContextDocument" ), UNO_QUERY );
if ( xDoc.is() )
xDoc->setModified( sal_True );
PropertyChangeEvent aEvent;
aEvent.Source = m_xComponent;
aEvent.PropertyHandle = rEvent.nId;
aEvent.PropertyName = _rPropertyName;
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
aEvent.OldValue <<= aOldScriptEvent;
aEvent.NewValue <<= aNewScriptEvent;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
m_aPropertyListeners.notify( aEvent, &XPropertyChangeListener::propertyChange );
}
//--------------------------------------------------------------------
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
Any SAL_CALL EventHandler::convertToPropertyValue( const ::rtl::OUString& _rPropertyName, const Any& _rControlValue ) throw (UnknownPropertyException, RuntimeException)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
{
::osl::MutexGuard aGuard( m_aMutex );
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
OSL_ENSURE( false, "EventHandler::convertToPropertyValue: why calling this for read-only controls?" );
// since currently, the controls to display the script events are readonly, this method should normally
// not be called.
Sequence< ScriptEventDescriptor > aAllAssignedEvents;
impl_getComponentScriptEvents_nothrow( aAllAssignedEvents );
const EventDescription& rEvent = impl_getEventForName_throw( _rPropertyName );
ScriptEventDescriptor aAssignedScript = lcl_getAssignedScriptEvent( rEvent, aAllAssignedEvents );
#if OSL_DEBUG_LEVEL > 0
::rtl::OUString sControlValue;
OSL_VERIFY( _rControlValue >>= sControlValue );
OSL_ENSURE( sControlValue == aAssignedScript.ScriptCode, "EventHandler::convertToPropertyValue: somebody really managed to enter a new value in the control?" );
#else
(void)_rControlValue;
#endif
return makeAny( aAssignedScript );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
}
//--------------------------------------------------------------------
INTEGRATION: CWS dba204b (1.3.34); FILE MERGED 2006/07/19 07:45:49 fs 1.3.34.2: RESYNC: (1.3-1.4); FILE MERGED 2006/07/06 14:52:27 fs 1.3.34.1: #i65159# describePropertyLine now returning a LineDescriptor, instead of taking an out parameter / some less warnings
2006-07-26 06:55:25 +00:00
Any SAL_CALL EventHandler::convertToControlValue( const ::rtl::OUString& /*_rPropertyName*/, const Any& _rPropertyValue, const Type& _rControlValueType ) throw (UnknownPropertyException, RuntimeException)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
{
::osl::MutexGuard aGuard( m_aMutex );
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
ScriptEventDescriptor aScriptEvent;
OSL_VERIFY( _rPropertyValue >>= aScriptEvent );
OSL_ENSURE( _rControlValueType.getTypeClass() == TypeClass_STRING,
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
"EventHandler::convertToControlValue: unexpected ControlValue type class!" );
INTEGRATION: CWS wae4extensions (1.9.30); FILE MERGED 2008/01/09 20:35:42 ericb 1.9.30.2: #i81612# a try to fix conflicts for resync with m242 2007/09/27 07:18:24 fs 1.9.30.1: #i81612# warning-free code
2008-01-14 13:57:12 +00:00
(void)_rControlValueType;
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
return makeAny( aScriptEvent.ScriptCode );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
}
//--------------------------------------------------------------------
INTEGRATION: CWS dba204b (1.3.34); FILE MERGED 2006/07/19 07:45:49 fs 1.3.34.2: RESYNC: (1.3-1.4); FILE MERGED 2006/07/06 14:52:27 fs 1.3.34.1: #i65159# describePropertyLine now returning a LineDescriptor, instead of taking an out parameter / some less warnings
2006-07-26 06:55:25 +00:00
PropertyState SAL_CALL EventHandler::getPropertyState( const ::rtl::OUString& /*_rPropertyName*/ ) throw (UnknownPropertyException, RuntimeException)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
{
return PropertyState_DIRECT_VALUE;
}
//--------------------------------------------------------------------
void SAL_CALL EventHandler::addPropertyChangeListener( const Reference< XPropertyChangeListener >& _rxListener ) throw (RuntimeException)
{
::osl::MutexGuard aGuard( m_aMutex );
if ( !_rxListener.is() )
throw NullPointerException();
m_aPropertyListeners.addListener( _rxListener );
}
//--------------------------------------------------------------------
void SAL_CALL EventHandler::removePropertyChangeListener( const Reference< XPropertyChangeListener >& _rxListener ) throw (RuntimeException)
{
::osl::MutexGuard aGuard( m_aMutex );
m_aPropertyListeners.removeListener( _rxListener );
}
//--------------------------------------------------------------------
Sequence< Property > SAL_CALL EventHandler::getSupportedProperties() throw (RuntimeException)
{
::osl::MutexGuard aGuard( m_aMutex );
if ( !m_bEventsMapInitialized )
{
const_cast< EventHandler* >( this )->m_bEventsMapInitialized = true;
try
{
Sequence< Type > aListeners;
impl_getCopmonentListenerTypes_nothrow( aListeners );
sal_Int32 listenerCount = aListeners.getLength();
Property aCurrentProperty;
::rtl::OUString sListenerClassName;
// loop through all listeners and all methods, and see which we can present at the UI
const Type* pListeners = aListeners.getConstArray();
for ( sal_Int32 listener = 0; listener < listenerCount; ++listener, ++pListeners )
{
aCurrentProperty = Property();
// the programmatic name of the listener, to be used as "property" name
sListenerClassName = pListeners->getTypeName();
OSL_ENSURE( sListenerClassName.getLength(), "EventHandler::getSupportedProperties: strange - no listener name ..." );
if ( !sListenerClassName.getLength() )
continue;
// loop through all methods
Sequence< ::rtl::OUString > aMethods( lcl_getListenerMethodsForType( *pListeners ) );
const ::rtl::OUString* pMethods = aMethods.getConstArray();
sal_uInt32 methodCount = aMethods.getLength();
for (sal_uInt32 method = 0 ; method < methodCount ; method++,++pMethods )
{
EventDescription aEvent;
if ( !lcl_getEventDescriptionForMethod( *pMethods, aEvent ) )
continue;
const_cast< EventHandler* >( this )->m_aEvents.insert( EventMap::value_type(
lcl_getEventPropertyName( sListenerClassName, *pMethods ), aEvent ) );
}
}
}
catch( const Exception& )
{
CWS-TOOLING: integrate CWS cmcfixes50 2008-11-10 13:31:50 +0100 cmc r263517 : gio doesn't do anything useful for remote stuff wrt info 2008-11-06 00:11:47 +0100 cmc r263359 : #i93436# pile of other 64bit new gcc warnings 2008-11-05 00:39:03 +0100 cmc r263340 : i95856 let a ppc64 vanilla build succeed 2008-11-04 14:00:25 +0100 cmc r263320 : #i93436# useless const 2008-11-04 11:53:10 +0100 cmc r263314 : #i93436# ambiguous 2008-11-04 11:48:05 +0100 cmc r263313 : #i93436# add some braces 2008-11-04 11:29:24 +0100 cmc r263312 : #i93436# ambiguous 2008-11-04 10:53:46 +0100 cmc r263311 :
2008-11-10 15:06:12 +00:00
DBG_ERROR( "EventHandler::getSupportedProperties: caught an exception !" );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
}
}
// sort them by ID - this is the relative ordering in the UI
::std::map< EventId, Property > aOrderedProperties;
for ( EventMap::const_iterator loop = m_aEvents.begin();
loop != m_aEvents.end();
++loop
)
{
aOrderedProperties[ loop->second.nId ] = Property(
loop->first, loop->second.nId,
::getCppuType( static_cast< const ::rtl::OUString* >( NULL ) ),
PropertyAttribute::BOUND );
}
StlSyntaxSequence< Property > aReturn( aOrderedProperties.size() );
::std::transform( aOrderedProperties.begin(), aOrderedProperties.end(), aReturn.begin(),
::std::select2nd< ::std::map< EventId, Property >::value_type >() );
return aReturn;
}
//--------------------------------------------------------------------
Sequence< ::rtl::OUString > SAL_CALL EventHandler::getSupersededProperties( ) throw (RuntimeException)
{
// none
return Sequence< ::rtl::OUString >( );
}
//--------------------------------------------------------------------
Sequence< ::rtl::OUString > SAL_CALL EventHandler::getActuatingProperties( ) throw (RuntimeException)
{
// none
return Sequence< ::rtl::OUString >( );
}
//--------------------------------------------------------------------
INTEGRATION: CWS dba204b (1.3.34); FILE MERGED 2006/07/19 07:45:49 fs 1.3.34.2: RESYNC: (1.3-1.4); FILE MERGED 2006/07/06 14:52:27 fs 1.3.34.1: #i65159# describePropertyLine now returning a LineDescriptor, instead of taking an out parameter / some less warnings
2006-07-26 06:55:25 +00:00
LineDescriptor SAL_CALL EventHandler::describePropertyLine( const ::rtl::OUString& _rPropertyName,
const Reference< XPropertyControlFactory >& _rxControlFactory )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
throw (UnknownPropertyException, NullPointerException, RuntimeException)
{
if ( !_rxControlFactory.is() )
throw NullPointerException();
::osl::MutexGuard aGuard( m_aMutex );
INTEGRATION: CWS dba204b (1.3.34); FILE MERGED 2006/07/19 07:45:49 fs 1.3.34.2: RESYNC: (1.3-1.4); FILE MERGED 2006/07/06 14:52:27 fs 1.3.34.1: #i65159# describePropertyLine now returning a LineDescriptor, instead of taking an out parameter / some less warnings
2006-07-26 06:55:25 +00:00
LineDescriptor aDescriptor;
aDescriptor.Control = _rxControlFactory->createPropertyControl( PropertyControlType::TextField, sal_True );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
const EventDescription& rEvent = impl_getEventForName_throw( _rPropertyName );
INTEGRATION: CWS dba204b (1.3.34); FILE MERGED 2006/07/19 07:45:49 fs 1.3.34.2: RESYNC: (1.3-1.4); FILE MERGED 2006/07/06 14:52:27 fs 1.3.34.1: #i65159# describePropertyLine now returning a LineDescriptor, instead of taking an out parameter / some less warnings
2006-07-26 06:55:25 +00:00
aDescriptor.DisplayName = rEvent.sDisplayName;
aDescriptor.HelpURL = HelpIdUrl::getHelpURL( rEvent.nHelpId );
aDescriptor.PrimaryButtonId = rEvent.nUniqueBrowseId;
aDescriptor.HasPrimaryButton = sal_True;
aDescriptor.Category = ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "Events" ) );
return aDescriptor;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
}
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
//--------------------------------------------------------------------
::sal_Bool SAL_CALL EventHandler::isComposable( const ::rtl::OUString& /*_rPropertyName*/ ) throw (UnknownPropertyException, RuntimeException)
{
return sal_False;
}
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
//--------------------------------------------------------------------
INTEGRATION: CWS dba204b (1.3.34); FILE MERGED 2006/07/19 07:45:49 fs 1.3.34.2: RESYNC: (1.3-1.4); FILE MERGED 2006/07/06 14:52:27 fs 1.3.34.1: #i65159# describePropertyLine now returning a LineDescriptor, instead of taking an out parameter / some less warnings
2006-07-26 06:55:25 +00:00
InteractiveSelectionResult SAL_CALL EventHandler::onInteractivePropertySelection( const ::rtl::OUString& _rPropertyName, sal_Bool /*_bPrimary*/, Any& /*_rData*/, const Reference< XObjectInspectorUI >& _rxInspectorUI ) throw (UnknownPropertyException, NullPointerException, RuntimeException)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
{
if ( !_rxInspectorUI.is() )
throw NullPointerException();
::osl::MutexGuard aGuard( m_aMutex );
const EventDescription& rForEvent = impl_getEventForName_throw( _rPropertyName );
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
Sequence< ScriptEventDescriptor > aAllAssignedEvents;
impl_getComponentScriptEvents_nothrow( aAllAssignedEvents );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
// SvxMacroAssignDlg-compatible structure holding all event/assignments
::rtl::Reference< EventHolder > pEventHolder( new EventHolder );
for ( EventMap::const_iterator event = m_aEvents.begin();
event != m_aEvents.end();
++event
)
{
INTEGRATION: CWS dba203c (1.2.12); FILE MERGED 2006/04/20 07:47:38 fs 1.2.12.3: #i64196# use FormController as secondary component only if it's really a form 2006/04/20 07:17:03 fs 1.2.12.2: proper fix for #ii64511#: XRowSetListener is in sdbc, not sdb 2006/04/19 13:33:11 fs 1.2.12.1: #i64511# proper event name in AddEvent call
2006-05-04 08:01:11 +00:00
// the script which is assigned to the current event (if any)
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
ScriptEventDescriptor aAssignedScript = lcl_getAssignedScriptEvent( event->second, aAllAssignedEvents );
pEventHolder->addEvent( event->second.nId, event->second.sListenerMethodName, aAssignedScript );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
}
// the inital selection in the dialog
Sequence< ::rtl::OUString > aNames( pEventHolder->getElementNames() );
const ::rtl::OUString* pChosenEvent = ::std::find( aNames.getConstArray(), aNames.getConstArray() + aNames.getLength(), rForEvent.sListenerMethodName );
INTEGRATION: CWS dba204b (1.3.34); FILE MERGED 2006/07/19 07:45:49 fs 1.3.34.2: RESYNC: (1.3-1.4); FILE MERGED 2006/07/06 14:52:27 fs 1.3.34.1: #i65159# describePropertyLine now returning a LineDescriptor, instead of taking an out parameter / some less warnings
2006-07-26 06:55:25 +00:00
sal_uInt16 nInitialSelection = (sal_uInt16)( pChosenEvent - aNames.getConstArray() );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
// the dialog
SvxAbstractDialogFactory* pFactory = SvxAbstractDialogFactory::Create();
if ( !pFactory )
return InteractiveSelectionResult_Cancelled;
INTEGRATION: CWS odbmacros2 (1.10.8); FILE MERGED 2008/02/04 13:09:22 fs 1.10.8.2: RESYNC: (1.10-1.11); FILE MERGED 2007/12/12 14:36:04 fs 1.10.8.1: #i49133# when invoking the macro assignment dialog, pass it the frame of our context document
2008-03-06 17:42:26 +00:00
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
::std::auto_ptr< VclAbstractDialog > pDialog( pFactory->CreateSvxMacroAssignDlg(
INTEGRATION: CWS odbmacros2 (1.10.8); FILE MERGED 2008/02/04 13:09:22 fs 1.10.8.2: RESYNC: (1.10-1.11); FILE MERGED 2007/12/12 14:36:04 fs 1.10.8.1: #i49133# when invoking the macro assignment dialog, pass it the frame of our context document
2008-03-06 17:42:26 +00:00
PropertyHandlerHelper::getDialogParentWindow( m_aContext ),
impl_getContextFrame_nothrow(),
m_bIsDialogElement,
pEventHolder.get(),
nInitialSelection
) );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
if ( !pDialog.get() )
return InteractiveSelectionResult_Cancelled;
// DF definite problem here
// OK & Cancel seem to be both returning 0
if ( pDialog->Execute() != 0 )
return InteractiveSelectionResult_Cancelled;
try
{
for ( EventMap::const_iterator event = m_aEvents.begin();
event != m_aEvents.end();
++event
)
{
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
ScriptEventDescriptor aScriptDescriptor( pEventHolder->getNormalizedDescriptorByName( event->second.sListenerMethodName ) );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
// set the new "property value"
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
setPropertyValue(
lcl_getEventPropertyName( event->second.sListenerClassName, event->second.sListenerMethodName ),
makeAny( aScriptDescriptor )
);
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
}
}
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
catch( const Exception& )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
{
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
DBG_UNHANDLED_EXCEPTION();
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
}
return InteractiveSelectionResult_Success;
}
//--------------------------------------------------------------------
INTEGRATION: CWS dba204b (1.3.34); FILE MERGED 2006/07/19 07:45:49 fs 1.3.34.2: RESYNC: (1.3-1.4); FILE MERGED 2006/07/06 14:52:27 fs 1.3.34.1: #i65159# describePropertyLine now returning a LineDescriptor, instead of taking an out parameter / some less warnings
2006-07-26 06:55:25 +00:00
void SAL_CALL EventHandler::actuatingPropertyChanged( const ::rtl::OUString& /*_rActuatingPropertyName*/, const Any& /*_rNewValue*/, const Any& /*_rOldValue*/, const Reference< XObjectInspectorUI >& /*_rxInspectorUI*/, sal_Bool /*_bFirstTimeInit*/ ) throw (NullPointerException, RuntimeException)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
{
DBG_ERROR( "EventHandler::actuatingPropertyChanged: no actuating properties -> no callback (well, this is how it *should* be!)" );
}
//--------------------------------------------------------------------
IMPLEMENT_FORWARD_XCOMPONENT( EventHandler, EventHandler_Base )
//--------------------------------------------------------------------
void SAL_CALL EventHandler::disposing()
{
EventMap aEmpty;
m_aEvents.swap( aEmpty );
m_xComponent.clear();
}
//--------------------------------------------------------------------
INTEGRATION: CWS dba204b (1.3.34); FILE MERGED 2006/07/19 07:45:49 fs 1.3.34.2: RESYNC: (1.3-1.4); FILE MERGED 2006/07/06 14:52:27 fs 1.3.34.1: #i65159# describePropertyLine now returning a LineDescriptor, instead of taking an out parameter / some less warnings
2006-07-26 06:55:25 +00:00
sal_Bool SAL_CALL EventHandler::suspend( sal_Bool /*_bSuspend*/ ) throw (RuntimeException)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
{
return sal_True;
}
INTEGRATION: CWS odbmacros2 (1.10.8); FILE MERGED 2008/02/04 13:09:22 fs 1.10.8.2: RESYNC: (1.10-1.11); FILE MERGED 2007/12/12 14:36:04 fs 1.10.8.1: #i49133# when invoking the macro assignment dialog, pass it the frame of our context document
2008-03-06 17:42:26 +00:00
//------------------------------------------------------------------------
Reference< XFrame > EventHandler::impl_getContextFrame_nothrow() const
{
Reference< XFrame > xContextFrame;
try
{
Reference< XModel > xContextDocument( m_aContext.getContextValueByAsciiName( "ContextDocument" ), UNO_QUERY_THROW );
Reference< XController > xController( xContextDocument->getCurrentController(), UNO_SET_THROW );
xContextFrame.set( xController->getFrame(), UNO_SET_THROW );
}
catch( const Exception& )
{
DBG_UNHANDLED_EXCEPTION();
}
return xContextFrame;
}
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
//--------------------------------------------------------------------
sal_Int32 EventHandler::impl_getComponentIndexInParent_throw() const
{
Reference< XChild > xChild( m_xComponent, UNO_QUERY_THROW );
Reference< XIndexAccess > xParentAsIndexAccess( xChild->getParent(), UNO_QUERY_THROW );
// get the index of the inspected object within it's parent container
sal_Int32 nElements = xParentAsIndexAccess->getCount();
for ( sal_Int32 i=0; i<nElements; ++i )
{
Reference< XInterface > xElement( xParentAsIndexAccess->getByIndex( i ), UNO_QUERY_THROW );
if ( xElement == m_xComponent )
return i;
}
throw NoSuchElementException();
}
//--------------------------------------------------------------------
void EventHandler::impl_getFormComponentScriptEvents_nothrow( Sequence < ScriptEventDescriptor >& _out_rEvents ) const
{
_out_rEvents = Sequence < ScriptEventDescriptor >();
try
{
Reference< XChild > xChild( m_xComponent, UNO_QUERY_THROW );
Reference< XEventAttacherManager > xEventManager( xChild->getParent(), UNO_QUERY_THROW );
_out_rEvents = xEventManager->getScriptEvents( impl_getComponentIndexInParent_throw() );
// the form component script API has unqualified listener names, but for normalization
// purpose, we want fully qualified ones
ScriptEventDescriptor* pEvents = _out_rEvents.getArray();
ScriptEventDescriptor* pEventsEnd = _out_rEvents.getArray() + _out_rEvents.getLength();
while ( pEvents != pEventsEnd )
{
pEvents->ListenerType = lcl_getQualifiedKnownListenerName( *pEvents );
++pEvents;
}
}
catch( const Exception& )
{
OSL_ENSURE( false, "EventHandler::impl_getFormComponentScriptEvents_nothrow: caught an exception!" );
}
}
//--------------------------------------------------------------------
void EventHandler::impl_getCopmonentListenerTypes_nothrow( Sequence< Type >& _out_rTypes ) const
{
_out_rTypes.realloc( 0 );
try
{
// we use a set to avoid duplicates
TypeBag aListeners;
Reference< XIntrospection > xIntrospection( m_aContext.createComponent( "com.sun.star.beans.Introspection" ), UNO_QUERY_THROW );
// --- model listeners
lcl_addListenerTypesFor_throw(
m_xComponent, xIntrospection, aListeners );
INTEGRATION: CWS dba203c (1.2.12); FILE MERGED 2006/04/20 07:47:38 fs 1.2.12.3: #i64196# use FormController as secondary component only if it's really a form 2006/04/20 07:17:03 fs 1.2.12.2: proper fix for #ii64511#: XRowSetListener is in sdbc, not sdb 2006/04/19 13:33:11 fs 1.2.12.1: #i64511# proper event name in AddEvent call
2006-05-04 08:01:11 +00:00
// --- "secondary component" (usually: "control" listeners)
{
Reference< XInterface > xSecondaryComponent( impl_getSecondaryComponentForEventInspection_throw() );
lcl_addListenerTypesFor_throw( xSecondaryComponent, xIntrospection, aListeners );
::comphelper::disposeComponent( xSecondaryComponent );
}
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
// now that they're disambiguated, copy these types into our member
_out_rTypes.realloc( aListeners.size() );
::std::copy( aListeners.begin(), aListeners.end(), _out_rTypes.getArray() );
}
catch( const Exception& )
{
OSL_ENSURE( false, "EventHandler::impl_getCopmonentListenerTypes_nothrow: caught an exception!" );
}
}
//--------------------------------------------------------------------
void EventHandler::impl_getDialogElementScriptEvents_nothrow( Sequence < ScriptEventDescriptor >& _out_rEvents ) const
{
_out_rEvents = Sequence < ScriptEventDescriptor >();
try
{
Reference< XScriptEventsSupplier > xEventsSupplier( m_xComponent, UNO_QUERY_THROW );
Reference< XNameContainer > xEvents( xEventsSupplier->getEvents(), UNO_QUERY_THROW );
Sequence< ::rtl::OUString > aEventNames( xEvents->getElementNames() );
sal_Int32 nEventCount = aEventNames.getLength();
_out_rEvents.realloc( nEventCount );
const ::rtl::OUString* pNames = aEventNames.getConstArray();
ScriptEventDescriptor* pDescs = _out_rEvents.getArray();
for( sal_Int32 i = 0 ; i < nEventCount ; ++i, ++pNames, ++pDescs )
OSL_VERIFY( xEvents->getByName( *pNames ) >>= *pDescs );
}
catch( const Exception& )
{
OSL_ENSURE( false, "EventHandler::impl_getDialogElementScriptEvents_nothrow: caught an exception!" );
}
}
//--------------------------------------------------------------------
Reference< XInterface > EventHandler::impl_getSecondaryComponentForEventInspection_throw( ) const
{
Reference< XInterface > xReturn;
// if it's a form, create a form controller for the additional events
INTEGRATION: CWS dba203c (1.2.12); FILE MERGED 2006/04/20 07:47:38 fs 1.2.12.3: #i64196# use FormController as secondary component only if it's really a form 2006/04/20 07:17:03 fs 1.2.12.2: proper fix for #ii64511#: XRowSetListener is in sdbc, not sdb 2006/04/19 13:33:11 fs 1.2.12.1: #i64511# proper event name in AddEvent call
2006-05-04 08:01:11 +00:00
Reference< XForm > xComponentAsForm( m_xComponent, UNO_QUERY );
if ( xComponentAsForm.is() )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
{
INTEGRATION: CWS dba203c (1.2.12); FILE MERGED 2006/04/20 07:47:38 fs 1.2.12.3: #i64196# use FormController as secondary component only if it's really a form 2006/04/20 07:17:03 fs 1.2.12.2: proper fix for #ii64511#: XRowSetListener is in sdbc, not sdb 2006/04/19 13:33:11 fs 1.2.12.1: #i64511# proper event name in AddEvent call
2006-05-04 08:01:11 +00:00
Reference< XTabControllerModel > xComponentAsTCModel( m_xComponent, UNO_QUERY_THROW );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
Reference< XFormController > xController(
m_aContext.createComponent( (const rtl::OUString&)SERVICE_FORMCONTROLLER ), UNO_QUERY_THROW );
xController->setModel( xComponentAsTCModel );
xReturn = xController.get();
}
else
{
::rtl::OUString sControlService;
OSL_VERIFY( m_xComponent->getPropertyValue( PROPERTY_DEFAULTCONTROL ) >>= sControlService );
xReturn = m_aContext.createComponent( sControlService );
}
return xReturn;
}
//--------------------------------------------------------------------
const EventDescription& EventHandler::impl_getEventForName_throw( const ::rtl::OUString& _rPropertyName ) const
{
EventMap::const_iterator pos = m_aEvents.find( _rPropertyName );
if ( pos == m_aEvents.end() )
throw UnknownPropertyException();
return pos->second;
}
INTEGRATION: CWS dba205c (1.7.12); FILE MERGED 2006/10/09 10:40:34 fs 1.7.12.1: #i70139# impl_setFormComponentScriptEvent_nothrow: proper comparison for exsiting event
2006-10-24 14:17:34 +00:00
//--------------------------------------------------------------------
namespace
{
static bool lcl_endsWith( const ::rtl::OUString& _rText, const ::rtl::OUString& _rCheck )
{
sal_Int32 nTextLen = _rText.getLength();
sal_Int32 nCheckLen = _rCheck.getLength();
if ( nCheckLen > nTextLen )
return false;
return _rText.indexOf( _rCheck ) == ( nTextLen - nCheckLen );
}
}
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
//--------------------------------------------------------------------
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
void EventHandler::impl_setFormComponentScriptEvent_nothrow( const ScriptEventDescriptor& _rScriptEvent )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
{
try
{
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
::rtl::OUString sScriptCode( _rScriptEvent.ScriptCode );
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
::rtl::OUString sScriptType( _rScriptEvent.ScriptType );
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
bool bResetScript = ( sScriptCode.getLength() == 0 );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
sal_Int32 nObjectIndex = impl_getComponentIndexInParent_throw();
Reference< XChild > xChild( m_xComponent, UNO_QUERY_THROW );
Reference< XEventAttacherManager > xEventManager( xChild->getParent(), UNO_QUERY_THROW );
Sequence< ScriptEventDescriptor > aEvents( xEventManager->getScriptEvents( nObjectIndex ) );
// is there already a registered script for this event?
ScriptEventDescriptor* pEvent = aEvents.getArray();
sal_Int32 eventCount = aEvents.getLength(), event = 0;
for ( event = 0; event < eventCount; ++event, ++pEvent )
{
INTEGRATION: CWS dba205c (1.7.12); FILE MERGED 2006/10/09 10:40:34 fs 1.7.12.1: #i70139# impl_setFormComponentScriptEvent_nothrow: proper comparison for exsiting event
2006-10-24 14:17:34 +00:00
if ( ( pEvent->EventMethod == _rScriptEvent.EventMethod )
&& ( lcl_endsWith( _rScriptEvent.ListenerType, pEvent->ListenerType ) )
// (strange enough, the events we get from getScriptEvents are not fully qualified)
)
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
{
// yes
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
if ( !bResetScript )
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
{
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
// set to something non-empty -> overwrite
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
pEvent->ScriptCode = sScriptCode;
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
pEvent->ScriptType = sScriptType;
}
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
else
{
// set to empty -> remove from sequence
::std::copy( pEvent + 1, aEvents.getArray() + eventCount, pEvent );
aEvents.realloc( eventCount - 1 );
--eventCount;
}
break;
}
}
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
if ( ( event >= eventCount ) && !bResetScript )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
{
// no, did not find it -> append
aEvents.realloc( eventCount + 1 );
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
aEvents[ eventCount ] = _rScriptEvent;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
}
xEventManager->revokeScriptEvents( nObjectIndex );
xEventManager->registerScriptEvents( nObjectIndex, aEvents );
PropertyHandlerHelper::setContextDocumentModified( m_aContext );
}
catch( const Exception& )
{
OSL_ENSURE( false, "EventHandler::impl_setFormComponentScriptEvent_nothrow: caught an exception!" );
}
}
//--------------------------------------------------------------------
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
void EventHandler::impl_setDialogElementScriptEvent_nothrow( const ScriptEventDescriptor& _rScriptEvent )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
{
try
{
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
::rtl::OUString sScriptCode( _rScriptEvent.ScriptCode );
bool bResetScript = ( sScriptCode.getLength() == 0 );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
Reference< XScriptEventsSupplier > xEventsSupplier( m_xComponent, UNO_QUERY_THROW );
Reference< XNameContainer > xEvents( xEventsSupplier->getEvents(), UNO_QUERY_THROW );
::rtl::OUStringBuffer aCompleteName;
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
aCompleteName.append( _rScriptEvent.ListenerType );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
aCompleteName.appendAscii( "::" );
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
aCompleteName.append( _rScriptEvent.EventMethod );
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
::rtl::OUString sCompleteName( aCompleteName.makeStringAndClear() );
bool bExists = xEvents->hasByName( sCompleteName );
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
if ( bResetScript )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
{
if ( bExists )
xEvents->removeByName( sCompleteName );
}
else
{
INTEGRATION: CWS dba204c (1.4.12); FILE MERGED 2006/07/27 13:54:54 fs 1.4.12.3: #i10000# 2006/07/27 11:23:01 fs 1.4.12.2: RESYNC: (1.4-1.5); FILE MERGED 2006/07/26 08:50:15 fs 1.4.12.1: #i67595# internally hold ScriptEventDescriptors as property values (instead of the previous ScriptCode only), to not lose additional information from the descriptor, such as the ScriptType
2006-08-04 12:59:16 +00:00
Any aNewValue; aNewValue <<= _rScriptEvent;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
if ( bExists )
xEvents->replaceByName( sCompleteName, aNewValue );
else
xEvents->insertByName( sCompleteName, aNewValue );
}
}
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
catch( const Exception& )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
{
INTEGRATION: CWS dba24c (1.9.20); FILE MERGED 2007/10/23 12:55:20 fs 1.9.20.1: #i81826# lcl_getAssignedScriptEvent: properly handle old-style macro specifications
2007-11-21 15:21:37 +00:00
DBG_UNHANDLED_EXCEPTION();
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED 2005/11/02 11:43:40 fs 1.1.2.15: #i10000# exception specifications 2005/10/31 11:13:06 fs 1.1.2.14: teach the ComposedPropertyUIUpdate to handle missing properties 2005/10/25 07:13:09 fs 1.1.2.13: #i53095# knitting lose ends (amongst others, make the handlers available as service) 2005/10/24 08:41:45 fs 1.1.2.12: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/17 14:09:16 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs 2005/10/17 13:18:59 fs 1.1.2.10: #i53095# proper listener administration: allow multiple listeners per handler 2005/10/17 08:58:16 fs 1.1.2.9: some mutex locking 2005/10/14 12:43:45 fs 1.1.2.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 09:37:21 fs 1.1.2.7: #i53095# let the ObjectInspectorModel provide relative property ordering 2005/10/14 08:40:35 fs 1.1.2.6: typo in interface name 2005/10/13 13:01:02 fs 1.1.2.5: #i53095# introduce an XObjectInspector/Model 2005/10/11 13:29:09 fs 1.1.2.4: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/07 12:25:15 fs 1.1.2.3: #i53095# also set the HasFooButton properties at the descriptor 2005/09/05 07:41:48 fs 1.1.2.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/18 12:44:28 fs 1.1.2.1: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends)
2006-03-14 10:22:12 +00:00
}
}
//........................................................................
} // namespace pcr
//........................................................................
Reference in New Issue Copy Permalink