2006/02/13 07:28:41 fs 1.17.36.17: #i10000#
2006/02/10 11:51:46 fs 1.17.36.16: NullPointerException is unusual at addFooListener methods
2006/02/10 08:32:14 fs 1.17.36.15: RESYNC: (1.18-1.19); FILE MERGED
2005/12/20 10:54:54 fs 1.17.36.14: #i53095# new control type for editing hyperlinks
2005/12/19 12:23:15 fs 1.17.36.13: #i53095# don't produce an trailing empty line in multi line edits
2005/12/16 15:29:58 fs 1.17.36.12: ImplCalcLongValue: care for overflow
2005/10/26 14:03:33 fs 1.17.36.11: some cleanups for finalizing #i53095#
2005/10/24 08:42:07 fs 1.17.36.10: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.17.36.9: #i53095# knitting some loose ends
2005/10/17 12:20:18 fs 1.17.36.8: make StringListField exchange a sequence< string >
2005/10/17 10:28:00 fs 1.17.36.7: #i53095# make numeric field exchange its values as double
2005/10/17 09:48:42 fs 1.17.36.6: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 07:17:05 fs 1.17.36.5: replace MeasurementUnit with css.util.MeasureUnit
2005/10/14 12:43:49 fs 1.17.36.4: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 07:10:42 fs 1.17.36.3: RESYNC: (1.17-1.18); FILE MERGED
2005/09/05 07:41:54 fs 1.17.36.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/09 14:00:07 fs 1.17.36.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
2005/10/13 13:01:11 fs 1.1.2.3: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:51 fs 1.1.2.2: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/08/12 16:30:15 fs 1.1.2.1: - 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/10/24 08:42:06 fs 1.1.2.3: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/13 13:01:11 fs 1.1.2.2: #i53095# introduce an XObjectInspector/Model
2005/08/12 16:30:15 fs 1.1.2.1: - 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/10/24 08:42:05 fs 1.4.16.1: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/24 08:42:04 fs 1.5.16.1: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/11 13:29:49 fs 1.3.158.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:08:20 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:54 fs 1.3.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/10 15:41:48 fs 1.3.158.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:07 fs 1.3.158.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
2005/10/05 07:08:08 fs 1.5.294.2: RESYNC: (1.5-1.6); FILE MERGED
2005/08/09 14:00:07 fs 1.5.294.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
2005/11/02 12:17:21 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:46 fs 1.3.88.17: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.3.88.16: some cleanup
2005/10/25 07:13:15 fs 1.3.88.15: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:04 fs 1.3.88.14: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:38 fs 1.3.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:03 fs 1.3.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:20 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:47 fs 1.3.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:58 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:54 fs 1.3.88.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:35 fs 1.3.88.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:06 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.3.88.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:47 fs 1.3.88.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:06 fs 1.3.88.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/08 10:13:18 fs 1.4.88.21: describePropertyLine: always set a help id
2005/11/02 12:17:21 fs 1.4.88.20: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.4.88.19: #i10000# exception specifications
2005/10/31 13:45:59 fs 1.4.88.18: some cleanup
2005/10/25 07:13:15 fs 1.4.88.17: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:03 fs 1.4.88.16: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:06 fs 1.4.88.15: #i53095# knitting some loose ends
2005/10/17 14:19:01 fs 1.4.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:37 fs 1.4.88.13: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:02 fs 1.4.88.12: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 08:58:19 fs 1.4.88.11: some mutex locking
2005/10/14 12:43:48 fs 1.4.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:10 fs 1.4.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:44 fs 1.4.88.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:07:45 fs 1.4.88.7: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:54 fs 1.4.88.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:34 fs 1.4.88.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:05 fs 1.4.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:15 fs 1.4.88.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:47 fs 1.4.88.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:06 fs 1.4.88.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
2005/10/05 07:07:28 fs 1.10.158.5: RESYNC: (1.10-1.11); FILE MERGED
2005/09/05 07:41:54 fs 1.10.158.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.10.158.3: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. 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/12 16:30:14 fs 1.10.158.2: - 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/09 14:00:06 fs 1.10.158.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
2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid
2005/10/31 13:45:59 fs 1.14.158.6: some cleanup
2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED
2005/09/05 07:41:53 fs 1.14.158.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. 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/12 16:30:14 fs 1.14.158.2: - 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/09 14:00:05 fs 1.14.158.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
2005/11/02 12:17:20 fs 1.3.88.13: #i10000# exception specifications
2005/11/02 11:43:45 fs 1.3.88.12: #i10000# exception specifications
2005/10/31 11:13:08 fs 1.3.88.11: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/25 07:13:14 fs 1.3.88.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:36 fs 1.3.88.9: #i53095# some cleanup of remaining TODOs
2005/10/13 13:01:09 fs 1.3.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:42 fs 1.3.88.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/10/05 07:07:01 fs 1.3.88.6: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:53 fs 1.3.88.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:34 fs 1.3.88.4: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. 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/12 16:30:14 fs 1.3.88.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:47 fs 1.3.88.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:05 fs 1.3.88.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/09 14:14:29 fs 1.4.88.15: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/11/02 12:17:19 fs 1.4.88.14: #i10000# exception specifications
2005/11/02 11:43:44 fs 1.4.88.13: #i10000# exception specifications
2005/10/31 11:13:08 fs 1.4.88.12: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/25 07:13:14 fs 1.4.88.11: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 14:09:35 fs 1.4.88.10: #i53095# some cleanup of remaining TODOs
2005/10/17 08:58:18 fs 1.4.88.9: some mutex locking
2005/10/13 13:01:09 fs 1.4.88.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:39 fs 1.4.88.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/10/05 07:06:45 fs 1.4.88.6: RESYNC: (1.4-1.5); FILE MERGED
2005/09/05 07:41:53 fs 1.4.88.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:33 fs 1.4.88.4: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. 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/12 16:30:14 fs 1.4.88.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:47 fs 1.4.88.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:05 fs 1.4.88.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/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:47 fs 1.27.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:04 fs 1.27.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006/03/09 14:31:15 fs 1.28.38.33: #i10000#
2006/03/09 14:14:29 fs 1.28.38.32: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2006/02/15 08:08:49 fs 1.28.38.31: properly remember/restore last selected page
2006/02/13 07:33:02 fs 1.28.38.30: #i10000#
2006/01/18 09:55:30 fs 1.28.38.29: implementation name of the PropertyBrowserController changed to ObjectInspector for better clarity
2005/12/20 10:54:43 fs 1.28.38.28: #i53095# new control type for editing hyperlinks
2005/12/19 12:21:17 fs 1.28.38.27: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/12/19 08:18:34 fs 1.28.38.26: dtor: acquire myself before doing anything else
2005/12/16 15:29:16 fs 1.28.38.25: activate first page only if there is one
2005/10/31 13:45:57 fs 1.28.38.24: some cleanup
2005/10/31 11:13:07 fs 1.28.38.23: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.28.38.22: some cleanups for finalizing #i53095#
2005/10/25 11:52:43 fs 1.28.38.21: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/25 07:13:14 fs 1.28.38.20: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:01 fs 1.28.38.19: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:00 fs 1.28.38.18: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:33 fs 1.28.38.17: #i53095# some cleanup of remaining TODOs
2005/10/17 12:20:17 fs 1.28.38.16: make StringListField exchange a sequence< string >
2005/10/17 08:58:18 fs 1.28.38.15: some mutex locking
2005/10/17 08:17:01 fs 1.28.38.14: #i53095#
2005/10/14 12:43:47 fs 1.28.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:02 fs 1.28.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:21 fs 1.28.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.28.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:08 fs 1.28.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:33 fs 1.28.38.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:06:23 fs 1.28.38.7: RESYNC: (1.28-1.29); FILE MERGED
2005/09/05 07:41:52 fs 1.28.38.6: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:33 fs 1.28.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.28.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.28.38.3: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/10 15:41:46 fs 1.28.38.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 14:00:04 fs 1.28.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2005/10/24 08:42:00 fs 1.3.16.1: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/25 07:13:13 fs 1.4.16.3: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:00 fs 1.4.16.2: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/13 13:01:08 fs 1.4.16.1: #i53095# introduce an XObjectInspector/Model
2006/03/10 09:43:34 fs 1.5.16.5: #i63001# also create reg info for SubmissionPropertyHandler
2005/12/19 12:21:42 fs 1.5.16.4: #i53095# +ObjectInspectorModel
2005/10/25 07:13:13 fs 1.5.16.3: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:59 fs 1.5.16.2: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/13 13:01:07 fs 1.5.16.1: #i53095# introduce an XObjectInspector/Model
2005/10/24 08:41:58 fs 1.1.2.4: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:18:59 fs 1.1.2.3: #i53095# some cleanup of remaining TODOs
2005/10/13 13:01:07 fs 1.1.2.2: #i53095# introduce an XObjectInspector/Model
2005/08/18 12:44:33 fs 1.1.2.1: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/10/24 08:41:58 fs 1.1.2.3: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/13 13:01:06 fs 1.1.2.2: #i53095# introduce an XObjectInspector/Model
2005/08/18 12:44:32 fs 1.1.2.1: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/10/13 13:01:06 fs 1.1.2.2: #i53095# introduce an XObjectInspector/Model
2005/08/18 12:44:32 fs 1.1.2.1: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/11/02 12:17:18 fs 1.3.158.14: #i10000# exception specifications
2005/10/26 14:03:33 fs 1.3.158.13: some cleanups for finalizing #i53095#
2005/10/25 11:52:43 fs 1.3.158.12: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/25 07:13:13 fs 1.3.158.11: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 10:28:00 fs 1.3.158.10: #i53095# make numeric field exchange its values as double
2005/10/17 07:17:05 fs 1.3.158.9: replace MeasurementUnit with css.util.MeasureUnit
2005/10/14 12:43:46 fs 1.3.158.8: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 08:40:43 fs 1.3.158.7: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:06 fs 1.3.158.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:28 fs 1.3.158.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 07:03:51 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:52 fs 1.3.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:55 fs 1.3.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/18 12:44:32 fs 1.3.158.1: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2006/03/07 09:57:08 fs 1.2.490.6: correct :getHelpId
2005/10/17 10:27:59 fs 1.2.490.5: #i53095# make numeric field exchange its values as double
2005/10/17 07:17:04 fs 1.2.490.4: replace MeasurementUnit with css.util.MeasureUnit
2005/10/14 12:43:46 fs 1.2.490.3: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 07:03:31 fs 1.2.490.2: RESYNC: (1.2-1.3); FILE MERGED
2005/09/05 07:41:52 fs 1.2.490.1: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2006/01/18 11:15:38 fs 1.1.2.3: no UnkwnonPropertyException in getPropertyOrderIndex, to ease implementations of this interface
2006/01/18 10:16:12 fs 1.1.2.2: no UnkwnonPropertyException in getPropertyOrderIndex, to ease implementations of this interface
2005/12/19 12:19:14 fs 1.1.2.1: a generic ObjectInspectorModel
2005/10/24 08:41:57 fs 1.3.16.1: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/24 08:41:57 fs 1.5.16.1: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/24 08:41:56 fs 1.6.16.1: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/12/19 12:20:10 fs 1.15.52.10: #i53095# +objectinspectormodel
2005/10/25 07:13:12 fs 1.15.52.9: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:55 fs 1.15.52.8: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/13 13:01:05 fs 1.15.52.7: #i53095# introduce an XObjectInspector/Model
2005/10/05 07:01:17 fs 1.15.52.6: RESYNC: (1.15-1.16); FILE MERGED
2005/09/26 09:06:16 fs 1.15.52.5: #i10000# some rearrangements
2005/09/05 07:41:52 fs 1.15.52.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.15.52.3: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. 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/12 16:30:12 fs 1.15.52.2: - 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/09 14:00:04 fs 1.15.52.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
2005/10/24 08:41:55 fs 1.3.16.1: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:05 fs 1.6.158.6: #i53095# knitting some loose ends
2005/10/14 12:43:46 fs 1.6.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:29:26 fs 1.6.158.4: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:59:46 fs 1.6.158.3: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:52 fs 1.6.158.2: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/09 14:00:03 fs 1.6.158.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
2005/10/17 13:19:02 fs 1.1.2.7: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:05 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:25 fs 1.1.2.5: #i53095# 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.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. 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/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:03 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
2005/10/24 08:41:54 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 13:19:01 fs 1.1.2.8: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/14 12:43:46 fs 1.1.2.7: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:04 fs 1.1.2.6: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:24 fs 1.1.2.5: #i53095# 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.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.3: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. 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/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:03 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
2005/12/19 12:19:52 fs 1.1.2.14: #i53095# extended implementation to work with an XIntrospectionAccess component
2005/11/02 12:17:17 fs 1.1.2.13: #i10000# exception specifications
2005/11/02 11:43:43 fs 1.1.2.12: #i10000# exception specifications
2005/10/25 12:09:28 fs 1.1.2.11: #i53095# cache the enum converters
2005/10/25 07:13:12 fs 1.1.2.10: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:53 fs 1.1.2.9: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:32 fs 1.1.2.8: #i53095# some cleanup of remaining TODOs
2005/10/13 13:01:04 fs 1.1.2.7: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:22 fs 1.1.2.6: #i53095# 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.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/18 12:44:31 fs 1.1.2.4: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. 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/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
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
2005/10/26 14:03:32 fs 1.29.38.4: some cleanups for finalizing #i53095#
2005/10/13 13:01:03 fs 1.29.38.3: #i53095# introduce an XObjectInspector/Model
2005/10/05 06:59:28 fs 1.29.38.2: RESYNC: (1.29-1.30); FILE MERGED
2005/08/09 14:00:01 fs 1.29.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2005/10/24 08:41:52 fs 1.26.38.7: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/11 13:29:18 fs 1.26.38.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:58:14 fs 1.26.38.5: RESYNC: (1.26-1.27); FILE MERGED
2005/09/05 07:41:51 fs 1.26.38.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the 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.26.38.3: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. 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/12 16:30:12 fs 1.26.38.2: - 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/09 14:00:01 fs 1.26.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2005/10/31 11:13:06 fs 1.33.38.7: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/24 08:41:52 fs 1.33.38.6: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/11 13:29:16 fs 1.33.38.5: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:58:01 fs 1.33.38.4: RESYNC: (1.33-1.34); FILE MERGED
2005/09/05 07:41:50 fs 1.33.38.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the 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.33.38.2: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. 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/09 14:00:00 fs 1.33.38.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2005/10/24 08:41:51 fs 1.4.96.3: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/05 06:56:33 fs 1.4.96.2: RESYNC: (1.4-1.6); FILE MERGED
2005/08/09 14:00:00 fs 1.4.96.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
2005/10/17 14:09:27 fs 1.14.206.3: #i53095# some cleanup of remaining TODOs
2005/10/05 06:56:21 fs 1.14.206.2: RESYNC: (1.14-1.15); FILE MERGED
2005/08/18 12:44:29 fs 1.14.206.1: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/10/24 08:41:50 fs 1.1.2.3: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/14 10:48:02 fs 1.1.2.2: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/13 13:00:30 fs 1.1.2.1: #i53095# (slightly) specialized version of the ObjectInspector which does the legacy implementation of css.form.PropertyBrowserController
2006/02/10 08:30:34 fs 1.85.88.14: RESYNC: (1.87-1.88); FILE MERGED
2005/11/01 11:09:46 fs 1.85.88.13: RESYNC: (1.85-1.87); FILE MERGED
2005/10/26 14:49:35 fs 1.85.88.12: #i53095#
2005/10/25 07:13:11 fs 1.85.88.11: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:49 fs 1.85.88.10: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:22 fs 1.85.88.9: #i53095# some cleanup of remaining TODOs
2005/10/14 10:48:00 fs 1.85.88.8: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/13 13:00:29 fs 1.85.88.7: #i53095# (slightly) specialized version of the ObjectInspector which does the legacy implementation of css.form.PropertyBrowserController
2005/09/05 07:41:50 fs 1.85.88.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:29 fs 1.85.88.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:02 fs 1.85.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:11 fs 1.85.88.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:45 fs 1.85.88.2: #i53095#
get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked,
and move them to a FormComponentHandler
[1] still to migrate:
- browsing for events (needs a dedicated event property handler)
- handling for clicking the button of the Command property - this
is kind of asynchronous, and IPropertyHandler is not yet prepared for this
2005/08/09 13:59:59 fs 1.85.88.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/09 13:22:52 fs 1.1.2.15: #i62965# release own mutex before executing a modal dialog
2005/11/02 11:43:42 fs 1.1.2.14: #i10000# exception specifications
2005/10/31 13:45:57 fs 1.1.2.13: some cleanup
2005/10/25 07:13:10 fs 1.1.2.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:48 fs 1.1.2.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:21 fs 1.1.2.10: #i53095# some cleanup of remaining TODOs
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:03 fs 1.1.2.8: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:15 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:49 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:28 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:01 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:11 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:45 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 13:59:59 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/09 13:22:52 fs 1.1.2.33: #i62965# release own mutex before executing a modal dialog
2006/03/08 10:12:20 fs 1.1.2.32: varname typo
2006/03/07 20:01:33 fs 1.1.2.31: properly en/disable TARGET_FRAME, also for forms
2006/02/15 07:25:53 fs 1.1.2.30: don't access &(*foo.begin()) of empty STL containers
2006/02/10 07:53:48 fs 1.1.2.29: manual RESYNC to m156
2005/11/02 12:17:16 fs 1.1.2.28: #i10000# exception specifications
2005/11/02 11:43:42 fs 1.1.2.27: #i10000# exception specifications
2005/10/31 13:45:57 fs 1.1.2.26: some cleanup
2005/10/26 14:49:34 fs 1.1.2.25: #i53095#
2005/10/26 14:03:32 fs 1.1.2.24: some cleanups for finalizing #i53095#
2005/10/25 12:23:00 fs 1.1.2.23: misc cleanup
2005/10/25 11:52:41 fs 1.1.2.22: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/25 07:13:10 fs 1.1.2.21: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:41:47 fs 1.1.2.20: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:19 fs 1.1.2.19: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:00 fs 1.1.2.18: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 10:27:59 fs 1.1.2.17: #i53095# make numeric field exchange its values as double
2005/10/17 09:48:36 fs 1.1.2.16: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:17 fs 1.1.2.15: some mutex locking
2005/10/17 08:38:37 fs 1.1.2.14: implement auto-firing for ComposedUIUpdate
2005/10/17 08:17:00 fs 1.1.2.13: #i53095#
2005/10/17 07:17:03 fs 1.1.2.12: replace MeasurementUnit with css.util.MeasureUnit
2005/10/14 12:43:45 fs 1.1.2.11: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 08:40:43 fs 1.1.2.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:02 fs 1.1.2.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:13 fs 1.1.2.8: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/07 12:25:14 fs 1.1.2.7: #i53095# also set the HasFooButton properties at the descriptor
2005/09/05 07:41:49 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:28 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:00 fs 1.1.2.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:10 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:44 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 13:59:59 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
2005/10/31 11:13:06 fs 1.3.158.3: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/05 06:56:08 fs 1.3.158.2: RESYNC: (1.3-1.4); FILE MERGED
2005/08/09 13:59:58 fs 1.3.158.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
Vladimir Glazounov