INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/11/02 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
/*************************************************************************
|
|
|
|
|
*
|
2008-04-11 09:47:51 +00:00
|
|
|
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/11/02 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
*
|
2010-02-12 15:01:35 +01:00
|
|
|
* Copyright 2000, 2010 Oracle and/or its affiliates.
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/11/02 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
*
|
2008-04-11 09:47:51 +00:00
|
|
|
* OpenOffice.org - a multi-platform office productivity suite
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/11/02 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
*
|
2008-04-11 09:47:51 +00:00
|
|
|
* This file is part of OpenOffice.org.
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/11/02 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
*
|
2008-04-11 09:47:51 +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 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
*
|
2008-04-11 09:47:51 +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 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
*
|
2008-04-11 09:47:51 +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 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
*
|
|
|
|
|
************************************************************************/
|
|
|
|
|
|
|
|
|
|
#ifndef EXTENSIONS_SOURCE_PROPCTRLR_EVENTHANDLER_HXX
|
|
|
|
|
#define EXTENSIONS_SOURCE_PROPCTRLR_EVENTHANDLER_HXX
|
|
|
|
|
|
|
|
|
|
#include "pcrcomponentcontext.hxx"
|
|
|
|
|
#include "pcrcommontypes.hxx"
|
|
|
|
|
#include "pcrcommon.hxx"
|
|
|
|
|
|
|
|
|
|
/** === begin UNO includes === **/
|
|
|
|
|
#include <com/sun/star/script/ScriptEventDescriptor.hpp>
|
|
|
|
|
#include <com/sun/star/lang/XServiceInfo.hpp>
|
2008-03-06 17:42:41 +00:00
|
|
|
#include <com/sun/star/inspection/XPropertyHandler.hpp>
|
|
|
|
|
#include <com/sun/star/beans/XPropertySet.hpp>
|
|
|
|
|
#include <com/sun/star/frame/XFrame.hpp>
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/11/02 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
/** === end UNO includes === **/
|
|
|
|
|
#include <cppuhelper/compbase2.hxx>
|
|
|
|
|
#include <comphelper/listenernotification.hxx>
|
|
|
|
|
|
|
|
|
|
//........................................................................
|
|
|
|
|
namespace pcr
|
|
|
|
|
{
|
|
|
|
|
//........................................................................
|
|
|
|
|
|
|
|
|
|
//====================================================================
|
|
|
|
|
//= EventDescription
|
|
|
|
|
//====================================================================
|
|
|
|
|
typedef sal_Int32 EventId;
|
|
|
|
|
struct EventDescription
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
::rtl::OUString sDisplayName;
|
|
|
|
|
::rtl::OUString sListenerClassName;
|
|
|
|
|
::rtl::OUString sListenerMethodName;
|
|
|
|
|
sal_Int32 nHelpId;
|
|
|
|
|
sal_Int32 nUniqueBrowseId;
|
|
|
|
|
EventId nId;
|
|
|
|
|
|
|
|
|
|
EventDescription()
|
2008-01-14 13:57:25 +00:00
|
|
|
:nHelpId( 0 )
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/11/02 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
,nUniqueBrowseId( 0 )
|
2008-01-14 13:57:25 +00:00
|
|
|
,nId( 0 )
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/11/02 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
EventDescription(
|
|
|
|
|
EventId _nId,
|
|
|
|
|
const sal_Char* _pListenerNamespaceAscii,
|
|
|
|
|
const sal_Char* _pListenerClassAsciiName,
|
|
|
|
|
const sal_Char* _pListenerMethodAsciiName,
|
|
|
|
|
sal_uInt16 _nDisplayNameResId,
|
|
|
|
|
sal_Int32 _nHelpId,
|
|
|
|
|
sal_Int32 _nUniqueBrowseId );
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
typedef ::std::hash_map< ::rtl::OUString, EventDescription, ::rtl::OUStringHash > EventMap;
|
|
|
|
|
|
|
|
|
|
//====================================================================
|
|
|
|
|
//= EventHandler
|
|
|
|
|
//====================================================================
|
|
|
|
|
typedef ::cppu::WeakComponentImplHelper2 < ::com::sun::star::inspection::XPropertyHandler
|
|
|
|
|
, ::com::sun::star::lang::XServiceInfo
|
|
|
|
|
> EventHandler_Base;
|
|
|
|
|
class EventHandler : public EventHandler_Base
|
|
|
|
|
{
|
|
|
|
|
private:
|
|
|
|
|
mutable ::osl::Mutex m_aMutex;
|
|
|
|
|
|
|
|
|
|
/// the context in which the instance was created
|
|
|
|
|
ComponentContext m_aContext;
|
|
|
|
|
/// the properties of the object we're handling
|
|
|
|
|
::com::sun::star::uno::Reference< ::com::sun::star::beans::XPropertySet > m_xComponent;
|
|
|
|
|
/// our XPropertyChangeListener(s)
|
|
|
|
|
PropertyChangeListeners m_aPropertyListeners;
|
|
|
|
|
/// cache of the events we found at our introspectee
|
|
|
|
|
EventMap m_aEvents;
|
|
|
|
|
/// has m_aEvents been initialized?
|
|
|
|
|
bool m_bEventsMapInitialized;
|
|
|
|
|
/// is our introspectee a dialog element?
|
|
|
|
|
bool m_bIsDialogElement;
|
|
|
|
|
// TODO: move different handling into different derived classes?
|
CWS-TOOLING: integrate CWS dba32g
2009-09-09 07:53:55 +0200 oj r275964 : replace strlen with rtl_str_getLength
2009-09-07 20:59:10 +0200 fs r275913 : disable the CopyTableWizard test until issue 104869 is fixed
2009-09-07 12:17:31 +0200 oj r275885 : #i104810# remove de as lang
2009-09-05 22:26:21 +0200 fs r275857 : protect StateChanged against re-entrance
2009-09-05 22:25:52 +0200 fs r275856 : don't attempt to classify the parent of a form as control
2009-09-05 22:25:29 +0200 fs r275855 : protect against re-entrance
2009-09-05 00:11:40 +0200 fs r275835 : #i10000#
2009-09-04 23:25:50 +0200 fs r275834 : #i10000#
2009-09-04 23:23:47 +0200 fs r275833 : #i10000#
2009-09-04 21:49:37 +0200 fs r275830 : #i10000# correct wrong conflict resolution
2009-09-04 20:59:51 +0200 fs r275829 : CWS-TOOLING: rebase CWS dba32g to trunk@275801 (milestone: DEV300:m57)
2009-09-04 11:08:32 +0200 oj r275791 : #i104780# new version 1.2.0
2009-09-03 22:29:21 +0200 fs r275775 : OSL_TRACE doesn't need \n anymore
2009-09-03 08:33:21 +0200 fs r275743 : CWS-TOOLING: rebase CWS dba32g to trunk@275331 (milestone: DEV300:m56)
2009-09-02 13:48:12 +0200 fs r275708 : removed useless include
2009-09-02 13:45:43 +0200 fs r275707 : more since tags, which are used across offapi/udkapi
2009-09-02 13:23:04 +0200 fs r275705 : should *not* have the dtor, copy ctor, and assignment operator compiler-generated, else we run into trouble as soon as the compiler creates different versions of our singleton member's static data in different libraries
2009-09-02 12:32:45 +0200 fs r275704 : AutoIncrementIsPrimaryKey is a driver setting, not a data source setting
2009-09-02 11:42:49 +0200 fs r275701 : URL meta data are meta data which are valid for all connections of this type, not per-data-source properties. Settings them as data source properties is a hack.
2009-09-02 08:43:34 +0200 fs r275696 : 3.x.x is not a valid 'since' tag
2009-09-01 16:05:24 +0200 fs r275665 : #i104686# don't treat controls bound to read-only columns as required
2009-09-01 13:10:22 +0200 fs r275657 : #i104574# use PageUp/Down to scroll through the complete page
2009-09-01 07:04:48 +0200 oj r275641 : #i104104# correct line ends
2009-08-31 15:52:34 +0200 fs r275612 : #i104410#
2009-08-31 12:29:05 +0200 fs r275596 : #i104364#
2009-08-31 12:28:56 +0200 fs r275595 : #i104364#
2009-08-31 11:43:09 +0200 fs r275593 : #i104649# JavaDriverClassPath is also a known JDBC-bridge setting
2009-08-31 11:41:37 +0200 fs r275592 : #i104649#
2009-08-28 21:48:27 +0200 fs r275552 : during #i96862#: renamed the configuration data which controls availability of certain DBA-related UI
2009-08-28 21:48:17 +0200 fs r275551 : #i96862# do not show the 'Create a new database' option when a) no embedded/dBase driver is installed or b) the configuration requests to hide the option
2009-08-28 21:47:19 +0200 fs r275550 : during #i96862#: renamed the configuration data which controls availability of certain DBA-related UI
2009-08-28 21:46:41 +0200 fs r275549 : #i96862# renamed and extended the configuration data which controls availability of certain DBA-related UI
2009-08-28 15:10:19 +0200 fs r275535 : #i96862# if no embedded driver is installed, use dBase for creating new DBs. If no dBase driver is installed, too, do not offer the 'Create new database' option
2009-08-28 14:03:04 +0200 fs r275532 : #i104454# allow multiple fields to display the same column
2009-08-28 13:14:00 +0200 fs r275528 : #i104584# driver meta data do not belong into a data source's settings
2009-08-28 13:09:57 +0200 fs r275527 : properly chech the MySQL type buttons (else next/back in the wizard leads to state with two buttons checked)
2009-08-28 13:09:17 +0200 fs r275526 : #i104584# driver meta data do not belong into a data source's settings
2009-08-28 13:07:18 +0200 fs r275525 : BooleanComparisonMode is a property, or a feature - but not a driver meta data
2009-08-28 11:00:31 +0200 fs r275521 : #i104580#
2009-08-28 10:40:05 +0200 fs r275519 : #i104577# correct assertion: If the template node type is ANY, then any value type is allowed
2009-08-28 10:09:30 +0200 fs r275518 : #i104575# implement Named Pipe UI
2009-08-28 10:09:07 +0200 fs r275517 : pass the trigger-event to IWindowOperator::operateOn / work with VclWindowEvents, not VclSimpleEvents
2009-08-27 14:27:36 +0200 fs r275484 : ImplPosTabPage: respect mbEmptyViewMargin for WINDOWALIGN_LEFT
2009-08-27 13:43:56 +0200 fs r275480 : merging latest changes from CWS dba32f herein
2009-08-27 13:23:07 +0200 fs r275475 : #i103882#
2009-08-27 11:56:55 +0200 fs r275466 : #i104544# SetState: Do not call Update at the window which we just set text for. It should (sic\!) not be needed, but causes trouble
2009-08-27 11:55:34 +0200 fs r275465 : #i104544#
do not allow re-entrance for impl_ensureControl_nothrow
Actually, this is part of the fix only. I also removed the code which triggered this re-entrance (from
the grid control implementation), but to ensure it won't happen, again, I added some safety herein.
2009-08-27 10:14:11 +0200 fs r275459 : preparations for supporting a 'NamedPipe' parameter for the MySQL Connector/OOo
2009-08-27 10:13:21 +0200 fs r275458 : preparations for supporting a 'NamedPipe' setting for the MySQL Connector/OOo
2009-08-27 10:11:14 +0200 fs r275456 : outsourced the MySQLNative settings into a dedicated class, to not duplicate all the code in two tab page implementations
2009-08-26 14:18:13 +0200 fs r275422 : #i10000#
2009-08-26 13:26:36 +0200 fs r275419 : ignore output paths
2009-08-26 13:23:38 +0200 fs r275417 : support the LocalSocket property for the MySQL native driver
2009-08-26 13:17:05 +0200 fs r275416 : some re-factoring, to outsource the tab page for setting up the MySQLNative connection, into a dedicated class (needed later)
2009-08-26 13:15:15 +0200 fs r275415 : support a NoThousandSep property for NumericFormatters - I'm tired of correcting this at runtime, instead of controlling it in the resource
2009-08-26 11:45:08 +0200 fs r275410 : oops, 'flat' shouldn't have got lost
2009-08-26 09:38:57 +0200 fs r275398 : #i102631# when saving the document fails, ensure that the interaction handler really can handle/display the error
2009-08-26 09:37:05 +0200 fs r275397 : #i102631# don't let non-IO/RuntimeExceptions escape from DatabaseDocument::store*, wrap them into an IOException
2009-08-26 09:35:39 +0200 fs r275395 : let the default interaction handler implement XInteractionHandler2
2009-08-25 13:51:34 +0200 fs r275352 : #i102631# createTempFile: pass URL through FileHelper.getOOoCompatibleFileURL
2009-08-25 13:49:23 +0200 fs r275351 : #i102631# createTempFileURL: immediately delete the file implicitly created by createTempFile, we really only need the URL
2009-08-24 14:49:07 +0200 fs r275318 : #i10000#
2009-08-24 14:36:03 +0200 fs r275315 : properly terminate message with 0 character
2009-08-24 14:35:45 +0200 fs r275314 : trace method concepts in non-pro, if special flag is enabled
2009-08-24 14:24:17 +0200 fs r275312 : #i98973# filter some more events for grid control columns
2009-08-24 14:15:23 +0200 fs r275311 : #i98973# implement XComboBox for combo box cells
2009-08-24 13:39:24 +0200 fs r275308 : #i98973# do not display the 'actionPerformed' event for grid combo box columns
2009-08-24 12:52:03 +0200 fs r275303 : #i98973# implement XCheckBox and XButton for check box cells
2009-08-24 11:56:05 +0200 oj r275300 : #i104447# wrong default for orientation
2009-08-24 10:51:21 +0200 fs r275296 : in the script selector dialog, interpret a double click onto a function as OK
2009-08-24 10:50:56 +0200 fs r275295 : localize some to-be-displayed names, consolidate some code regarding form/control naming
2009-08-21 14:28:05 +0200 fs r275255 : #i98973# implement KeyListeners
2009-08-21 14:27:20 +0200 fs r275254 : #i98973# move the conversion VCL[Mouse|Key]Event->Awt[Mouse|Key]Event from vclxwindow.cxx to VCLUnoHelper
2009-08-21 14:08:50 +0200 fs r275248 : #i98973# implement Mouse- and MouseMotion-broadcasting
2009-08-21 13:31:08 +0200 fs r275244 : #i98973# implement text and change listeners at text cells
2009-08-21 12:47:38 +0200 fs r275234 : #i104399# some refactoring:
If the MySQL Connector/OOo is installed, it registers for the sdbc:mysqlc: protocol (now known as DST_MYSQL_NATIVE_DIRECT).
However, we do not want to display this in the UI, instead we display "MySQL" only, which collects DST_MYSQL_ODBC, DST_MYSQL_JDBC, and DST_MYSQL_NATIVE.
2009-08-21 12:45:18 +0200 fs r275232 : #i104399# also register for the sdbc:mysql:mysqlc protocol, decide at runtime (depending on the availability of sdbc:mysqlc:), whether it is really accepted. This prevents that the C/OOo extension needs to register *our* implementation name for the sdbc:mysql:mysqlc: protocol, which would be somewhat weird
2009-08-20 16:18:48 +0200 fs r275190 : merging the latest changes from CWS dba32f (which this CWS was created from)
2009-08-19 20:19:59 +0200 fs r275160 : add some spacing between the radios
2009-08-19 14:50:15 +0200 fs r275150 : #i98973# slightly refactoring the grid cell implementations, to prepare for proper events being fired. Implement focus events for the moment, more to come.
2009-08-19 10:53:38 +0200 fs r275142 : #i99936# initialize newly created models
2009-08-18 23:03:48 +0200 fs r275132 : merging latest changes from CWS dba32f
2009-08-18 15:14:08 +0200 fs r275110 : #i102819# SetColumnPos: SCROLL_CLIP is deadly here
2009-09-14 11:18:01 +00:00
|
|
|
/// (FormComponent) type of the grid column being inspected, or -1 if we're not inspecting a grid column
|
|
|
|
|
sal_Int16 m_nGridColumnType;
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/11/02 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
// XServiceInfo - static versions
|
|
|
|
|
static ::rtl::OUString SAL_CALL getImplementationName_static( ) throw (::com::sun::star::uno::RuntimeException);
|
|
|
|
|
static ::com::sun::star::uno::Sequence< ::rtl::OUString > SAL_CALL getSupportedServiceNames_static( ) throw (::com::sun::star::uno::RuntimeException);
|
|
|
|
|
static ::com::sun::star::uno::Reference< ::com::sun::star::uno::XInterface > Create( const ::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext >& _rxContext );
|
|
|
|
|
|
|
|
|
|
protected:
|
|
|
|
|
EventHandler(
|
|
|
|
|
const ::com::sun::star::uno::Reference< ::com::sun::star::uno::XComponentContext >& _rxContext
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
~EventHandler();
|
|
|
|
|
|
|
|
|
|
protected:
|
|
|
|
|
// XPropertyHandler overridables
|
|
|
|
|
virtual void SAL_CALL inspect( const ::com::sun::star::uno::Reference< ::com::sun::star::uno::XInterface >& _rxIntrospectee ) throw (::com::sun::star::lang::NullPointerException, ::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual ::com::sun::star::uno::Any SAL_CALL getPropertyValue( const ::rtl::OUString& _rPropertyName ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual void SAL_CALL setPropertyValue( const ::rtl::OUString& _rPropertyName, const ::com::sun::star::uno::Any& _rValue ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual ::com::sun::star::uno::Any SAL_CALL convertToPropertyValue( const ::rtl::OUString& _rPropertyName, const ::com::sun::star::uno::Any& _rControlValue ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual ::com::sun::star::uno::Any SAL_CALL convertToControlValue( const ::rtl::OUString& _rPropertyName, const ::com::sun::star::uno::Any& _rPropertyValue, const ::com::sun::star::uno::Type& _rControlValueType ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual ::com::sun::star::beans::PropertyState SAL_CALL getPropertyState( const ::rtl::OUString& _rPropertyName ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual void SAL_CALL addPropertyChangeListener( const ::com::sun::star::uno::Reference< ::com::sun::star::beans::XPropertyChangeListener >& _rxListener ) throw (::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual void SAL_CALL removePropertyChangeListener( const ::com::sun::star::uno::Reference< ::com::sun::star::beans::XPropertyChangeListener >& _rxListener ) throw (::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual ::com::sun::star::uno::Sequence< ::com::sun::star::beans::Property >
|
|
|
|
|
SAL_CALL getSupportedProperties() throw (::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual ::com::sun::star::uno::Sequence< ::rtl::OUString > SAL_CALL getSupersededProperties( ) throw (::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual ::com::sun::star::uno::Sequence< ::rtl::OUString > SAL_CALL getActuatingProperties( ) throw (::com::sun::star::uno::RuntimeException);
|
2006-07-26 06:58:12 +00:00
|
|
|
virtual ::com::sun::star::inspection::LineDescriptor SAL_CALL describePropertyLine( const ::rtl::OUString& _rPropertyName, const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControlFactory >& _rxControlFactory ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::lang::NullPointerException, ::com::sun::star::uno::RuntimeException);
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/11/02 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
virtual ::sal_Bool SAL_CALL isComposable( const ::rtl::OUString& _rPropertyName ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual ::com::sun::star::inspection::InteractiveSelectionResult
|
|
|
|
|
SAL_CALL onInteractivePropertySelection( const ::rtl::OUString& _rPropertyName, sal_Bool _bPrimary, ::com::sun::star::uno::Any& _rData, const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XObjectInspectorUI >& _rxInspectorUI ) throw (::com::sun::star::beans::UnknownPropertyException, ::com::sun::star::lang::NullPointerException, ::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual void SAL_CALL actuatingPropertyChanged( const ::rtl::OUString& _rActuatingPropertyName, const ::com::sun::star::uno::Any& _rNewValue, const ::com::sun::star::uno::Any& _rOldValue, const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XObjectInspectorUI >& _rxInspectorUI, sal_Bool _bFirstTimeInit ) throw (::com::sun::star::lang::NullPointerException, ::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual sal_Bool SAL_CALL suspend( sal_Bool _bSuspend ) throw (::com::sun::star::uno::RuntimeException);
|
|
|
|
|
|
|
|
|
|
// XComponent
|
2008-01-14 13:57:25 +00:00
|
|
|
DECLARE_XCOMPONENT()
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/11/02 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
virtual void SAL_CALL disposing();
|
|
|
|
|
|
|
|
|
|
// XServiceInfo
|
|
|
|
|
virtual ::rtl::OUString SAL_CALL getImplementationName( ) throw (::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual ::sal_Bool SAL_CALL supportsService( const ::rtl::OUString& ServiceName ) throw (::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual ::com::sun::star::uno::Sequence< ::rtl::OUString > SAL_CALL getSupportedServiceNames( ) throw (::com::sun::star::uno::RuntimeException);
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
/** returns the script events associated with our introspectee
|
|
|
|
|
@param _out_rEvents
|
|
|
|
|
Takes, upon successfull return, the events currently associated with the introspectee
|
|
|
|
|
@precond
|
|
|
|
|
Our introspectee is a form component
|
|
|
|
|
*/
|
|
|
|
|
void impl_getFormComponentScriptEvents_nothrow(
|
|
|
|
|
::com::sun::star::uno::Sequence< ::com::sun::star::script::ScriptEventDescriptor >& _out_rEvents
|
|
|
|
|
) const;
|
|
|
|
|
|
|
|
|
|
/** returns the script events associated with our introspectee
|
|
|
|
|
@param _out_rEvents
|
|
|
|
|
Takes, upon successfull return, the events currently associated with the introspectee
|
|
|
|
|
@precond
|
|
|
|
|
Our introspectee is a dialog element
|
|
|
|
|
*/
|
|
|
|
|
void impl_getDialogElementScriptEvents_nothrow(
|
|
|
|
|
::com::sun::star::uno::Sequence< ::com::sun::star::script::ScriptEventDescriptor >& _out_rEvents
|
|
|
|
|
) const;
|
|
|
|
|
|
|
|
|
|
/** returns the script events associated with our introspectee
|
|
|
|
|
@param _out_rEvents
|
|
|
|
|
Takes, the events currently associated with the introspectee
|
|
|
|
|
*/
|
|
|
|
|
inline void impl_getComponentScriptEvents_nothrow(
|
|
|
|
|
::com::sun::star::uno::Sequence< ::com::sun::star::script::ScriptEventDescriptor >& _out_rEvents
|
|
|
|
|
) const
|
|
|
|
|
{
|
|
|
|
|
if ( m_bIsDialogElement )
|
|
|
|
|
impl_getDialogElementScriptEvents_nothrow( _out_rEvents );
|
|
|
|
|
else
|
|
|
|
|
impl_getFormComponentScriptEvents_nothrow( _out_rEvents );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** returns the types of the listeners which can be registered at our introspectee
|
|
|
|
|
@param _out_rTypes
|
|
|
|
|
Takes, upon successfull return, the types of possible listeners at the introspectee
|
|
|
|
|
*/
|
|
|
|
|
void impl_getCopmonentListenerTypes_nothrow(
|
|
|
|
|
::com::sun::star::uno::Sequence< ::com::sun::star::uno::Type >& _out_rTypes
|
|
|
|
|
) const;
|
|
|
|
|
|
|
|
|
|
/** returns a secondary component to be used for event inspection
|
|
|
|
|
|
|
|
|
|
In the UI, we want to mix events for the control model with events for the control.
|
|
|
|
|
Since our introspectee is a model, this method creates a control for it (if possible).
|
|
|
|
|
|
|
|
|
|
@return
|
|
|
|
|
the secondary component whose events should be mixed with the introspectee's events
|
|
|
|
|
The caller takes the ownership of the component (if not <NULL/>).
|
|
|
|
|
|
|
|
|
|
@throws
|
|
|
|
|
if an unexpected error occurs during creation of the secondary component.
|
|
|
|
|
A <NULL/> component to be returned is not unexpected, but allowed
|
|
|
|
|
|
|
|
|
|
@precond
|
|
|
|
|
->m_xComponent is not <NULL/>
|
|
|
|
|
*/
|
|
|
|
|
::com::sun::star::uno::Reference< ::com::sun::star::uno::XInterface >
|
|
|
|
|
impl_getSecondaryComponentForEventInspection_throw( ) const;
|
|
|
|
|
|
|
|
|
|
/** returns the event description for the given (programmatic) property name
|
|
|
|
|
@param _rPropertyName
|
|
|
|
|
the name whose event description should be looked up
|
|
|
|
|
@return
|
|
|
|
|
the event description for the property name
|
|
|
|
|
@throws ::com::sun::star::beans::UnknownPropertyException
|
|
|
|
|
if our introspectee does not have an event with the given logical name (see ->getSupportedProperties)
|
|
|
|
|
*/
|
|
|
|
|
const EventDescription&
|
|
|
|
|
impl_getEventForName_throw( const ::rtl::OUString& _rPropertyName ) const;
|
|
|
|
|
|
|
|
|
|
/** returns the index of our component within its parent, if this parent can be
|
|
|
|
|
obtained (XChild::getParent) and supports an ->XIndexAccess interface
|
|
|
|
|
*/
|
|
|
|
|
sal_Int32 impl_getComponentIndexInParent_throw() const;
|
|
|
|
|
|
2006-08-04 12:59:29 +00:00
|
|
|
/** sets a given script event as event handler at a form component
|
|
|
|
|
|
|
|
|
|
@param _rScriptEvent
|
|
|
|
|
the script event to set
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/11/02 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
*/
|
2006-08-04 12:59:29 +00:00
|
|
|
void impl_setFormComponentScriptEvent_nothrow( const ::com::sun::star::script::ScriptEventDescriptor& _rScriptEvent );
|
|
|
|
|
|
|
|
|
|
/** sets a given script event as event handler at a dialog component
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/11/02 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
|
2006-08-04 12:59:29 +00:00
|
|
|
@param _rScriptEvent
|
|
|
|
|
the script event to set
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/11/02 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
*/
|
2006-08-04 12:59:29 +00:00
|
|
|
void impl_setDialogElementScriptEvent_nothrow( const ::com::sun::star::script::ScriptEventDescriptor& _rScriptEvent );
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/11/02 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
|
2008-03-06 17:42:41 +00:00
|
|
|
/** returns the frame associated with our context document
|
|
|
|
|
*/
|
|
|
|
|
::com::sun::star::uno::Reference< ::com::sun::star::frame::XFrame >
|
|
|
|
|
impl_getContextFrame_nothrow() const;
|
|
|
|
|
|
CWS-TOOLING: integrate CWS dba32g
2009-09-09 07:53:55 +0200 oj r275964 : replace strlen with rtl_str_getLength
2009-09-07 20:59:10 +0200 fs r275913 : disable the CopyTableWizard test until issue 104869 is fixed
2009-09-07 12:17:31 +0200 oj r275885 : #i104810# remove de as lang
2009-09-05 22:26:21 +0200 fs r275857 : protect StateChanged against re-entrance
2009-09-05 22:25:52 +0200 fs r275856 : don't attempt to classify the parent of a form as control
2009-09-05 22:25:29 +0200 fs r275855 : protect against re-entrance
2009-09-05 00:11:40 +0200 fs r275835 : #i10000#
2009-09-04 23:25:50 +0200 fs r275834 : #i10000#
2009-09-04 23:23:47 +0200 fs r275833 : #i10000#
2009-09-04 21:49:37 +0200 fs r275830 : #i10000# correct wrong conflict resolution
2009-09-04 20:59:51 +0200 fs r275829 : CWS-TOOLING: rebase CWS dba32g to trunk@275801 (milestone: DEV300:m57)
2009-09-04 11:08:32 +0200 oj r275791 : #i104780# new version 1.2.0
2009-09-03 22:29:21 +0200 fs r275775 : OSL_TRACE doesn't need \n anymore
2009-09-03 08:33:21 +0200 fs r275743 : CWS-TOOLING: rebase CWS dba32g to trunk@275331 (milestone: DEV300:m56)
2009-09-02 13:48:12 +0200 fs r275708 : removed useless include
2009-09-02 13:45:43 +0200 fs r275707 : more since tags, which are used across offapi/udkapi
2009-09-02 13:23:04 +0200 fs r275705 : should *not* have the dtor, copy ctor, and assignment operator compiler-generated, else we run into trouble as soon as the compiler creates different versions of our singleton member's static data in different libraries
2009-09-02 12:32:45 +0200 fs r275704 : AutoIncrementIsPrimaryKey is a driver setting, not a data source setting
2009-09-02 11:42:49 +0200 fs r275701 : URL meta data are meta data which are valid for all connections of this type, not per-data-source properties. Settings them as data source properties is a hack.
2009-09-02 08:43:34 +0200 fs r275696 : 3.x.x is not a valid 'since' tag
2009-09-01 16:05:24 +0200 fs r275665 : #i104686# don't treat controls bound to read-only columns as required
2009-09-01 13:10:22 +0200 fs r275657 : #i104574# use PageUp/Down to scroll through the complete page
2009-09-01 07:04:48 +0200 oj r275641 : #i104104# correct line ends
2009-08-31 15:52:34 +0200 fs r275612 : #i104410#
2009-08-31 12:29:05 +0200 fs r275596 : #i104364#
2009-08-31 12:28:56 +0200 fs r275595 : #i104364#
2009-08-31 11:43:09 +0200 fs r275593 : #i104649# JavaDriverClassPath is also a known JDBC-bridge setting
2009-08-31 11:41:37 +0200 fs r275592 : #i104649#
2009-08-28 21:48:27 +0200 fs r275552 : during #i96862#: renamed the configuration data which controls availability of certain DBA-related UI
2009-08-28 21:48:17 +0200 fs r275551 : #i96862# do not show the 'Create a new database' option when a) no embedded/dBase driver is installed or b) the configuration requests to hide the option
2009-08-28 21:47:19 +0200 fs r275550 : during #i96862#: renamed the configuration data which controls availability of certain DBA-related UI
2009-08-28 21:46:41 +0200 fs r275549 : #i96862# renamed and extended the configuration data which controls availability of certain DBA-related UI
2009-08-28 15:10:19 +0200 fs r275535 : #i96862# if no embedded driver is installed, use dBase for creating new DBs. If no dBase driver is installed, too, do not offer the 'Create new database' option
2009-08-28 14:03:04 +0200 fs r275532 : #i104454# allow multiple fields to display the same column
2009-08-28 13:14:00 +0200 fs r275528 : #i104584# driver meta data do not belong into a data source's settings
2009-08-28 13:09:57 +0200 fs r275527 : properly chech the MySQL type buttons (else next/back in the wizard leads to state with two buttons checked)
2009-08-28 13:09:17 +0200 fs r275526 : #i104584# driver meta data do not belong into a data source's settings
2009-08-28 13:07:18 +0200 fs r275525 : BooleanComparisonMode is a property, or a feature - but not a driver meta data
2009-08-28 11:00:31 +0200 fs r275521 : #i104580#
2009-08-28 10:40:05 +0200 fs r275519 : #i104577# correct assertion: If the template node type is ANY, then any value type is allowed
2009-08-28 10:09:30 +0200 fs r275518 : #i104575# implement Named Pipe UI
2009-08-28 10:09:07 +0200 fs r275517 : pass the trigger-event to IWindowOperator::operateOn / work with VclWindowEvents, not VclSimpleEvents
2009-08-27 14:27:36 +0200 fs r275484 : ImplPosTabPage: respect mbEmptyViewMargin for WINDOWALIGN_LEFT
2009-08-27 13:43:56 +0200 fs r275480 : merging latest changes from CWS dba32f herein
2009-08-27 13:23:07 +0200 fs r275475 : #i103882#
2009-08-27 11:56:55 +0200 fs r275466 : #i104544# SetState: Do not call Update at the window which we just set text for. It should (sic\!) not be needed, but causes trouble
2009-08-27 11:55:34 +0200 fs r275465 : #i104544#
do not allow re-entrance for impl_ensureControl_nothrow
Actually, this is part of the fix only. I also removed the code which triggered this re-entrance (from
the grid control implementation), but to ensure it won't happen, again, I added some safety herein.
2009-08-27 10:14:11 +0200 fs r275459 : preparations for supporting a 'NamedPipe' parameter for the MySQL Connector/OOo
2009-08-27 10:13:21 +0200 fs r275458 : preparations for supporting a 'NamedPipe' setting for the MySQL Connector/OOo
2009-08-27 10:11:14 +0200 fs r275456 : outsourced the MySQLNative settings into a dedicated class, to not duplicate all the code in two tab page implementations
2009-08-26 14:18:13 +0200 fs r275422 : #i10000#
2009-08-26 13:26:36 +0200 fs r275419 : ignore output paths
2009-08-26 13:23:38 +0200 fs r275417 : support the LocalSocket property for the MySQL native driver
2009-08-26 13:17:05 +0200 fs r275416 : some re-factoring, to outsource the tab page for setting up the MySQLNative connection, into a dedicated class (needed later)
2009-08-26 13:15:15 +0200 fs r275415 : support a NoThousandSep property for NumericFormatters - I'm tired of correcting this at runtime, instead of controlling it in the resource
2009-08-26 11:45:08 +0200 fs r275410 : oops, 'flat' shouldn't have got lost
2009-08-26 09:38:57 +0200 fs r275398 : #i102631# when saving the document fails, ensure that the interaction handler really can handle/display the error
2009-08-26 09:37:05 +0200 fs r275397 : #i102631# don't let non-IO/RuntimeExceptions escape from DatabaseDocument::store*, wrap them into an IOException
2009-08-26 09:35:39 +0200 fs r275395 : let the default interaction handler implement XInteractionHandler2
2009-08-25 13:51:34 +0200 fs r275352 : #i102631# createTempFile: pass URL through FileHelper.getOOoCompatibleFileURL
2009-08-25 13:49:23 +0200 fs r275351 : #i102631# createTempFileURL: immediately delete the file implicitly created by createTempFile, we really only need the URL
2009-08-24 14:49:07 +0200 fs r275318 : #i10000#
2009-08-24 14:36:03 +0200 fs r275315 : properly terminate message with 0 character
2009-08-24 14:35:45 +0200 fs r275314 : trace method concepts in non-pro, if special flag is enabled
2009-08-24 14:24:17 +0200 fs r275312 : #i98973# filter some more events for grid control columns
2009-08-24 14:15:23 +0200 fs r275311 : #i98973# implement XComboBox for combo box cells
2009-08-24 13:39:24 +0200 fs r275308 : #i98973# do not display the 'actionPerformed' event for grid combo box columns
2009-08-24 12:52:03 +0200 fs r275303 : #i98973# implement XCheckBox and XButton for check box cells
2009-08-24 11:56:05 +0200 oj r275300 : #i104447# wrong default for orientation
2009-08-24 10:51:21 +0200 fs r275296 : in the script selector dialog, interpret a double click onto a function as OK
2009-08-24 10:50:56 +0200 fs r275295 : localize some to-be-displayed names, consolidate some code regarding form/control naming
2009-08-21 14:28:05 +0200 fs r275255 : #i98973# implement KeyListeners
2009-08-21 14:27:20 +0200 fs r275254 : #i98973# move the conversion VCL[Mouse|Key]Event->Awt[Mouse|Key]Event from vclxwindow.cxx to VCLUnoHelper
2009-08-21 14:08:50 +0200 fs r275248 : #i98973# implement Mouse- and MouseMotion-broadcasting
2009-08-21 13:31:08 +0200 fs r275244 : #i98973# implement text and change listeners at text cells
2009-08-21 12:47:38 +0200 fs r275234 : #i104399# some refactoring:
If the MySQL Connector/OOo is installed, it registers for the sdbc:mysqlc: protocol (now known as DST_MYSQL_NATIVE_DIRECT).
However, we do not want to display this in the UI, instead we display "MySQL" only, which collects DST_MYSQL_ODBC, DST_MYSQL_JDBC, and DST_MYSQL_NATIVE.
2009-08-21 12:45:18 +0200 fs r275232 : #i104399# also register for the sdbc:mysql:mysqlc protocol, decide at runtime (depending on the availability of sdbc:mysqlc:), whether it is really accepted. This prevents that the C/OOo extension needs to register *our* implementation name for the sdbc:mysql:mysqlc: protocol, which would be somewhat weird
2009-08-20 16:18:48 +0200 fs r275190 : merging the latest changes from CWS dba32f (which this CWS was created from)
2009-08-19 20:19:59 +0200 fs r275160 : add some spacing between the radios
2009-08-19 14:50:15 +0200 fs r275150 : #i98973# slightly refactoring the grid cell implementations, to prepare for proper events being fired. Implement focus events for the moment, more to come.
2009-08-19 10:53:38 +0200 fs r275142 : #i99936# initialize newly created models
2009-08-18 23:03:48 +0200 fs r275132 : merging latest changes from CWS dba32f
2009-08-18 15:14:08 +0200 fs r275110 : #i102819# SetColumnPos: SCROLL_CLIP is deadly here
2009-09-14 11:18:01 +00:00
|
|
|
/** approves or denies a certain method to be included in the UI
|
|
|
|
|
@return
|
|
|
|
|
<TRUE/> if and only if the given method is allowed.
|
|
|
|
|
*/
|
|
|
|
|
bool impl_filterMethod_nothrow( const EventDescription& _rEvent ) const;
|
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/11/02 12:17:15 fs 1.1.2.10: #i10000# exception specifications
2005/11/02 11:43:41 fs 1.1.2.9: #i10000# exception specifications
2005/10/25 07:13:10 fs 1.1.2.8: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:45 fs 1.1.2.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:18 fs 1.1.2.6: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.5: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:02 fs 1.1.2.4: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:11 fs 1.1.2.3: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/09/05 07:41:49 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:22 +00:00
|
|
|
private:
|
|
|
|
|
EventHandler(); // never implemented
|
|
|
|
|
EventHandler( const EventHandler& ); // never implemented
|
|
|
|
|
EventHandler& operator=( const EventHandler& ); // never implemented
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
//........................................................................
|
|
|
|
|
} // namespace pcr
|
|
|
|
|
//........................................................................
|
|
|
|
|
|
|
|
|
|
#endif // EXTENSIONS_SOURCE_PROPCTRLR_EVENTHANDLER_HXX
|
|
|
|
|
|