2006/05/23 15:50:08 sb 1.20.12.2: RESYNC: (1.20-1.21); FILE MERGED
2006/05/12 16:29:54 sb 1.20.12.1: #i53898# Made code warning-free and/or compile at all after resync to SRC680m162.
2006/04/20 07:47:38 fs 1.2.12.3: #i64196# use FormController as secondary component only if it's really a form
2006/04/20 07:17:03 fs 1.2.12.2: proper fix for #ii64511#: XRowSetListener is in sdbc, not sdb
2006/04/19 13:33:11 fs 1.2.12.1: #i64511# proper event name in AddEvent call
2006/03/29 11:48:57 sb 1.3.114.1: #i61729# Decode LDAP string value using UTF8 instead of ASCII_US; plus some cleanup of strange, obviously broken code.
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
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
