2006/03/22 07:48:14 fs 1.1.2.4: UILocale instead of SysLocale, if default locale is required
2006/03/17 13:01:04 fs 1.1.2.3: proper base name
2006/03/17 12:33:58 fs 1.1.2.2: changed singleton name
2006/03/17 11:12:36 fs 1.1.2.1: implementation of css.resource.OpenOfficeResourceLoader
2006/03/08 12:14:47 fs 1.46.4.1: read/write: don't do the translation to/from SO5.x-compatible service names anymore. Nowadays,
this code is not used anymore for writing this file format (this is in the dedicated "binfilter"
module), so it's unnecessary. Also, it caused some strange problems like the deadlock described
in issue #i61444#.
(Yes, removing this part fixes a symptom only, but I was unable to figure out the deeper reason
with a reasonable effort.)
2006/02/22 15:22:03 fs 1.2.204.1: in the course of #i62418#: check boxes and radio buttons exchange their validatable value as boolean, if no external binding is set
2006/03/14 16:59:44 mav 1.24.4.2: #i59886# there might be no common password
2006/02/27 15:51:11 mav 1.24.4.1: #i59886# copy the encrypted stream correctly
2006/03/09 13:31:53 mav 1.8.50.2: RESYNC: (1.8-1.9); FILE MERGED
2006/02/27 08:14:54 mav 1.8.50.1: #i57734# do not do the checks that should be done by installation
2005/11/02 11:43:48 fs 1.3.88.13: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.12: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:11 fs 1.3.88.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:42 fs 1.3.88.10: #i53095# some cleanup of remaining TODOs
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:30:01 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:16:22 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 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:36 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:09 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 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:48 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:10 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/13 07:35:15 fs 1.3.88.21: more help ids
2006/03/09 14:16:41 fs 1.3.88.20: Has*Button must be set, too, not only the images
2006/02/15 07:25:56 fs 1.3.88.19: don't access &(*foo.begin()) of empty STL containers
2005/11/02 12:17:22 fs 1.3.88.18: #i10000# exception specifications
2005/11/02 11:43:48 fs 1.3.88.17: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.16: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:10 fs 1.3.88.15: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:09:40 fs 1.3.88.14: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:06 fs 1.3.88.13: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/17 09:48:45 fs 1.3.88.12: #i53095# make DateFields and TimeFields exchange their values as css.util.Date/Time
2005/10/17 08:58:21 fs 1.3.88.11: some mutex locking
2005/10/14 12:43:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:58 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:16:07 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 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:36 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:08 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 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:48 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:09 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
2005/10/17 13:19:05 fs 1.3.88.3: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/05 07:15:29 fs 1.3.88.2: RESYNC: (1.3-1.4); FILE MERGED
2005/08/09 14:00:09 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
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.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:09 fs 1.3.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/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.294.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:09 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/10/24 08:42:10 fs 1.6.2.1: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/24 08:42:09 fs 1.5.16.1: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/11/02 11:43:47 fs 1.3.88.15: #i10000# exception specifications
2005/10/25 07:13:16 fs 1.3.88.14: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/24 08:42:08 fs 1.3.88.13: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 08:48:44 fs 1.3.88.12: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:40 fs 1.3.88.11: #i53095# some cleanup of remaining TODOs
2005/10/17 13:19:04 fs 1.3.88.10: #i53095# proper listener administration: allow multiple listeners per handler
2005/10/13 13:01:12 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:55 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:12:49 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 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:36 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:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 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:48 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:08 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/10 11:32:29 fs 1.3.88.19: help ids
2006/03/10 09:43:46 fs 1.3.88.18: proper enum types
2006/02/15 07:25:55 fs 1.3.88.17: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:47 fs 1.3.88.16: #i10000# exception specifications
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/19 08:48:43 fs 1.3.88.14: protect agains multiple inspection (more precise: properly deal with it)
2005/10/17 14:09:39 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:50 fs 1.3.88.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/13 13:01:11 fs 1.3.88.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:53 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:12:16 fs 1.3.88.7: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:55 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:07 fs 1.3.88.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:16 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:48 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:08 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
2005/12/19 12:22:19 fs 1.3.88.6: #i53095# also allow for BYTE sequences
2005/10/24 08:42:07 fs 1.3.88.5: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 12:20:20 fs 1.3.88.4: make StringListField exchange a sequence< string >
2005/10/05 07:11:39 fs 1.3.88.3: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:35 fs 1.3.88.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:08 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/02/10 11:52:35 fs 1.5.158.10: NullPointerException is unusual at addFooListener methods
2005/12/20 10:54:54 fs 1.5.158.9: #i53095# new control type for editing hyperlinks
2005/10/19 07:48:06 fs 1.5.158.8: #i53095# knitting some loose ends
2005/10/17 12:20:19 fs 1.5.158.7: make StringListField exchange a sequence< string >
2005/10/17 10:28:01 fs 1.5.158.6: #i53095# make numeric field exchange its values as double
2005/10/17 07:17:06 fs 1.5.158.5: replace MeasurementUnit with css.util.MeasureUnit
2005/10/14 12:43:49 fs 1.5.158.4: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 07:10:54 fs 1.5.158.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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:07 fs 1.5.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
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.*
