2001-01-12 10:35:45 +00:00
|
|
|
/*************************************************************************
|
|
|
|
*
|
2005-09-08 19:07:32 +00:00
|
|
|
* OpenOffice.org - a multi-platform office productivity suite
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2005-09-08 19:07:32 +00:00
|
|
|
* $RCSfile: commoncontrol.cxx,v $
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2006-09-16 12:14:43 +00:00
|
|
|
* $Revision: 1.7 $
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2006-09-16 12:14:43 +00:00
|
|
|
* last change: $Author: obo $ $Date: 2006-09-16 13:14:43 $
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2005-09-08 19:07:32 +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:07:32 +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:07:32 +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:07:32 +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:07:32 +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
|
|
|
*
|
|
|
|
************************************************************************/
|
|
|
|
|
2006-09-16 12:14:43 +00:00
|
|
|
// MARKER(update_precomp.py): autogen include statement, do not remove
|
|
|
|
#include "precompiled_extensions.hxx"
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
#ifndef _EXTENSIONS_PROPCTRLR_COMMONCONTROL_HXX_
|
|
|
|
#include "commoncontrol.hxx"
|
|
|
|
#endif
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
#ifndef _EXTENSIONS_PROPCTRLR_PCRCOMMON_HXX_
|
|
|
|
#include "pcrcommon.hxx"
|
|
|
|
#endif
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
#ifndef _TOOLS_DEBUG_HXX
|
|
|
|
#include <tools/debug.hxx>
|
|
|
|
#endif
|
|
|
|
#ifndef _SV_COMBOBOX_HXX
|
|
|
|
#include <vcl/combobox.hxx>
|
|
|
|
#endif
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
#ifndef _TOOLKIT_HELPER_VCLUNOHELPER_HXX_
|
|
|
|
#include <toolkit/helper/vclunohelper.hxx>
|
|
|
|
#endif
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
//............................................................................
|
|
|
|
namespace pcr
|
|
|
|
{
|
|
|
|
//............................................................................
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
|
|
|
|
/** === begin UNO using === **/
|
|
|
|
using ::com::sun::star::uno::RuntimeException;
|
|
|
|
using ::com::sun::star::uno::Reference;
|
|
|
|
using ::com::sun::star::inspection::XPropertyControlContext;
|
|
|
|
using ::com::sun::star::awt::XWindow;
|
|
|
|
using ::com::sun::star::uno::Exception;
|
|
|
|
using ::com::sun::star::inspection::XPropertyControl;
|
|
|
|
/** === end UNO using === **/
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//==================================================================
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
//= ControlHelper
|
2001-01-12 10:35:45 +00:00
|
|
|
//==================================================================
|
|
|
|
//------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
ControlHelper::ControlHelper( Window* _pControlWindow, sal_Int16 _nControlType, XPropertyControl& _rAntiImpl, IModifyListener* _pModifyListener )
|
|
|
|
:m_pControlWindow( _pControlWindow )
|
|
|
|
,m_nControlType( _nControlType )
|
|
|
|
,m_rAntiImpl( _rAntiImpl )
|
|
|
|
,m_pModifyListener( _pModifyListener )
|
|
|
|
,m_bModified( sal_False )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
DBG_ASSERT( m_pControlWindow != NULL, "ControlHelper::ControlHelper: invalid window!" );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2006-07-26 06:54:32 +00:00
|
|
|
//------------------------------------------------------------------
|
|
|
|
ControlHelper::~ControlHelper()
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
//--------------------------------------------------------------------
|
|
|
|
::sal_Int16 SAL_CALL ControlHelper::getControlType() throw (RuntimeException)
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
return m_nControlType;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
//--------------------------------------------------------------------
|
|
|
|
Reference< XPropertyControlContext > SAL_CALL ControlHelper::getControlContext() throw (RuntimeException)
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
return m_xContext;
|
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
//--------------------------------------------------------------------
|
|
|
|
void SAL_CALL ControlHelper::setControlContext( const Reference< XPropertyControlContext >& _controlcontext ) throw (RuntimeException)
|
|
|
|
{
|
|
|
|
m_xContext = _controlcontext;
|
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
Reference< XWindow > SAL_CALL ControlHelper::getControlWindow() throw (RuntimeException)
|
|
|
|
{
|
|
|
|
return VCLUnoHelper::GetInterface( m_pControlWindow );
|
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
::sal_Bool SAL_CALL ControlHelper::isModified( ) throw (RuntimeException)
|
|
|
|
{
|
|
|
|
return m_bModified;
|
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
void SAL_CALL ControlHelper::notifyModifiedValue( ) throw (RuntimeException)
|
|
|
|
{
|
|
|
|
if ( isModified() && m_xContext.is() )
|
|
|
|
{
|
|
|
|
try
|
|
|
|
{
|
|
|
|
m_xContext->controlValueChanged( &m_rAntiImpl );
|
|
|
|
m_bModified = sal_False;
|
|
|
|
}
|
|
|
|
catch( const Exception& e )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
#if OSL_DEBUG_LEVEL > 0
|
|
|
|
::rtl::OString sMessage( "ControlHelper::notifyModifiedValue: caught an exception!\n" );
|
|
|
|
sMessage += "message:\n";
|
|
|
|
sMessage += ::rtl::OString( e.Message.getStr(), e.Message.getLength(), osl_getThreadTextEncoding() );
|
|
|
|
OSL_ENSURE( false, sMessage );
|
|
|
|
#else
|
|
|
|
e; // make compiler happy
|
|
|
|
#endif
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
void SAL_CALL ControlHelper::dispose()
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
DELETEZ( m_pControlWindow );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
void ControlHelper::autoSizeWindow()
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
OSL_PRECOND( m_pControlWindow, "ControlHelper::autoSizeWindow: no window!" );
|
|
|
|
if ( !m_pControlWindow )
|
|
|
|
return;
|
|
|
|
|
|
|
|
ComboBox aComboBox(m_pControlWindow, WB_DROPDOWN);
|
|
|
|
aComboBox.SetPosSizePixel(Point(0,0), Size(100,100));
|
|
|
|
m_pControlWindow->SetSizePixel(aComboBox.GetSizePixel());
|
|
|
|
|
|
|
|
// TODO/UNOize: why do the controls this themselves? Shouldn't this be the task
|
|
|
|
// of the the browser listbox/line?
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
void ControlHelper::impl_activateNextControl_nothrow() const
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
try
|
|
|
|
{
|
|
|
|
if ( m_xContext.is() )
|
|
|
|
m_xContext->activateNextControl( const_cast< XPropertyControl* >( &m_rAntiImpl ) );
|
|
|
|
}
|
|
|
|
catch( const Exception& e )
|
|
|
|
{
|
|
|
|
#if OSL_DEBUG_LEVEL > 0
|
|
|
|
::rtl::OString sMessage( "ControlHelper::impl_activateNextControl_nothrow: caught an exception!\n" );
|
|
|
|
sMessage += "message:\n";
|
|
|
|
sMessage += ::rtl::OString( e.Message.getStr(), e.Message.getLength(), osl_getThreadTextEncoding() );
|
|
|
|
OSL_ENSURE( false, sMessage );
|
|
|
|
#else
|
|
|
|
e; // make compiler happy
|
|
|
|
#endif
|
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
bool ControlHelper::handlePreNotify(NotifyEvent& rNEvt)
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
if (EVENT_KEYINPUT == rNEvt.GetType())
|
|
|
|
{
|
|
|
|
const KeyCode& aKeyCode = rNEvt.GetKeyEvent()->GetKeyCode();
|
|
|
|
sal_uInt16 nKey = aKeyCode.GetCode();
|
|
|
|
|
|
|
|
if (nKey == KEY_RETURN && !aKeyCode.IsShift())
|
|
|
|
{
|
|
|
|
LoseFocusHdl(m_pControlWindow);
|
|
|
|
impl_activateNextControl_nothrow();
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return false;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
2006-07-26 06:54:32 +00:00
|
|
|
IMPL_LINK( ControlHelper, ModifiedHdl, Window*, /*_pWin*/ )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
if ( m_pModifyListener )
|
|
|
|
m_pModifyListener->modified();
|
2001-01-12 10:35:45 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
2006-07-26 06:54:32 +00:00
|
|
|
IMPL_LINK( ControlHelper, GetFocusHdl, Window*, /*_pWin*/ )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
try
|
|
|
|
{
|
|
|
|
if ( m_xContext.is() )
|
|
|
|
m_xContext->focusGained( &m_rAntiImpl );
|
|
|
|
}
|
|
|
|
catch( const Exception& e )
|
|
|
|
{
|
|
|
|
#if OSL_DEBUG_LEVEL > 0
|
|
|
|
::rtl::OString sMessage( "ControlHelper, GetFocusHdl: caught an exception!\n" );
|
|
|
|
sMessage += "message:\n";
|
|
|
|
sMessage += ::rtl::OString( e.Message.getStr(), e.Message.getLength(), osl_getThreadTextEncoding() );
|
|
|
|
OSL_ENSURE( false, sMessage );
|
|
|
|
#else
|
|
|
|
e; // make compiler happy
|
|
|
|
#endif
|
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
2006-07-26 06:54:32 +00:00
|
|
|
IMPL_LINK( ControlHelper, LoseFocusHdl, Window*, /*_pWin*/ )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.158); FILE MERGED
2005/10/14 12:43:44 fs 1.3.158.5: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:13 fs 1.3.158.4: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:47 fs 1.3.158.3: #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/10 15:41:43 fs 1.3.158.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:56 fs 1.3.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:23 +00:00
|
|
|
// TODO/UNOize: should this be outside the default control's implementations? If somebody
|
|
|
|
// has an own control implementation, which does *not* do this - would this be allowed?
|
|
|
|
// If not, then we must move this logic out of here.
|
|
|
|
notifyModifiedValue();
|
2001-01-12 10:35:45 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
//............................................................................
|
|
|
|
} // namespace pcr
|
|
|
|
//............................................................................
|
|
|
|
|