2010-10-12 15:57:08 +02:00
|
|
|
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
|
2012-06-21 14:30:25 +01:00
|
|
|
/*
|
|
|
|
* This file is part of the LibreOffice project.
|
|
|
|
*
|
|
|
|
* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
*
|
|
|
|
* This file incorporates work covered by the following license notice:
|
|
|
|
*
|
|
|
|
* Licensed to the Apache Software Foundation (ASF) under one or more
|
|
|
|
* contributor license agreements. See the NOTICE file distributed
|
|
|
|
* with this work for additional information regarding copyright
|
|
|
|
* ownership. The ASF licenses this file to you under the Apache
|
|
|
|
* License, Version 2.0 (the "License"); you may not use this file
|
|
|
|
* except in compliance with the License. You may obtain a copy of
|
|
|
|
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
|
|
|
|
*/
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
#include "commoncontrol.hxx"
|
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
|
|
|
#include "pcrcommon.hxx"
|
2001-01-12 10:35:45 +00:00
|
|
|
#include <tools/debug.hxx>
|
2007-05-10 09:46:51 +00:00
|
|
|
#include <tools/diagnose_ex.h>
|
2001-01-12 10:35:45 +00:00
|
|
|
#include <vcl/combobox.hxx>
|
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
|
|
|
#include <toolkit/helper/vclunohelper.hxx>
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
namespace pcr
|
|
|
|
{
|
2014-02-25 18:36:00 +01: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
|
|
|
|
|
|
|
using ::com::sun::star::uno::RuntimeException;
|
|
|
|
using ::com::sun::star::uno::Reference;
|
|
|
|
using ::com::sun::star::inspection::XPropertyControlContext;
|
|
|
|
using ::com::sun::star::uno::Exception;
|
|
|
|
using ::com::sun::star::inspection::XPropertyControl;
|
|
|
|
|
2015-10-09 16:22:24 +02:00
|
|
|
CommonBehaviourControlHelper::CommonBehaviourControlHelper( sal_Int16 _nControlType, XPropertyControl& _rAntiImpl )
|
|
|
|
:m_nControlType( _nControlType )
|
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
|
|
|
,m_rAntiImpl( _rAntiImpl )
|
2014-04-30 11:46:15 +02:00
|
|
|
,m_bModified( false )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2015-10-09 15:17:24 +02:00
|
|
|
CommonBehaviourControlHelper::~CommonBehaviourControlHelper()
|
2006-07-26 06:54:32 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
void SAL_CALL CommonBehaviourControlHelper::setControlContext( const Reference< XPropertyControlContext >& _controlcontext )
|
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
|
|
|
{
|
|
|
|
m_xContext = _controlcontext;
|
|
|
|
}
|
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
void SAL_CALL CommonBehaviourControlHelper::notifyModifiedValue( )
|
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 ( isModified() && m_xContext.is() )
|
|
|
|
{
|
|
|
|
try
|
|
|
|
{
|
2006-12-13 10:57:02 +00:00
|
|
|
m_xContext->valueChanged( &m_rAntiImpl );
|
2014-04-30 11:46:15 +02:00
|
|
|
m_bModified = false;
|
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
|
|
|
}
|
2007-05-10 09:46:51 +00:00
|
|
|
catch( const Exception& )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2007-05-10 09:46:51 +00:00
|
|
|
DBG_UNHANDLED_EXCEPTION();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2015-10-09 15:17:24 +02:00
|
|
|
void CommonBehaviourControlHelper::autoSizeWindow()
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2015-10-09 16:22:24 +02:00
|
|
|
ScopedVclPtrInstance< ComboBox > aComboBox(getVclWindow(), WB_DROPDOWN);
|
2015-02-11 14:42:23 +02:00
|
|
|
aComboBox->SetPosSizePixel(Point(0,0), Size(100,100));
|
2015-10-09 16:22:24 +02:00
|
|
|
getVclWindow()->SetSizePixel(aComboBox->GetSizePixel());
|
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: why do the controls this themselves? Shouldn't this be the task
|
2013-02-22 09:48:17 +02:00
|
|
|
// of the browser listbox/line?
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2015-10-09 15:17:24 +02:00
|
|
|
void CommonBehaviourControlHelper::activateNextControl() 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() )
|
2015-05-29 12:04:25 +02:00
|
|
|
m_xContext->activateNextControl( &m_rAntiImpl );
|
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
|
|
|
}
|
2007-05-10 09:46:51 +00:00
|
|
|
catch( const Exception& )
|
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
|
|
|
{
|
2007-05-10 09:46:51 +00:00
|
|
|
DBG_UNHANDLED_EXCEPTION();
|
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
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2016-10-05 07:56:12 +02:00
|
|
|
IMPL_LINK_NOARG( CommonBehaviourControlHelper, EditModifiedHdl, Edit&, void )
|
2015-10-15 08:13:49 +02:00
|
|
|
{
|
|
|
|
setModified();
|
|
|
|
}
|
|
|
|
|
2016-10-05 07:56:12 +02:00
|
|
|
IMPL_LINK_NOARG( CommonBehaviourControlHelper, ModifiedHdl, ListBox&, void )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2015-10-09 17:44:20 +02:00
|
|
|
setModified();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2016-11-05 20:28:27 +00:00
|
|
|
IMPL_LINK_NOARG( CommonBehaviourControlHelper, ColorModifiedHdl, SvxColorListBox&, void )
|
|
|
|
{
|
|
|
|
setModified();
|
|
|
|
}
|
|
|
|
|
2016-10-05 07:56:12 +02:00
|
|
|
IMPL_LINK_NOARG( CommonBehaviourControlHelper, GetFocusHdl, Control&, void )
|
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 );
|
|
|
|
}
|
2007-05-10 09:46:51 +00:00
|
|
|
catch( const Exception& )
|
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
|
|
|
{
|
2007-05-10 09:46:51 +00:00
|
|
|
DBG_UNHANDLED_EXCEPTION();
|
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
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2016-10-05 07:56:12 +02:00
|
|
|
IMPL_LINK_NOARG( CommonBehaviourControlHelper, LoseFocusHdl, Control&, void )
|
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
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
} // namespace pcr
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2010-10-12 15:57:08 +02:00
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|