2006/11/23 12:17:30 fs 1.7.32.2: getSupersededProperties not needed anymore, after the previous fix
2006/11/23 12:06:25 fs 1.7.32.1: #i70109#
- removed the ActionButtonType property, ButtonNavigationHandler now again
working with ButtonType
- as a consequence, it's now defined that if a handler supersedes a property,
then all handlers which previously registered for changes of this
property (getActuatingProperties) will not be notified anymore. Reasoning
is that the new handler could given the property a new semantics, type,
whatever, which the previous handlers would not expect.
2006/02/15 07:25:51 fs 1.3.130.12: don't access &(*foo.begin()) of empty STL containers
2005/11/02 11:43:36 fs 1.3.130.11: #i10000# exception specifications
2005/10/25 11:52:39 fs 1.3.130.10: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/25 07:13:05 fs 1.3.130.9: #i53095# knitting lose ends (amongst others, make the handlers available as service)
2005/10/17 08:58:14 fs 1.3.130.8: some mutex locking
2005/10/13 13:00:57 fs 1.3.130.7: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:28:48 fs 1.3.130.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:50:45 fs 1.3.130.5: RESYNC: (1.3-1.4); FILE MERGED
2005/08/18 12:44:26 fs 1.3.130.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/16 05:38:55 fs 1.3.130.3: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/10 15:41:43 fs 1.3.130.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:55 fs 1.3.130.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
2004/07/22 09:04:43 fs 1.1.2.5: #i31762# split 'onBrowseButtonClicked' into 'requestUserInputOnButtonClick' and 'executeButtonClick', to allow composition of property handlers (request only once, but execute for every single handler in the composition)
2004/07/20 12:11:35 fs 1.1.2.4: in preparation of #i31762#: ensure that property handlers silently accept introspectees which they don't have properties for
2004/07/15 07:41:02 fs 1.1.2.3: #114856# cache supported properties
2004/07/12 14:26:19 fs 1.1.2.2: #114856#
2004/06/29 15:06:03 fs 1.1.2.1: initial checkin - manual resync of CWS eforms2, the code herein was originally introduced on the master
