2001-01-12 10:35:45 +00:00
|
|
|
/*************************************************************************
|
|
|
|
|
*
|
2005-09-08 19:03:03 +00:00
|
|
|
* OpenOffice.org - a multi-platform office productivity suite
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2005-09-08 19:03:03 +00:00
|
|
|
* $RCSfile: browserlistbox.hxx,v $
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
* $Revision: 1.8 $
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
* last change: $Author: vg $ $Date: 2006-03-14 11:17:37 $
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2005-09-08 19:03:03 +00:00
|
|
|
* The Contents of this file are made available subject to
|
|
|
|
|
* the terms of GNU Lesser General Public License Version 2.1.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
|
|
|
|
*
|
2005-09-08 19:03:03 +00:00
|
|
|
* GNU Lesser General Public License Version 2.1
|
|
|
|
|
* =============================================
|
|
|
|
|
* Copyright 2005 by Sun Microsystems, Inc.
|
|
|
|
|
* 901 San Antonio Road, Palo Alto, CA 94303, USA
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2005-09-08 19:03:03 +00:00
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
|
* License version 2.1, as published by the Free Software Foundation.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2005-09-08 19:03:03 +00:00
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
|
* Lesser General Public License for more details.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2005-09-08 19:03:03 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
|
* License along with this library; if not, write to the Free Software
|
|
|
|
|
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
|
|
|
|
|
* MA 02111-1307 USA
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
|
|
|
|
************************************************************************/
|
|
|
|
|
|
|
|
|
|
#ifndef _EXTENSIONS_PROPCTRLR_BROWSERLISTBOX_HXX_
|
|
|
|
|
#define _EXTENSIONS_PROPCTRLR_BROWSERLISTBOX_HXX_
|
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
#ifndef _EXTENSIONS_PROPCTRLR_BROWSERLINE_HXX_
|
|
|
|
|
#include "browserline.hxx"
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef _EXTENSIONS_PROPCTRLR_MODULEPRC_HXX_
|
|
|
|
|
#include "modulepcr.hxx"
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef _EXTENSIONS_PROPCTRLR_PCRCOMMON_HXX_
|
|
|
|
|
#include "pcrcommon.hxx"
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/** === begin UNO includes === **/
|
|
|
|
|
#ifndef _COM_SUN_STAR_INSPECTION_XPROPERTYCONTROL_HPP_
|
|
|
|
|
#include <com/sun/star/inspection/XPropertyControl.hpp>
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef _COM_SUN_STAR_INSPECTION_XPROPERTYHANDLER_HPP_
|
|
|
|
|
#include <com/sun/star/inspection/XPropertyHandler.hpp>
|
|
|
|
|
#endif
|
|
|
|
|
/** === end UNO includes === **/
|
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
#ifndef _SV_SCRBAR_HXX
|
|
|
|
|
#include <vcl/scrbar.hxx>
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef _SV_LSTBOX_HXX
|
|
|
|
|
#include <vcl/lstbox.hxx>
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef _SV_BUTTON_HXX
|
|
|
|
|
#include <vcl/button.hxx>
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef _LINK_HXX
|
|
|
|
|
#include <tools/link.hxx>
|
|
|
|
|
#endif
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
#ifndef _RTL_REF_HXX_
|
|
|
|
|
#include <rtl/ref.hxx>
|
2001-01-12 10:35:45 +00:00
|
|
|
#endif
|
|
|
|
|
|
2004-11-16 11:01:00 +00:00
|
|
|
#include <set>
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
#include <vector>
|
|
|
|
|
#include <hash_map>
|
|
|
|
|
#include <boost/shared_ptr.hpp>
|
2004-11-16 11:01:00 +00:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//............................................................................
|
|
|
|
|
namespace pcr
|
|
|
|
|
{
|
|
|
|
|
//............................................................................
|
|
|
|
|
|
|
|
|
|
class IPropertyLineListener;
|
|
|
|
|
struct OLineDescriptor;
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
class PropertyControlContext_Impl;
|
|
|
|
|
|
|
|
|
|
//========================================================================
|
|
|
|
|
//= administrative structures for OBrowserListBox
|
|
|
|
|
//========================================================================
|
|
|
|
|
typedef ::boost::shared_ptr< OBrowserLine > BrowserLinePointer;
|
|
|
|
|
struct ListBoxLine
|
|
|
|
|
{
|
|
|
|
|
BrowserLinePointer pLine;
|
|
|
|
|
::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyHandler >
|
|
|
|
|
xHandler;
|
|
|
|
|
|
|
|
|
|
ListBoxLine() { }
|
|
|
|
|
ListBoxLine( BrowserLinePointer _pLine, const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyHandler >& _rxHandler )
|
|
|
|
|
:pLine( _pLine )
|
|
|
|
|
,xHandler( _rxHandler )
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
typedef ::std::hash_map< ::rtl::OUString, ListBoxLine, ::rtl::OUStringHash > ListBoxLines;
|
|
|
|
|
typedef ::std::vector< ListBoxLines::iterator > OrderedListBoxLines;
|
|
|
|
|
|
|
|
|
|
//========================================================================
|
|
|
|
|
//= IControlContext
|
|
|
|
|
//========================================================================
|
|
|
|
|
/** non-UNO version of XPropertyControlContext
|
|
|
|
|
*/
|
|
|
|
|
class SAL_NO_VTABLE IControlContext
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
virtual void SAL_CALL focusGained( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& Control ) throw (::com::sun::star::uno::RuntimeException) = 0;
|
|
|
|
|
virtual void SAL_CALL controlValueChanged( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& Control ) throw (::com::sun::star::uno::RuntimeException) = 0;
|
|
|
|
|
virtual void SAL_CALL activateNextControl( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& CurrentControl ) throw (::com::sun::star::uno::RuntimeException) = 0;
|
|
|
|
|
};
|
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//========================================================================
|
|
|
|
|
//= OBrowserListBox
|
|
|
|
|
//========================================================================
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
class OBrowserListBox :public Control
|
|
|
|
|
,public IButtonClickListener
|
|
|
|
|
,public IControlContext
|
|
|
|
|
,public PcrClient
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
|
|
|
|
protected:
|
|
|
|
|
Window m_aPlayGround;
|
|
|
|
|
ScrollBar m_aVScroll;
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
ListBoxLines m_aLines;
|
|
|
|
|
OrderedListBoxLines m_aOrderedLines;
|
2001-01-12 10:35:45 +00:00
|
|
|
IPropertyLineListener* m_pLineListener;
|
|
|
|
|
long m_nYOffset;
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >
|
|
|
|
|
m_xActiveControl;
|
2001-01-12 10:35:45 +00:00
|
|
|
sal_uInt16 m_nTheNameSize;
|
|
|
|
|
sal_uInt16 m_nRowHeight;
|
2004-11-16 11:01:00 +00:00
|
|
|
::std::set< sal_uInt16 > m_aOutOfDateLines;
|
2003-03-25 15:04:55 +00:00
|
|
|
sal_Bool m_bIsActive : 1;
|
2001-01-12 10:35:45 +00:00
|
|
|
sal_Bool m_bUpdate : 1;
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
::rtl::Reference< PropertyControlContext_Impl >
|
|
|
|
|
m_pControlContextImpl;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
|
protected:
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
void PositionLine( sal_uInt16 _nIndex );
|
|
|
|
|
void UpdatePosNSize();
|
|
|
|
|
void UpdatePlayGround();
|
|
|
|
|
void UpdateVScroll();
|
|
|
|
|
void ShowEntry(sal_uInt16 nPos);
|
|
|
|
|
void MoveThumbTo(long nNewThumbPos);
|
|
|
|
|
void Resize();
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
|
public:
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
OBrowserListBox( Window* pParent, WinBits nWinStyle = WB_DIALOGCONTROL );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
~OBrowserListBox();
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
void UpdateAll();
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
void Activate(sal_Bool _bActive = sal_True);
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
sal_uInt16 CalcVisibleLines();
|
|
|
|
|
void EnableUpdate();
|
|
|
|
|
void DisableUpdate();
|
|
|
|
|
long Notify( NotifyEvent& _rNEvt );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
void setListener(IPropertyLineListener* _pPLL);
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
void Clear();
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
sal_uInt16 InsertEntry( const OLineDescriptor&, sal_uInt16 nPos = EDITOR_LIST_APPEND );
|
|
|
|
|
sal_Bool RemoveEntry( const ::rtl::OUString& _rName );
|
|
|
|
|
void ChangeEntry( const OLineDescriptor&, sal_uInt16 nPos );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
void SetPropertyValue( const ::rtl::OUString& rEntryName, const ::com::sun::star::uno::Any& rValue );
|
|
|
|
|
::com::sun::star::uno::Any GetPropertyValue( const ::rtl::OUString& rEntryName ) const;
|
|
|
|
|
sal_uInt16 GetPropertyPos( const ::rtl::OUString& rEntryName ) const;
|
|
|
|
|
::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >
|
|
|
|
|
GetPropertyControl( const ::rtl::OUString& rEntryName );
|
|
|
|
|
void EnablePropertyControls( const ::rtl::OUString& _rEntryName, sal_Int16 _nControls, bool _bEnable );
|
|
|
|
|
void EnablePropertyLine( const ::rtl::OUString& _rEntryName, bool _bEnable );
|
|
|
|
|
sal_Bool IsPropertyInputEnabled( const ::rtl::OUString& _rEntryName ) const;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
// #95343# --------------------------
|
|
|
|
|
sal_Int32 GetMinimumWidth();
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2002-11-06 08:20:07 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
sal_Bool IsModified( ) const;
|
|
|
|
|
void CommitModified( );
|
2002-11-06 08:20:07 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
protected:
|
|
|
|
|
// IControlContext
|
|
|
|
|
virtual void SAL_CALL focusGained( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& Control ) throw (::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual void SAL_CALL controlValueChanged( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& Control ) throw (::com::sun::star::uno::RuntimeException);
|
|
|
|
|
virtual void SAL_CALL activateNextControl( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& CurrentControl ) throw (::com::sun::star::uno::RuntimeException);
|
2003-03-25 15:04:55 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
// IButtonClickListener
|
|
|
|
|
void buttonClicked( OBrowserLine* _pLine, sal_Bool _bPrimary );
|
2003-03-25 15:04:55 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
private:
|
2001-01-12 10:35:45 +00:00
|
|
|
DECL_LINK( ScrollHdl, ScrollBar* );
|
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED
2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/11 13:28:46 fs 1.6.156.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:19 fs 1.6.156.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:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:47 fs 1.6.156.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:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.156.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.6.156.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.6.156.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-14 10:17:37 +00:00
|
|
|
/** retrieves the index of a given control in our line list
|
|
|
|
|
@param _rxControl
|
|
|
|
|
The control to lookup. Must denote a control of one of the lines in ->m_aLines
|
|
|
|
|
*/
|
|
|
|
|
sal_uInt16 impl_getControlPos( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& _rxControl ) const;
|
|
|
|
|
|
|
|
|
|
/** retrieves (a reference to) the ->ListBoxLine for a given control
|
|
|
|
|
@param _rxControl
|
|
|
|
|
The control to lookup. Must denote a control of one of the lines in ->m_aLines
|
|
|
|
|
*/
|
|
|
|
|
inline const ListBoxLine&
|
|
|
|
|
impl_getControlLine( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& _rxControl ) const
|
|
|
|
|
{
|
|
|
|
|
return m_aOrderedLines[ impl_getControlPos( _rxControl ) ]->second;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** sets the given property value at the given control, after converting it as necessary
|
|
|
|
|
@param _rLine
|
|
|
|
|
The line whose at which the value is to be set.
|
|
|
|
|
@param _rPropertyValue
|
|
|
|
|
the property value to set. If it's not compatible with the control value,
|
|
|
|
|
it will be converted, using <member>XPropertyHandler::convertToControlValue</member>
|
|
|
|
|
*/
|
|
|
|
|
void impl_setControlAsPropertyValue( const ListBoxLine& _rLine, const ::com::sun::star::uno::Any& _rPropertyValue );
|
|
|
|
|
|
|
|
|
|
/** retrieves the value for the given control, as a property value, after converting it as necessary
|
|
|
|
|
@param _rLine
|
|
|
|
|
The line whose at which the value is to be set.
|
|
|
|
|
*/
|
|
|
|
|
::com::sun::star::uno::Any
|
|
|
|
|
impl_getControlAsPropertyValue( const ListBoxLine& _rLine ) const;
|
|
|
|
|
|
|
|
|
|
/** retrieves the ->BrowserLinePointer for a given entry name
|
|
|
|
|
@param _rEntryName
|
|
|
|
|
the name whose line is to be looked up
|
|
|
|
|
@param _out_rpLine
|
|
|
|
|
contains, upon return, the found browser line, if any
|
|
|
|
|
@return
|
|
|
|
|
<TRUE/> if and only if a non-<NULL/> line for the given entry name could be
|
|
|
|
|
found.
|
|
|
|
|
*/
|
|
|
|
|
bool impl_getBrowserLineForName( const ::rtl::OUString& _rEntryName, BrowserLinePointer& _out_rpLine ) const;
|
2001-01-12 10:35:45 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
//............................................................................
|
|
|
|
|
} // namespace pcr
|
|
|
|
|
//............................................................................
|
|
|
|
|
|
|
|
|
|
#endif // _EXTENSIONS_PROPCTRLR_BROWSERLISTBOX_HXX_
|
|
|
|
|
|
|
|
|
|
|