2001-01-12 10:35:45 +00:00
|
|
|
/*************************************************************************
|
|
|
|
*
|
2008-04-11 09:38:10 +00:00
|
|
|
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2008-04-11 09:38:10 +00:00
|
|
|
* Copyright 2008 by Sun Microsystems, Inc.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2008-04-11 09:38:10 +00:00
|
|
|
* OpenOffice.org - a multi-platform office productivity suite
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2008-04-11 09:38:10 +00:00
|
|
|
* $RCSfile: browserline.cxx,v $
|
2008-05-20 18:10:14 +00:00
|
|
|
* $Revision: 1.20 $
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2008-04-11 09:38:10 +00:00
|
|
|
* This file is part of OpenOffice.org.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2008-04-11 09:38:10 +00:00
|
|
|
* OpenOffice.org is free software: you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU Lesser General Public License version 3
|
|
|
|
* only, as published by the Free Software Foundation.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2008-04-11 09:38:10 +00:00
|
|
|
* OpenOffice.org 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 version 3 for more details
|
|
|
|
* (a copy is included in the LICENSE file that accompanied this code).
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2008-04-11 09:38:10 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public License
|
|
|
|
* version 3 along with OpenOffice.org. If not, see
|
|
|
|
* <http://www.openoffice.org/license.html>
|
|
|
|
* for a copy of the LGPLv3 License.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
|
|
|
************************************************************************/
|
|
|
|
|
2006-09-16 12:12:55 +00:00
|
|
|
// MARKER(update_precomp.py): autogen include statement, do not remove
|
|
|
|
#include "precompiled_extensions.hxx"
|
2001-01-12 10:35:45 +00:00
|
|
|
#include "browserline.hxx"
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
|
|
|
|
/** === begin UNO includes === **/
|
|
|
|
#include <com/sun/star/inspection/PropertyLineElement.hpp>
|
2007-08-03 12:52:21 +00:00
|
|
|
#include <com/sun/star/graphic/XGraphicProvider.hpp>
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
/** === end UNO includes === **/
|
|
|
|
|
|
|
|
#include <vcl/svapp.hxx>
|
2001-01-12 10:35:45 +00:00
|
|
|
#include <tools/debug.hxx>
|
2007-08-03 12:52:21 +00:00
|
|
|
#include <tools/diagnose_ex.h>
|
|
|
|
#include <tools/urlobj.hxx>
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
#include <toolkit/helper/vclunohelper.hxx>
|
2007-08-03 12:52:21 +00:00
|
|
|
|
|
|
|
#include <comphelper/processfactory.hxx>
|
|
|
|
#include <comphelper/componentcontext.hxx>
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
//............................................................................
|
|
|
|
namespace pcr
|
|
|
|
{
|
|
|
|
//............................................................................
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
/** === begin UNO using === **/
|
|
|
|
using ::com::sun::star::uno::Reference;
|
|
|
|
using ::com::sun::star::inspection::XPropertyControl;
|
|
|
|
using ::com::sun::star::inspection::XPropertyControlContext;
|
|
|
|
using ::com::sun::star::uno::UNO_QUERY_THROW;
|
|
|
|
using ::com::sun::star::uno::Exception;
|
2007-08-03 12:52:21 +00:00
|
|
|
using ::com::sun::star::graphic::XGraphicProvider;
|
|
|
|
using ::com::sun::star::uno::Sequence;
|
|
|
|
using ::com::sun::star::beans::PropertyValue;
|
|
|
|
using ::com::sun::star::graphic::XGraphic;
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
/** === end UNO using === **/
|
|
|
|
|
|
|
|
namespace PropertyLineElement = ::com::sun::star::inspection::PropertyLineElement;
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//==================================================================
|
|
|
|
//= OBrowserLine
|
|
|
|
//==================================================================
|
2001-01-18 12:20:45 +00:00
|
|
|
DBG_NAME(OBrowserLine)
|
2001-01-12 10:35:45 +00:00
|
|
|
//------------------------------------------------------------------
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
OBrowserLine::OBrowserLine( const ::rtl::OUString& _rEntryName, Window* pParent )
|
|
|
|
:m_sEntryName( _rEntryName )
|
|
|
|
,m_aFtTitle(pParent)
|
|
|
|
,m_pControlWindow( NULL )
|
2004-03-19 10:59:54 +00:00
|
|
|
,m_pBrowseButton(NULL)
|
2004-11-16 11:00:17 +00:00
|
|
|
,m_pAdditionalBrowseButton( NULL )
|
|
|
|
,m_pClickListener( NULL )
|
2008-01-14 13:55:45 +00:00
|
|
|
,m_pTheParent(pParent)
|
|
|
|
,m_nNameWidth(0)
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
,m_nEnableFlags( 0xFFFF )
|
2008-01-14 13:55:45 +00:00
|
|
|
,m_bIndentTitle( false )
|
|
|
|
,m_bReadOnly( false )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
|
|
|
DBG_CTOR(OBrowserLine,NULL);
|
|
|
|
m_aFtTitle.Show();
|
|
|
|
}
|
2004-11-16 11:00:17 +00:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//------------------------------------------------------------------
|
|
|
|
OBrowserLine::~OBrowserLine()
|
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
implHideBrowseButton( true, false );
|
|
|
|
implHideBrowseButton( false, false );
|
|
|
|
|
|
|
|
DBG_DTOR(OBrowserLine,NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
2007-05-10 09:46:12 +00:00
|
|
|
void OBrowserLine::IndentTitle( bool _bIndent )
|
2004-11-16 11:00:17 +00:00
|
|
|
{
|
|
|
|
if ( m_bIndentTitle != _bIndent )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
m_bIndentTitle = _bIndent;
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
impl_layoutComponents();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
2008-03-05 16:12:22 +00:00
|
|
|
void OBrowserLine::SetComponentHelpIds( const SmartId& _rHelpId, sal_uInt32 _bPrimaryButtonId, sal_uInt32 _nSecondaryButtonId )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( m_pControlWindow )
|
2008-03-05 16:12:22 +00:00
|
|
|
m_pControlWindow->SetSmartHelpId( _rHelpId );
|
2004-11-16 11:00:17 +00:00
|
|
|
|
|
|
|
if ( m_pBrowseButton )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2008-03-05 16:12:22 +00:00
|
|
|
m_pBrowseButton->SetSmartHelpId( _rHelpId );
|
2004-11-16 11:00:17 +00:00
|
|
|
m_pBrowseButton->SetUniqueId( _bPrimaryButtonId );
|
|
|
|
|
|
|
|
if ( m_pAdditionalBrowseButton )
|
|
|
|
{
|
2008-03-05 16:12:22 +00:00
|
|
|
m_pAdditionalBrowseButton->SetSmartHelpId( _rHelpId );
|
2004-11-16 11:00:17 +00:00
|
|
|
m_pAdditionalBrowseButton->SetUniqueId( _nSecondaryButtonId );
|
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
void OBrowserLine::setControl( const Reference< XPropertyControl >& _rxControl )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
m_xControl = _rxControl;
|
|
|
|
m_pControlWindow = m_xControl.is() ? VCLUnoHelper::GetWindow( _rxControl->getControlWindow() ) : NULL;
|
|
|
|
DBG_ASSERT( m_pControlWindow, "OBrowserLine::setControl: setting NULL controls/windows is not allowed!" );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( m_pControlWindow )
|
|
|
|
{
|
|
|
|
m_pControlWindow->SetParent( m_pTheParent );
|
|
|
|
m_pControlWindow->Show();
|
|
|
|
}
|
|
|
|
impl_layoutComponents();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
|
|
|
Window* OBrowserLine::GetRefWindow()
|
|
|
|
{
|
|
|
|
Window* pRefWindow=&m_aFtTitle;
|
|
|
|
|
2004-03-19 10:59:54 +00:00
|
|
|
if(m_pBrowseButton)
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-03-19 10:59:54 +00:00
|
|
|
pRefWindow=(Window*)m_pBrowseButton;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
else if ( m_pControlWindow )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
pRefWindow = m_pControlWindow;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
return pRefWindow;
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
|
|
|
void OBrowserLine::SetTabOrder(Window* pRefWindow, sal_uInt16 nFlags )
|
|
|
|
{
|
|
|
|
m_aFtTitle.SetZOrder(pRefWindow,nFlags);
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( m_pControlWindow )
|
|
|
|
m_pControlWindow->SetZOrder( (Window*)&m_aFtTitle, WINDOW_ZORDER_BEHIND );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2004-11-16 11:00:17 +00:00
|
|
|
if ( m_pBrowseButton )
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
m_pBrowseButton->SetZOrder( m_pControlWindow, WINDOW_ZORDER_BEHIND );
|
2004-11-16 11:00:17 +00:00
|
|
|
|
|
|
|
if ( m_pAdditionalBrowseButton )
|
|
|
|
m_pAdditionalBrowseButton->SetZOrder( m_pBrowseButton, WINDOW_ZORDER_BEHIND );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
|
|
|
sal_Bool OBrowserLine::GrabFocus()
|
|
|
|
{
|
|
|
|
sal_Bool bRes=sal_False;
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( m_pControlWindow && m_pControlWindow->IsEnabled() )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
m_pControlWindow->GrabFocus();
|
2004-11-16 11:00:17 +00:00
|
|
|
bRes = sal_True;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
2004-11-16 11:00:17 +00:00
|
|
|
else if ( m_pAdditionalBrowseButton && m_pAdditionalBrowseButton->IsEnabled() )
|
|
|
|
{
|
|
|
|
m_pAdditionalBrowseButton->GrabFocus();
|
|
|
|
bRes = sal_True;
|
|
|
|
}
|
|
|
|
else if ( m_pBrowseButton && m_pBrowseButton->IsEnabled() )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-03-19 10:59:54 +00:00
|
|
|
m_pBrowseButton->GrabFocus();
|
2004-11-16 11:00:17 +00:00
|
|
|
bRes = sal_True;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
return bRes;
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
2004-11-16 11:00:17 +00:00
|
|
|
void OBrowserLine::SetPosSizePixel( Point _rPos, Size _rSize )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
m_aLinePos = _rPos;
|
|
|
|
m_aOutputSize = _rSize;
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
impl_layoutComponents();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
|
|
|
void OBrowserLine::Show(sal_Bool bFlag)
|
|
|
|
{
|
|
|
|
m_aFtTitle.Show(bFlag);
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( m_pControlWindow )
|
|
|
|
m_pControlWindow->Show( bFlag );
|
2004-11-16 11:00:17 +00:00
|
|
|
if ( m_pBrowseButton )
|
|
|
|
m_pBrowseButton->Show( bFlag );
|
|
|
|
if ( m_pAdditionalBrowseButton )
|
|
|
|
m_pAdditionalBrowseButton->Show( bFlag );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
|
|
|
void OBrowserLine::Hide()
|
|
|
|
{
|
|
|
|
Show(sal_False);
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
|
|
|
sal_Bool OBrowserLine::IsVisible()
|
|
|
|
{
|
|
|
|
return m_aFtTitle.IsVisible();
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
void OBrowserLine::impl_layoutComponents()
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
Point aTitlePos( m_aLinePos.X(), m_aLinePos.Y() + 8 );
|
|
|
|
Size aTitleSize( m_nNameWidth - 3, m_aOutputSize.Height() );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2004-11-16 11:00:17 +00:00
|
|
|
if ( m_bIndentTitle )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
Size aIndent( m_pTheParent->LogicToPixel( Size( 8, 0 ), MAP_APPFONT ) );
|
|
|
|
aTitlePos.X() += aIndent.Width();
|
|
|
|
aTitleSize.Width() -= aIndent.Width();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
2004-11-16 11:00:17 +00:00
|
|
|
m_aFtTitle.SetPosSizePixel( aTitlePos, aTitleSize );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2004-11-16 11:00:17 +00:00
|
|
|
sal_Int32 nBrowseButtonSize = m_aOutputSize.Height() - 4;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( m_pControlWindow )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
Point aControlPos( m_aLinePos.X() + m_nNameWidth, m_aLinePos.Y() + 2 );
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
m_pControlWindow->SetPosPixel( aControlPos );
|
2004-11-16 11:00:17 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
Size aControlSize( m_aOutputSize.Width() - 4 - m_nNameWidth - nBrowseButtonSize - 4, m_pControlWindow->GetSizePixel().Height() );
|
2004-11-16 11:00:17 +00:00
|
|
|
if ( m_pAdditionalBrowseButton )
|
|
|
|
aControlSize.Width() -= nBrowseButtonSize + 4;
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
m_pControlWindow->SetSizePixel( aControlSize );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2004-03-19 10:59:54 +00:00
|
|
|
if ( m_pBrowseButton )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
Point aButtonPos( m_aOutputSize.Width() - 4 - nBrowseButtonSize, m_aLinePos.Y() + 2 );
|
|
|
|
Size aButtonSize( nBrowseButtonSize, nBrowseButtonSize );
|
|
|
|
m_pBrowseButton->SetPosSizePixel( aButtonPos, aButtonSize );
|
|
|
|
|
|
|
|
if ( m_pAdditionalBrowseButton )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
aButtonPos.X() -= nBrowseButtonSize + 4;
|
|
|
|
m_pAdditionalBrowseButton->SetPosSizePixel( aButtonPos, aButtonSize );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
2005-03-10 16:00:01 +00:00
|
|
|
void OBrowserLine::SetTitle(const XubString& _rNewTtile )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2005-03-10 16:00:01 +00:00
|
|
|
if ( GetTitle() == _rNewTtile )
|
|
|
|
return;
|
2002-11-05 08:56:59 +00:00
|
|
|
// #99102# --------------
|
2005-03-10 16:00:01 +00:00
|
|
|
m_aFtTitle.SetText( _rNewTtile );
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( m_pControlWindow )
|
|
|
|
m_pControlWindow->SetAccessibleName( _rNewTtile );
|
2004-09-08 16:50:06 +00:00
|
|
|
if ( m_pBrowseButton )
|
2005-03-10 16:00:01 +00:00
|
|
|
m_pBrowseButton->SetAccessibleName( _rNewTtile );
|
2002-11-05 08:56:59 +00:00
|
|
|
FullFillTitleString();
|
|
|
|
}
|
|
|
|
|
|
|
|
// #99102# ---------------------------------------------------------
|
|
|
|
void OBrowserLine::FullFillTitleString()
|
|
|
|
{
|
|
|
|
if( m_pTheParent )
|
|
|
|
{
|
|
|
|
String aText = m_aFtTitle.GetText();
|
2007-06-12 04:37:26 +00:00
|
|
|
|
2002-11-05 08:56:59 +00:00
|
|
|
while( m_pTheParent->GetTextWidth( aText ) < m_nNameWidth )
|
2007-06-12 04:37:26 +00:00
|
|
|
aText.AppendAscii("...........");
|
|
|
|
|
|
|
|
// for Issue 69452
|
|
|
|
if (Application::GetSettings().GetLayoutRTL())
|
|
|
|
{
|
|
|
|
sal_Unicode cRTL_mark = 0x200F;
|
|
|
|
aText.Append(cRTL_mark);
|
|
|
|
}
|
|
|
|
|
2002-11-05 08:56:59 +00:00
|
|
|
m_aFtTitle.SetText(aText);
|
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
|
|
|
XubString OBrowserLine::GetTitle() const
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
String sDisplayName = m_aFtTitle.GetText();
|
2007-06-12 04:37:26 +00:00
|
|
|
|
|
|
|
// for Issue 69452
|
|
|
|
if (Application::GetSettings().GetLayoutRTL())
|
|
|
|
{
|
|
|
|
sal_Unicode cRTL_mark = 0x200F;
|
|
|
|
sDisplayName.EraseTrailingChars(cRTL_mark);
|
|
|
|
}
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
sDisplayName.EraseTrailingChars( '.' );
|
2007-06-12 04:37:26 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
return sDisplayName;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
2004-11-16 11:00:17 +00:00
|
|
|
sal_Bool OBrowserLine::IsPropertyInputEnabled( ) const
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
return ( m_nEnableFlags & PropertyLineElement::InputControl ) != 0;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2007-05-10 09:46:12 +00:00
|
|
|
//------------------------------------------------------------------
|
|
|
|
void OBrowserLine::SetReadOnly( bool _bReadOnly )
|
|
|
|
{
|
|
|
|
if ( m_bReadOnly != _bReadOnly )
|
|
|
|
{
|
|
|
|
m_bReadOnly = _bReadOnly;
|
|
|
|
implUpdateEnabledDisabled();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//------------------------------------------------------------------
|
2004-11-16 11:00:17 +00:00
|
|
|
namespace
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
void implSetBitIfAffected( sal_uInt16& _nEnabledBits, sal_Int16 _nAffectedMask, sal_Int16 _nTestBit, bool _bSet )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( _nAffectedMask & _nTestBit )
|
2008-12-11 07:05:03 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( _bSet )
|
|
|
|
_nEnabledBits |= _nTestBit;
|
|
|
|
else
|
|
|
|
_nEnabledBits &= ~_nTestBit;
|
2008-12-11 07:05:03 +00:00
|
|
|
}
|
2004-11-16 11:00:17 +00:00
|
|
|
}
|
|
|
|
|
2007-05-10 09:46:12 +00:00
|
|
|
void implEnable( Window* _pWindow, sal_uInt16 _nEnabledBits, sal_uInt16 _nMatchBits )
|
2004-11-16 11:00:17 +00:00
|
|
|
{
|
|
|
|
if ( _pWindow )
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
_pWindow->Enable( ( _nEnabledBits & _nMatchBits ) == _nMatchBits );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
2007-05-10 09:46:12 +00:00
|
|
|
|
|
|
|
void implEnable( Window* _pWindow, bool _bEnable )
|
|
|
|
{
|
|
|
|
if ( _pWindow )
|
|
|
|
_pWindow->Enable( _bEnable );
|
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
2004-11-16 11:00:17 +00:00
|
|
|
void OBrowserLine::implUpdateEnabledDisabled()
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
implEnable( &m_aFtTitle, m_nEnableFlags, PropertyLineElement::CompleteLine );
|
|
|
|
if ( m_pControlWindow )
|
|
|
|
implEnable( m_pControlWindow, m_nEnableFlags, PropertyLineElement::CompleteLine | PropertyLineElement::InputControl );
|
2007-05-10 09:46:12 +00:00
|
|
|
|
|
|
|
if ( m_bReadOnly )
|
|
|
|
{
|
|
|
|
implEnable( m_pBrowseButton, false );
|
|
|
|
implEnable( m_pAdditionalBrowseButton, false );
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
implEnable( m_pBrowseButton, m_nEnableFlags, PropertyLineElement::CompleteLine | PropertyLineElement::PrimaryButton );
|
|
|
|
implEnable( m_pAdditionalBrowseButton, m_nEnableFlags, PropertyLineElement::CompleteLine | PropertyLineElement::SecondaryButton );
|
|
|
|
}
|
2004-11-16 11:00:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
|
|
|
void OBrowserLine::EnablePropertyLine( bool _bEnable )
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
implSetBitIfAffected( m_nEnableFlags, PropertyLineElement::CompleteLine, PropertyLineElement::CompleteLine, _bEnable );
|
2004-11-16 11:00:17 +00:00
|
|
|
implUpdateEnabledDisabled();
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
void OBrowserLine::EnablePropertyControls( sal_Int16 _nControls, bool _bEnable )
|
2004-11-16 11:00:17 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
implSetBitIfAffected( m_nEnableFlags, _nControls, PropertyLineElement::InputControl, _bEnable );
|
|
|
|
implSetBitIfAffected( m_nEnableFlags, _nControls, PropertyLineElement::PrimaryButton, _bEnable );
|
|
|
|
implSetBitIfAffected( m_nEnableFlags, _nControls, PropertyLineElement::SecondaryButton, _bEnable );
|
2004-11-16 11:00:17 +00:00
|
|
|
implUpdateEnabledDisabled();
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
2007-08-03 12:52:21 +00:00
|
|
|
PushButton& OBrowserLine::impl_ensureButton( bool _bPrimary )
|
2004-11-16 11:00:17 +00:00
|
|
|
{
|
|
|
|
PushButton*& rpButton = _bPrimary ? m_pBrowseButton : m_pAdditionalBrowseButton;
|
|
|
|
|
|
|
|
if ( !rpButton )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
rpButton = new PushButton( m_pTheParent, WB_NOPOINTERFOCUS );
|
|
|
|
rpButton->SetGetFocusHdl( LINK( this, OBrowserLine, OnButtonFocus ) );
|
|
|
|
rpButton->SetClickHdl( LINK( this, OBrowserLine, OnButtonClicked ) );
|
2007-08-03 12:52:21 +00:00
|
|
|
rpButton->SetText( String::CreateFromAscii( "..." ) );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
2007-08-03 12:52:21 +00:00
|
|
|
|
2004-11-16 11:00:17 +00:00
|
|
|
rpButton->Show();
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
impl_layoutComponents();
|
2007-08-03 12:52:21 +00:00
|
|
|
|
|
|
|
return *rpButton;
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
|
|
|
void OBrowserLine::impl_getImagesFromURL_nothrow( const ::rtl::OUString& _rImageURL, Image& _out_rImage, Image& _out_rHCImage )
|
|
|
|
{
|
|
|
|
try
|
|
|
|
{
|
|
|
|
::comphelper::ComponentContext aContext( ::comphelper::getProcessServiceFactory() );
|
|
|
|
Reference< XGraphicProvider > xGraphicProvider( aContext.createComponent( "com.sun.star.graphic.GraphicProvider" ), UNO_QUERY_THROW );
|
|
|
|
|
|
|
|
Sequence< PropertyValue > aMediaProperties(1);
|
|
|
|
aMediaProperties[0].Name = ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "URL" ) );
|
|
|
|
aMediaProperties[0].Value <<= _rImageURL;
|
|
|
|
|
|
|
|
Reference< XGraphic > xGraphic( xGraphicProvider->queryGraphic( aMediaProperties ), UNO_QUERY_THROW );
|
|
|
|
_out_rImage = _out_rHCImage = Image( xGraphic );
|
|
|
|
|
|
|
|
// see if we find an HC version beside the normal graphic
|
|
|
|
INetURLObject aURL( _rImageURL );
|
|
|
|
::rtl::OUString sBaseName( aURL.getBase() );
|
|
|
|
aURL.setBase( sBaseName + ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "_hc" ) ) );
|
|
|
|
::rtl::OUString sHCImageURL( aURL.GetMainURL( INetURLObject::NO_DECODE ) );
|
|
|
|
|
|
|
|
Reference< XGraphic > xHCGraphic;
|
|
|
|
try
|
|
|
|
{
|
|
|
|
aMediaProperties[0].Value <<= sHCImageURL;
|
|
|
|
xHCGraphic = xGraphicProvider->queryGraphic( aMediaProperties );
|
|
|
|
}
|
|
|
|
catch( const Exception& ) { }
|
|
|
|
|
|
|
|
if ( xHCGraphic.is() )
|
|
|
|
_out_rHCImage = Image( xHCGraphic );
|
|
|
|
}
|
|
|
|
catch( const Exception& )
|
|
|
|
{
|
|
|
|
DBG_UNHANDLED_EXCEPTION();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
|
|
|
void OBrowserLine::ShowBrowseButton( const ::rtl::OUString& _rImageURL, sal_Bool _bPrimary )
|
|
|
|
{
|
|
|
|
PushButton& rButton( impl_ensureButton( _bPrimary ) );
|
|
|
|
|
|
|
|
OSL_PRECOND( _rImageURL.getLength(), "OBrowserLine::ShowBrowseButton: use the other version if you don't have an image!" );
|
|
|
|
Image aImage, aHCImage;
|
|
|
|
impl_getImagesFromURL_nothrow( _rImageURL, aImage, aHCImage );
|
|
|
|
|
|
|
|
rButton.SetModeImage( aImage, BMP_COLOR_NORMAL );
|
|
|
|
rButton.SetModeImage( aHCImage, BMP_COLOR_HIGHCONTRAST );
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
|
|
|
void OBrowserLine::ShowBrowseButton( const Image& _rImage, sal_Bool _bPrimary )
|
|
|
|
{
|
|
|
|
PushButton& rButton( impl_ensureButton( _bPrimary ) );
|
|
|
|
if ( !!_rImage )
|
|
|
|
rButton.SetModeImage( _rImage );
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
|
|
|
void OBrowserLine::ShowBrowseButton( sal_Bool _bPrimary )
|
|
|
|
{
|
|
|
|
impl_ensureButton( _bPrimary );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
void OBrowserLine::implHideBrowseButton( sal_Bool _bPrimary, bool _bReLayout )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
PushButton*& rpButton = _bPrimary ? m_pBrowseButton : m_pAdditionalBrowseButton;
|
|
|
|
|
|
|
|
if ( rpButton )
|
|
|
|
{
|
|
|
|
rpButton->Hide();
|
|
|
|
delete rpButton;
|
|
|
|
rpButton = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ( _bReLayout )
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
impl_layoutComponents();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
void OBrowserLine::HideBrowseButton( sal_Bool _bPrimary )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
implHideBrowseButton( _bPrimary, true );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
|
|
|
void OBrowserLine::SetTitleWidth(sal_uInt16 nWidth)
|
|
|
|
{
|
|
|
|
if (m_nNameWidth != nWidth+10)
|
|
|
|
{
|
|
|
|
m_nNameWidth = nWidth+10;
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
impl_layoutComponents();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
2002-11-05 08:56:59 +00:00
|
|
|
// #99102# ---------
|
|
|
|
FullFillTitleString();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
2004-11-16 11:00:17 +00:00
|
|
|
void OBrowserLine::SetClickListener( IButtonClickListener* _pListener )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
m_pClickListener = _pListener;
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
|
|
|
IMPL_LINK( OBrowserLine, OnButtonClicked, PushButton*, _pButton )
|
|
|
|
{
|
|
|
|
if ( m_pClickListener )
|
|
|
|
m_pClickListener->buttonClicked( this, _pButton == m_pBrowseButton );
|
|
|
|
|
|
|
|
return 0L;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
2006-07-26 06:52:16 +00:00
|
|
|
IMPL_LINK( OBrowserLine, OnButtonFocus, PushButton*, /*pPB*/ )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( m_xControl.is() )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
try
|
|
|
|
{
|
|
|
|
Reference< XPropertyControlContext > xContext( m_xControl->getControlContext(), UNO_QUERY_THROW );
|
|
|
|
xContext->focusGained( m_xControl );
|
|
|
|
}
|
2008-01-14 13:55:45 +00:00
|
|
|
catch( const Exception& )
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
{
|
2008-01-14 13:55:45 +00:00
|
|
|
DBG_UNHANDLED_EXCEPTION();
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
//............................................................................
|
|
|
|
} // namespace pcr
|
|
|
|
//............................................................................
|
|
|
|
|