2010-10-12 15:57:08 +02:00
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
/*************************************************************************
*
2008-04-11 10:02:22 +00:00
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER .
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +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/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
*
2008-04-11 10:02:22 +00:00
* OpenOffice . org - a multi - platform office productivity suite
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
*
2008-04-11 10:02:22 +00:00
* This file is part of OpenOffice . org .
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
*
2008-04-11 10:02:22 +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/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
*
2008-04-11 10:02:22 +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/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
*
2008-04-11 10:02:22 +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/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2006-09-16 12:18:46 +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/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
# include "genericpropertyhandler.hxx"
# include "formmetadata.hxx"
# include "handlerhelper.hxx"
/** === begin UNO includes === **/
# include <com/sun/star/container/XHierarchicalNameAccess.hpp>
# include <com/sun/star/reflection/XEnumTypeDescription.hpp>
# include <com/sun/star/beans/XIntrospection.hpp>
# include <com/sun/star/inspection/PropertyControlType.hpp>
# include <com/sun/star/inspection/XHyperlinkControl.hpp>
# include <com/sun/star/awt/XActionListener.hpp>
# include <com/sun/star/util/XURLTransformer.hpp>
# include <com/sun/star/frame/XDispatchProvider.hpp>
/** === end UNO includes === **/
# include <tools/debug.hxx>
# include <cppuhelper/extract.hxx>
# include <algorithm>
2011-02-08 19:22:43 +01:00
# include <o3tl/compat_functional.hxx>
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
//------------------------------------------------------------------------
extern " C " void SAL_CALL createRegistryInfo_GenericPropertyHandler ( )
{
: : pcr : : OAutoRegistration < : : pcr : : GenericPropertyHandler > aAutoRegistration ;
}
//........................................................................
namespace pcr
{
//........................................................................
using namespace : : com : : sun : : star : : uno ;
using namespace : : com : : sun : : star : : beans ;
using namespace : : com : : sun : : star : : script ;
using namespace : : com : : sun : : star : : frame ;
using namespace : : com : : sun : : star : : lang ;
using namespace : : com : : sun : : star : : util ;
using namespace : : com : : sun : : star : : container ;
using namespace : : com : : sun : : star : : reflection ;
using namespace : : com : : sun : : star : : inspection ;
using : : com : : sun : : star : : awt : : XActionListener ;
using : : com : : sun : : star : : awt : : ActionEvent ;
//====================================================================
//= EnumRepresentation
//====================================================================
class EnumRepresentation : public IPropertyEnumRepresentation
{
private :
oslInterlockedCount m_refCount ;
Reference < XEnumTypeDescription > m_xTypeDescription ;
Type m_aEnumType ;
public :
EnumRepresentation ( const Reference < XComponentContext > & _rxContext , const Type & _rEnumType ) ;
// IPropertyEnumRepresentation implementqation
virtual : : std : : vector < : : rtl : : OUString >
SAL_CALL getDescriptions ( ) const ;
virtual void SAL_CALL getValueFromDescription ( const : : rtl : : OUString & _rDescription , : : com : : sun : : star : : uno : : Any & _out_rValue ) const ;
virtual : : rtl : : OUString SAL_CALL getDescriptionForValue ( const : : com : : sun : : star : : uno : : Any & _rEnumValue ) const ;
// IReference implementqation
virtual oslInterlockedCount SAL_CALL acquire ( ) ;
virtual oslInterlockedCount SAL_CALL release ( ) ;
private :
void impl_getValues ( Sequence < sal_Int32 > & _out_rValues ) const ;
private :
EnumRepresentation ( ) ; // never implemented
EnumRepresentation ( const EnumRepresentation & ) ; // never implemented
EnumRepresentation & operator = ( const EnumRepresentation & ) ; // never implemented
} ;
//--------------------------------------------------------------------
EnumRepresentation : : EnumRepresentation ( const Reference < XComponentContext > & _rxContext , const Type & _rEnumType )
2008-01-14 13:58:59 +00:00
: m_refCount ( 0 )
, m_aEnumType ( _rEnumType )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
{
try
{
if ( _rxContext . is ( ) )
{
Reference < XHierarchicalNameAccess > xTypeDescProv (
_rxContext - > getValueByName ( : : rtl : : OUString ( RTL_CONSTASCII_USTRINGPARAM ( " /singletons/com.sun.star.reflection.theTypeDescriptionManager " ) ) ) ,
UNO_QUERY_THROW ) ;
m_xTypeDescription = Reference < XEnumTypeDescription > ( xTypeDescProv - > getByHierarchicalName ( m_aEnumType . getTypeName ( ) ) , UNO_QUERY_THROW ) ;
}
}
catch ( const Exception & )
{
OSL_ENSURE ( sal_False , " EnumRepresentation::EnumRepresentation: caught an exception! " ) ;
}
}
//--------------------------------------------------------------------
: : std : : vector < : : rtl : : OUString > EnumRepresentation : : getDescriptions ( ) const
{
Sequence < : : rtl : : OUString > aNames ;
try
{
if ( m_xTypeDescription . is ( ) )
aNames = m_xTypeDescription - > getEnumNames ( ) ;
}
catch ( const Exception & )
{
OSL_ENSURE ( sal_False , " EnumRepresentation::getDescriptions: caught an exception! " ) ;
}
return : : std : : vector < : : rtl : : OUString > ( aNames . getConstArray ( ) , aNames . getConstArray ( ) + aNames . getLength ( ) ) ;
}
//--------------------------------------------------------------------
void EnumRepresentation : : impl_getValues ( Sequence < sal_Int32 > & _out_rValues ) const
{
_out_rValues . realloc ( 0 ) ;
try
{
if ( m_xTypeDescription . is ( ) )
_out_rValues = m_xTypeDescription - > getEnumValues ( ) ;
}
catch ( const Exception & )
{
OSL_ENSURE ( sal_False , " EnumRepresentation::impl_getValues: caught an exception! " ) ;
}
}
//--------------------------------------------------------------------
void EnumRepresentation : : getValueFromDescription ( const : : rtl : : OUString & _rDescription , Any & _out_rValue ) const
{
: : std : : vector < : : rtl : : OUString > aDescriptions ( getDescriptions ( ) ) ;
sal_Int32 index = : : std : : find ( aDescriptions . begin ( ) , aDescriptions . end ( ) ,
_rDescription ) - aDescriptions . begin ( ) ;
Sequence < sal_Int32 > aValues ;
impl_getValues ( aValues ) ;
if ( ( index > = 0 ) & & ( index < aValues . getLength ( ) ) )
_out_rValue = : : cppu : : int2enum ( aValues [ index ] , m_aEnumType ) ;
else
{
DBG_ERROR ( " EnumRepresentation::getValueFromDescription: cannot convert! " ) ;
_out_rValue . clear ( ) ;
}
}
//--------------------------------------------------------------------
: : rtl : : OUString EnumRepresentation : : getDescriptionForValue ( const Any & _rEnumValue ) const
{
: : rtl : : OUString sDescription ;
sal_Int32 nAsInt = 0 ;
OSL_VERIFY ( : : cppu : : enum2int ( nAsInt , _rEnumValue ) ) ;
Sequence < sal_Int32 > aValues ;
impl_getValues ( aValues ) ;
sal_Int32 index = : : std : : find ( aValues . getConstArray ( ) , aValues . getConstArray ( ) + aValues . getLength ( ) ,
nAsInt ) - aValues . getConstArray ( ) ;
: : std : : vector < : : rtl : : OUString > aDescriptions ( getDescriptions ( ) ) ;
if ( ( index > = 0 ) & & ( index < ( sal_Int32 ) aDescriptions . size ( ) ) )
sDescription = aDescriptions [ index ] ;
else
2008-10-28 15:03:16 +00:00
{
DBG_ERROR ( " EnumRepresentation::getDescriptionForValue: cannot convert! " ) ;
}
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
return sDescription ;
}
//--------------------------------------------------------------------
oslInterlockedCount SAL_CALL EnumRepresentation : : acquire ( )
{
return osl_incrementInterlockedCount ( & m_refCount ) ;
}
//--------------------------------------------------------------------
oslInterlockedCount SAL_CALL EnumRepresentation : : release ( )
{
if ( 0 = = osl_decrementInterlockedCount ( & m_refCount ) )
{
delete this ;
return 0 ;
}
return m_refCount ;
}
//====================================================================
//= UrlClickHandler
//====================================================================
typedef : : cppu : : WeakImplHelper1 < XActionListener
> UrlClickHandler_Base ;
class UrlClickHandler : public UrlClickHandler_Base
{
ComponentContext m_aContext ;
public :
UrlClickHandler ( const ComponentContext & _rContext , const Reference < XHyperlinkControl > & _rxControl ) ;
protected :
~ UrlClickHandler ( ) ;
// XActionListener
virtual void SAL_CALL actionPerformed ( const ActionEvent & rEvent ) throw ( RuntimeException ) ;
// XEventListener
virtual void SAL_CALL disposing ( const EventObject & Source ) throw ( RuntimeException ) ;
protected :
void impl_dispatch_throw ( const : : rtl : : OUString & _rURL ) ;
} ;
//--------------------------------------------------------------------
DBG_NAME ( UrlClickHandler )
//--------------------------------------------------------------------
UrlClickHandler : : UrlClickHandler ( const ComponentContext & _rContext , const Reference < XHyperlinkControl > & _rxControl )
: m_aContext ( _rContext )
{
if ( ! _rxControl . is ( ) )
throw NullPointerException ( ) ;
osl_incrementInterlockedCount ( & m_refCount ) ;
{
_rxControl - > addActionListener ( this ) ;
}
osl_decrementInterlockedCount ( & m_refCount ) ;
OSL_ENSURE ( m_refCount > 0 , " UrlClickHandler::UrlClickHandler: leaking! " ) ;
DBG_CTOR ( UrlClickHandler , NULL ) ;
}
//--------------------------------------------------------------------
UrlClickHandler : : ~ UrlClickHandler ( )
{
DBG_DTOR ( UrlClickHandler , NULL ) ;
}
//--------------------------------------------------------------------
void SAL_CALL UrlClickHandler : : actionPerformed ( const ActionEvent & rEvent ) throw ( RuntimeException )
{
Reference < XPropertyControl > xControl ( rEvent . Source , UNO_QUERY_THROW ) ;
Any aControlValue ( xControl - > getValue ( ) ) ;
: : rtl : : OUString sURL ;
if ( aControlValue . hasValue ( ) & & ! ( aControlValue > > = sURL ) )
throw RuntimeException ( : : rtl : : OUString ( ) , * this ) ;
if ( ! sURL . getLength ( ) )
return ;
impl_dispatch_throw ( sURL ) ;
}
//--------------------------------------------------------------------
2006-07-26 06:58:12 +00:00
void SAL_CALL UrlClickHandler : : disposing ( const EventObject & /*Source*/ ) throw ( RuntimeException )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
{
// not interested in
}
//--------------------------------------------------------------------
void UrlClickHandler : : impl_dispatch_throw ( const : : rtl : : OUString & _rURL )
{
Reference < XURLTransformer > xTransformer ( m_aContext . createComponent ( " com.sun.star.util.URLTransformer " ) , UNO_QUERY_THROW ) ;
URL aURL ; aURL . Complete = : : rtl : : OUString ( RTL_CONSTASCII_USTRINGPARAM ( " .uno:OpenHyperlink " ) ) ;
xTransformer - > parseStrict ( aURL ) ;
Reference < XDispatchProvider > xDispProv ( m_aContext . createComponent ( " com.sun.star.frame.Desktop " ) , UNO_QUERY_THROW ) ;
Reference < XDispatch > xDispatch ( xDispProv - > queryDispatch ( aURL , : : rtl : : OUString ( ) , 0 ) , UNO_QUERY_THROW ) ;
Sequence < PropertyValue > aDispatchArgs ( 1 ) ;
aDispatchArgs [ 0 ] . Name = : : rtl : : OUString ( RTL_CONSTASCII_USTRINGPARAM ( " URL " ) ) ;
aDispatchArgs [ 0 ] . Value < < = _rURL ;
xDispatch - > dispatch ( aURL , aDispatchArgs ) ;
}
//====================================================================
//= GenericPropertyHandler
//====================================================================
DBG_NAME ( GenericPropertyHandler )
//--------------------------------------------------------------------
GenericPropertyHandler : : GenericPropertyHandler ( const Reference < XComponentContext > & _rxContext )
: GenericPropertyHandler_Base ( m_aMutex )
, m_aContext ( _rxContext )
, m_aPropertyListeners ( m_aMutex )
2008-01-14 13:58:59 +00:00
, m_bPropertyMapInitialized ( false )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
{
DBG_CTOR ( GenericPropertyHandler , NULL ) ;
m_xTypeConverter = Reference < XTypeConverter > (
m_aContext . createComponent ( " com.sun.star.script.Converter " ) ,
UNO_QUERY_THROW
) ;
}
//--------------------------------------------------------------------
GenericPropertyHandler : : ~ GenericPropertyHandler ( )
{
DBG_DTOR ( GenericPropertyHandler , NULL ) ;
}
//--------------------------------------------------------------------
: : rtl : : OUString SAL_CALL GenericPropertyHandler : : getImplementationName ( ) throw ( RuntimeException )
{
return getImplementationName_static ( ) ;
}
//--------------------------------------------------------------------
: : sal_Bool SAL_CALL GenericPropertyHandler : : 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 GenericPropertyHandler : : getSupportedServiceNames ( ) throw ( RuntimeException )
{
return getSupportedServiceNames_static ( ) ;
}
//--------------------------------------------------------------------
: : rtl : : OUString SAL_CALL GenericPropertyHandler : : getImplementationName_static ( ) throw ( RuntimeException )
{
return : : rtl : : OUString ( RTL_CONSTASCII_USTRINGPARAM ( " com.sun.star.comp.extensions.GenericPropertyHandler " ) ) ;
}
//--------------------------------------------------------------------
Sequence < : : rtl : : OUString > SAL_CALL GenericPropertyHandler : : getSupportedServiceNames_static ( ) throw ( RuntimeException )
{
Sequence < : : rtl : : OUString > aSupported ( 1 ) ;
aSupported [ 0 ] = : : rtl : : OUString ( RTL_CONSTASCII_USTRINGPARAM ( " com.sun.star.inspection.GenericPropertyHandler " ) ) ;
return aSupported ;
}
//--------------------------------------------------------------------
Reference < XInterface > SAL_CALL GenericPropertyHandler : : Create ( const Reference < XComponentContext > & _rxContext )
{
return * ( new GenericPropertyHandler ( _rxContext ) ) ;
}
//--------------------------------------------------------------------
void SAL_CALL GenericPropertyHandler : : inspect ( const Reference < XInterface > & _rxIntrospectee ) throw ( RuntimeException , NullPointerException )
{
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
if ( ! _rxIntrospectee . is ( ) )
throw NullPointerException ( ) ;
// revoke old property change listeners
: : cppu : : OInterfaceIteratorHelper iterRemove ( m_aPropertyListeners ) ;
: : cppu : : OInterfaceIteratorHelper iterReAdd ( m_aPropertyListeners ) ; // this holds a copy of the container ...
while ( iterRemove . hasMoreElements ( ) )
m_xComponent - > removePropertyChangeListener ( : : rtl : : OUString ( ) , static_cast < XPropertyChangeListener * > ( iterRemove . next ( ) ) ) ;
m_xComponentIntrospectionAccess . clear ( ) ;
m_xComponent . clear ( ) ;
m_xPropertyState . clear ( ) ;
// create an introspection adapter for the component
Reference < XIntrospection > xIntrospection ;
if ( ! m_aContext . createComponent ( " com.sun.star.beans.Introspection " , xIntrospection ) )
throw RuntimeException ( : : rtl : : OUString ( RTL_CONSTASCII_USTRINGPARAM ( " Could not create an instance of the service com.sun.star.beans.Introspection. " ) ) , * this ) ;
Reference < XIntrospectionAccess > xIntrospectionAccess ( xIntrospection - > inspect ( makeAny ( _rxIntrospectee ) ) ) ;
if ( ! xIntrospectionAccess . is ( ) )
throw RuntimeException ( : : rtl : : OUString ( RTL_CONSTASCII_USTRINGPARAM ( " The introspection service could not handle the given component. " ) ) , * this ) ;
m_xComponent = Reference < XPropertySet > ( xIntrospectionAccess - > queryAdapter ( XPropertySet : : static_type ( ) ) , UNO_QUERY_THROW ) ;
// now that we survived so far, remember m_xComponentIntrospectionAccess
m_xComponentIntrospectionAccess = xIntrospectionAccess ;
m_xPropertyState = m_xPropertyState . query ( m_xComponent ) ;
m_bPropertyMapInitialized = false ;
m_aProperties . clear ( ) ;
// re-add the property change listeners
while ( iterReAdd . hasMoreElements ( ) )
m_xComponent - > addPropertyChangeListener ( : : rtl : : OUString ( ) , static_cast < XPropertyChangeListener * > ( iterReAdd . next ( ) ) ) ;
}
//--------------------------------------------------------------------
Any SAL_CALL GenericPropertyHandler : : getPropertyValue ( const : : rtl : : OUString & _rPropertyName ) throw ( UnknownPropertyException , RuntimeException )
{
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
if ( ! m_xComponent . is ( ) )
throw UnknownPropertyException ( ) ;
return m_xComponent - > getPropertyValue ( _rPropertyName ) ;
}
//--------------------------------------------------------------------
void SAL_CALL GenericPropertyHandler : : setPropertyValue ( const : : rtl : : OUString & _rPropertyName , const Any & _rValue ) throw ( UnknownPropertyException , RuntimeException )
{
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
if ( ! m_xComponent . is ( ) )
throw UnknownPropertyException ( ) ;
m_xComponent - > setPropertyValue ( _rPropertyName , _rValue ) ;
}
//--------------------------------------------------------------------
: : rtl : : Reference < IPropertyEnumRepresentation > GenericPropertyHandler : : impl_getEnumConverter ( const Type & _rEnumType )
{
: : rtl : : Reference < IPropertyEnumRepresentation > & rConverter = m_aEnumConverters [ _rEnumType ] ;
if ( ! rConverter . is ( ) )
rConverter = new EnumRepresentation ( m_aContext . getUNOContext ( ) , _rEnumType ) ;
return rConverter ;
}
//--------------------------------------------------------------------
Any SAL_CALL GenericPropertyHandler : : convertToPropertyValue ( const : : rtl : : OUString & _rPropertyName , const Any & _rControlValue ) throw ( UnknownPropertyException , RuntimeException )
{
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
const_cast < GenericPropertyHandler * > ( this ) - > impl_ensurePropertyMap ( ) ;
PropertyMap : : const_iterator pos = m_aProperties . find ( _rPropertyName ) ;
if ( pos = = m_aProperties . end ( ) )
throw UnknownPropertyException ( ) ;
Any aPropertyValue ;
if ( ! _rControlValue . hasValue ( ) )
// NULL is converted to NULL
return aPropertyValue ;
if ( pos - > second . Type . getTypeClass ( ) = = TypeClass_ENUM )
{
: : rtl : : OUString sControlValue ;
OSL_VERIFY ( _rControlValue > > = sControlValue ) ;
impl_getEnumConverter ( pos - > second . Type ) - > getValueFromDescription ( sControlValue , aPropertyValue ) ;
}
else
2007-07-06 07:49:25 +00:00
aPropertyValue = PropertyHandlerHelper : : convertToPropertyValue ( m_aContext . getContext ( ) , m_xTypeConverter , pos - > second , _rControlValue ) ;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
return aPropertyValue ;
}
//--------------------------------------------------------------------
Any SAL_CALL GenericPropertyHandler : : convertToControlValue ( const : : rtl : : OUString & _rPropertyName , const Any & _rPropertyValue , const Type & _rControlValueType ) throw ( UnknownPropertyException , RuntimeException )
{
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
const_cast < GenericPropertyHandler * > ( this ) - > impl_ensurePropertyMap ( ) ;
PropertyMap : : const_iterator pos = m_aProperties . find ( _rPropertyName ) ;
if ( pos = = m_aProperties . end ( ) )
throw UnknownPropertyException ( ) ;
Any aControlValue ;
if ( ! _rPropertyValue . hasValue ( ) )
// NULL is converted to NULL
return aControlValue ;
if ( pos - > second . Type . getTypeClass ( ) = = TypeClass_ENUM )
{
aControlValue < < = impl_getEnumConverter ( pos - > second . Type ) - > getDescriptionForValue ( _rPropertyValue ) ;
}
else
2007-07-06 07:49:25 +00:00
aControlValue = PropertyHandlerHelper : : convertToControlValue ( m_aContext . getContext ( ) , m_xTypeConverter , _rPropertyValue , _rControlValueType ) ;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
return aControlValue ;
}
//--------------------------------------------------------------------
PropertyState SAL_CALL GenericPropertyHandler : : getPropertyState ( const : : rtl : : OUString & _rPropertyName ) throw ( UnknownPropertyException , RuntimeException )
{
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
PropertyState eState = PropertyState_DIRECT_VALUE ;
if ( m_xPropertyState . is ( ) )
eState = m_xPropertyState - > getPropertyState ( _rPropertyName ) ;
return eState ;
}
//--------------------------------------------------------------------
void SAL_CALL GenericPropertyHandler : : addPropertyChangeListener ( const Reference < XPropertyChangeListener > & _rxListener ) throw ( RuntimeException )
{
if ( ! _rxListener . is ( ) )
throw NullPointerException ( ) ;
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
m_aPropertyListeners . addInterface ( _rxListener ) ;
if ( m_xComponent . is ( ) )
{
try
{
m_xComponent - > addPropertyChangeListener ( : : rtl : : OUString ( ) , _rxListener ) ;
}
catch ( const UnknownPropertyException & )
{
OSL_ENSURE ( false , " GenericPropertyHandler::addPropertyChangeListener: \n The inspected component does not allow registering for all properties at once! This violates the interface contract! " ) ;
}
}
}
//--------------------------------------------------------------------
void SAL_CALL GenericPropertyHandler : : removePropertyChangeListener ( const Reference < XPropertyChangeListener > & _rxListener ) throw ( RuntimeException )
{
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
if ( m_xComponent . is ( ) )
{
try
{
m_xComponent - > removePropertyChangeListener ( : : rtl : : OUString ( ) , _rxListener ) ;
}
catch ( const UnknownPropertyException & )
{
OSL_ENSURE ( false , " GenericPropertyHandler::removePropertyChangeListener: \n The inspected component does not allow de-registering for all properties at once! This violates the interface contract! " ) ;
}
}
m_aPropertyListeners . removeInterface ( _rxListener ) ;
}
//--------------------------------------------------------------------
void GenericPropertyHandler : : impl_ensurePropertyMap ( )
{
if ( ! m_bPropertyMapInitialized )
{
m_bPropertyMapInitialized = true ;
try
{
Reference < XPropertySetInfo > xPSI ;
if ( m_xComponent . is ( ) )
xPSI = m_xComponent - > getPropertySetInfo ( ) ;
Sequence < Property > aProperties ;
if ( xPSI . is ( ) )
aProperties = xPSI - > getProperties ( ) ;
DBG_ASSERT ( aProperties . getLength ( ) , " GenericPropertyHandler::getSupportedProperties: no properties! " ) ;
for ( const Property * pProperties = aProperties . getConstArray ( ) ;
pProperties ! = aProperties . getConstArray ( ) + aProperties . getLength ( ) ;
+ + pProperties
)
{
switch ( pProperties - > Type . getTypeClass ( ) )
{
case TypeClass_BOOLEAN :
case TypeClass_BYTE :
case TypeClass_SHORT :
case TypeClass_UNSIGNED_SHORT :
case TypeClass_LONG :
case TypeClass_UNSIGNED_LONG :
case TypeClass_HYPER :
case TypeClass_UNSIGNED_HYPER :
case TypeClass_FLOAT :
case TypeClass_DOUBLE :
case TypeClass_ENUM :
case TypeClass_STRING :
// allowed, we can handle this type
break ;
case TypeClass_SEQUENCE :
{
TypeClass eElementTypeClass = : : comphelper : : getSequenceElementType ( pProperties - > Type ) . getTypeClass ( ) ;
if ( ( eElementTypeClass ! = TypeClass_STRING )
& & ( eElementTypeClass ! = TypeClass_BYTE )
& & ( eElementTypeClass ! = TypeClass_SHORT )
& & ( eElementTypeClass ! = TypeClass_UNSIGNED_SHORT )
& & ( eElementTypeClass ! = TypeClass_LONG )
& & ( eElementTypeClass ! = TypeClass_UNSIGNED_LONG )
)
// can only handle the above
continue ;
}
break ;
default :
// next property, we don't support this type
continue ;
}
m_aProperties . insert ( PropertyMap : : value_type ( pProperties - > Name , * pProperties ) ) ;
}
}
catch ( const Exception & )
{
OSL_ENSURE ( sal_False , " GenericPropertyHandler::impl_ensurePropertyMap: caught an exception! " ) ;
}
}
}
//--------------------------------------------------------------------
Sequence < Property > SAL_CALL GenericPropertyHandler : : getSupportedProperties ( ) throw ( RuntimeException )
{
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
const_cast < GenericPropertyHandler * > ( this ) - > impl_ensurePropertyMap ( ) ;
Sequence < Property > aReturn ( m_aProperties . size ( ) ) ;
: : std : : transform ( m_aProperties . begin ( ) , m_aProperties . end ( ) ,
2011-02-08 19:22:43 +01:00
aReturn . getArray ( ) , : : o3tl : : select2nd < PropertyMap : : value_type > ( ) ) ;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
return aReturn ;
}
//--------------------------------------------------------------------
Sequence < : : rtl : : OUString > SAL_CALL GenericPropertyHandler : : getSupersededProperties ( ) throw ( RuntimeException )
{
// no superseded properties at all. This handler offers the very basic PropertyHandler
// functionality, so it's much more likely that other handlers want to supersede
// *our* properties ....
return Sequence < : : rtl : : OUString > ( ) ;
}
//--------------------------------------------------------------------
Sequence < : : rtl : : OUString > SAL_CALL GenericPropertyHandler : : getActuatingProperties ( ) throw ( RuntimeException )
{
// This basic PropertyHandler implementation is too dumb^Wgeneric to know
// anything about property dependencies
return Sequence < : : rtl : : OUString > ( ) ;
}
//--------------------------------------------------------------------
2006-07-26 06:58:12 +00:00
LineDescriptor SAL_CALL GenericPropertyHandler : : describePropertyLine ( const : : rtl : : OUString & _rPropertyName ,
const Reference < XPropertyControlFactory > & _rxControlFactory )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
throw ( UnknownPropertyException , NullPointerException , RuntimeException )
{
if ( ! _rxControlFactory . is ( ) )
throw NullPointerException ( ) ;
: : osl : : MutexGuard aGuard ( m_aMutex ) ;
const_cast < GenericPropertyHandler * > ( this ) - > impl_ensurePropertyMap ( ) ;
PropertyMap : : const_iterator pos = m_aProperties . find ( _rPropertyName ) ;
if ( pos = = m_aProperties . end ( ) )
throw UnknownPropertyException ( ) ;
2006-07-26 06:58:12 +00:00
LineDescriptor aDescriptor ;
aDescriptor . DisplayName = _rPropertyName ;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
switch ( pos - > second . Type . getTypeClass ( ) )
{
case TypeClass_ENUM :
2006-07-26 06:58:12 +00:00
aDescriptor . Control = PropertyHandlerHelper : : createListBoxControl ( _rxControlFactory ,
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
impl_getEnumConverter ( pos - > second . Type ) - > getDescriptions ( ) ,
2006-12-13 15:57:21 +00:00
PropertyHandlerHelper : : requiresReadOnlyControl ( pos - > second . Attributes ) ,
sal_False ) ;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
break ;
case TypeClass_STRING :
{
// some special handling for URL properties
bool bIsURLProperty = ( _rPropertyName . getLength ( ) > = 3 ) & & _rPropertyName . matchAsciiL ( " URL " , 3 , _rPropertyName . getLength ( ) - 3 ) ;
if ( bIsURLProperty )
{
2006-07-26 06:58:12 +00:00
aDescriptor . Control = _rxControlFactory - > createPropertyControl (
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
PropertyControlType : : HyperlinkField , PropertyHandlerHelper : : requiresReadOnlyControl ( pos - > second . Attributes ) ) ;
2006-07-26 06:58:12 +00:00
Reference < XHyperlinkControl > xControl ( aDescriptor . Control , UNO_QUERY_THROW ) ;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
Reference < XActionListener > xEnsureDelete ( new UrlClickHandler ( m_aContext , xControl ) ) ;
}
}
break ;
2006-07-26 06:58:12 +00:00
default :
break ;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
}
// fallback
2006-07-26 06:58:12 +00:00
if ( ! aDescriptor . Control . is ( ) )
PropertyHandlerHelper : : describePropertyLine ( pos - > second , aDescriptor , _rxControlFactory ) ;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
2006-07-26 06:58:12 +00:00
aDescriptor . Category = : : rtl : : OUString ( RTL_CONSTASCII_USTRINGPARAM ( " General " ) ) ;
return aDescriptor ;
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
}
//--------------------------------------------------------------------
2006-07-26 06:58:12 +00:00
: : sal_Bool SAL_CALL GenericPropertyHandler : : isComposable ( const : : rtl : : OUString & /*_rPropertyName*/ ) throw ( UnknownPropertyException , RuntimeException )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
{
return sal_False ;
}
//--------------------------------------------------------------------
2006-07-26 06:58:12 +00:00
InteractiveSelectionResult SAL_CALL GenericPropertyHandler : : 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/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
{
DBG_ERROR ( " GenericPropertyHandler::onInteractivePropertySelection: I'm too dumb to know anything about property browse buttons! " ) ;
return InteractiveSelectionResult_Cancelled ;
}
//--------------------------------------------------------------------
2006-07-26 06:58:12 +00:00
void SAL_CALL GenericPropertyHandler : : 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/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
{
DBG_ERROR ( " GenericPropertyHandler::actuatingPropertyChanged: no no no, I did not register for any actuating properties! " ) ;
}
//--------------------------------------------------------------------
2006-07-26 06:58:12 +00:00
sal_Bool SAL_CALL GenericPropertyHandler : : suspend ( sal_Bool /*_bSuspend*/ ) throw ( RuntimeException )
INTEGRATION: CWS pbrwuno (1.1.2); FILE ADDED
2005/12/20 10:54:23 fs 1.1.2.17: #i53095# special handling for URL properties: use a hyperlink control
2005/12/19 12:19:52 fs 1.1.2.16: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.15: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.14: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.13: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:30 fs 1.1.2.11: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:17 fs 1.1.2.10: some mutex locking
2005/10/14 12:43:45 fs 1.1.2.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:20 fs 1.1.2.7: #i53095# 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:51 fs 1.1.2.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:30 fs 1.1.2.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:03 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:12 fs 1.1.2.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.1.2.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:02 fs 1.1.2.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:25:05 +00:00
{
return sal_True ;
}
//--------------------------------------------------------------------
void SAL_CALL GenericPropertyHandler : : disposing ( )
{
m_aPropertyListeners . clear ( ) ;
// not disposeAndClear: the listeners are (virtually) listeners at our introspectee, not
// at this handler instance
}
//--------------------------------------------------------------------
IMPLEMENT_FORWARD_XCOMPONENT ( GenericPropertyHandler , GenericPropertyHandler_Base ) ;
//........................................................................
} // namespace pcr
//........................................................................
2010-10-12 15:57:08 +02:00
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */