INTEGRATION: CWS pbrwuno (1.12.136); FILE MERGED 2005/12/20 10:53:49 fs 1.12.136.13: removed unnecessary include 2005/11/02 12:17:14 fs 1.12.136.12: #i10000# exception specifications 2005/10/19 08:30:03 fs 1.12.136.11: make IEventProcessor ref-counted 2005/10/14 12:43:43 fs 1.12.136.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/14 08:40:42 fs 1.12.136.9: #i53095# let the XObjectInspectorModel provide category meta information part 2005/10/11 13:28:44 fs 1.12.136.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:24:17 fs 1.12.136.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:08 fs 1.12.136.6: RESYNC: (1.12-1.13); FILE MERGED 2005/09/05 07:41:46 fs 1.12.136.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/31 08:28:53 fs 1.12.136.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.12.136.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:42 fs 1.12.136.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler
INTEGRATION: CWS pbrwuno (1.12.136); FILE MERGED
2005/12/20 10:53:49 fs 1.12.136.13: removed unnecessary include
2005/11/02 12:17:14 fs 1.12.136.12: #i10000# exception specifications
2005/10/19 08:30:03 fs 1.12.136.11: make IEventProcessor ref-counted
2005/10/14 12:43:43 fs 1.12.136.10: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 08:40:42 fs 1.12.136.9: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/11 13:28:44 fs 1.12.136.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:24:17 fs 1.12.136.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows
2005/10/05 06:49:08 fs 1.12.136.6: RESYNC: (1.12-1.13); FILE MERGED
2005/09/05 07:41:46 fs 1.12.136.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/31 08:28:53 fs 1.12.136.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.12.136.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:42 fs 1.12.136.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:54 fs 1.12.136.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

JurassicWordExcel/core,JurassicWordExcel/core,JurassicWordExcel/core,JurassicWordExcel/core,JurassicWordExcel/core,JurassicWordExcel/core,JurassicWordExcel/core,JurassicWordExcel/core,JurassicWordExcel/core,JurassicWordExcel/core