Files
libreoffice/extensions/source/propctrlr/propertyeditor.cxx

486 lines
18 KiB
C++
Raw Normal View History

/*************************************************************************
*
* OpenOffice.org - a multi-platform office productivity suite
*
* $RCSfile: propertyeditor.cxx,v $
*
* $Revision: 1.17 $
*
* last change: $Author: obo $ $Date: 2006-09-16 13:22:08 $
*
* The Contents of this file are made available subject to
* the terms of GNU Lesser General Public License Version 2.1.
*
*
* GNU Lesser General Public License Version 2.1
* =============================================
* Copyright 2005 by Sun Microsystems, Inc.
* 901 San Antonio Road, Palo Alto, CA 94303, USA
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License version 2.1, as published by the Free Software Foundation.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*
************************************************************************/
// MARKER(update_precomp.py): autogen include statement, do not remove
#include "precompiled_extensions.hxx"
#ifndef _EXTENSIONS_PROPCTRLR_PROPERTYEDITOR_HXX_
#include "propertyeditor.hxx"
#endif
#ifndef _EXTENSIONS_PROPCTRLR_BROWSERPAGE_HXX_
#include "browserpage.hxx"
#endif
#ifndef _EXTENSIONS_PROPCTRLR_LINEDESCRIPTOR_HXX_
#include "linedescriptor.hxx"
#endif
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
/** === begin UNO includes === **/
/** === end UNO includes === **/
#ifndef _TOOLS_DEBUG_HXX
#include <tools/debug.hxx>
#endif
//............................................................................
namespace pcr
{
//............................................................................
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
/** === begin UNO using === **/
using ::com::sun::star::uno::Any;
using ::com::sun::star::inspection::XPropertyControl;
using ::com::sun::star::uno::Reference;
/** === end UNO using === **/
//==================================================================
// class OPropertyEditor
//==================================================================
2001-01-18 13:45:10 +00:00
DBG_NAME(OPropertyEditor)
//------------------------------------------------------------------
OPropertyEditor::OPropertyEditor( Window* pParent, WinBits nWinStyle)
:Control(pParent, nWinStyle)
,m_aTabControl(this)
,m_nNextId(1)
{
DBG_CTOR(OPropertyEditor,NULL);
m_aTabControl.Show();
m_aTabControl.SetDeactivatePageHdl(LINK(this, OPropertyEditor, OnPageDeactivate));
m_aTabControl.SetActivatePageHdl(LINK(this, OPropertyEditor, OnPageActivate));
m_aTabControl.SetBackground(GetBackground());
m_aTabControl.SetPaintTransparent(sal_True);
}
//------------------------------------------------------------------
OPropertyEditor::~OPropertyEditor()
{
Hide();
ClearAll();
DBG_DTOR(OPropertyEditor,NULL);
}
//------------------------------------------------------------------
void OPropertyEditor::ClearAll()
{
m_nNextId=1;
sal_uInt16 nCount = m_aTabControl.GetPageCount();
for(long i = nCount-1; i >= 0; --i)
{
sal_uInt16 nID = m_aTabControl.GetPageId((sal_uInt16)i);
OBrowserPage* pPage = static_cast<OBrowserPage*>(m_aTabControl.GetTabPage(nID));
if (pPage)
{
pPage->EnableInput(sal_False);
m_aTabControl.RemovePage(nID);
delete pPage;
}
}
m_aTabControl.Clear();
{
MapStringToPageId aEmpty;
m_aPropertyPageIds.swap( aEmpty );
}
while ( !m_aHiddenPages.empty() )
{
delete m_aHiddenPages.begin()->second.pPage;
m_aHiddenPages.erase( m_aHiddenPages.begin() );
}
}
// #95343# ---------------------------------------------------------
sal_Int32 OPropertyEditor::getMinimumWidth()
{
sal_uInt16 nCount = m_aTabControl.GetPageCount();
sal_Int32 nPageMinWidth = 0;
for(long i = nCount-1; i >= 0; --i)
{
sal_uInt16 nID = m_aTabControl.GetPageId((sal_uInt16)i);
OBrowserPage* pPage = static_cast<OBrowserPage*>(m_aTabControl.GetTabPage(nID));
if (pPage)
{
sal_Int32 nCurPageMinWidth = pPage->getMinimumWidth();
if( nCurPageMinWidth > nPageMinWidth )
nPageMinWidth = nCurPageMinWidth;
}
}
return nPageMinWidth+6;
}
//------------------------------------------------------------------
void OPropertyEditor::CommitModified()
{
// commit all of my pages, if necessary
sal_uInt16 nCount = m_aTabControl.GetPageCount();
for ( sal_uInt16 i=0; i<nCount; ++i )
{
sal_uInt16 nID = m_aTabControl.GetPageId( i );
OBrowserPage* pPage = static_cast< OBrowserPage* >( m_aTabControl.GetTabPage( nID ) );
if ( pPage && pPage->getListBox() && pPage->getListBox()->IsModified() )
pPage->getListBox()->CommitModified();
}
}
//------------------------------------------------------------------
void OPropertyEditor::GetFocus()
{
m_aTabControl.GrabFocus();
}
//------------------------------------------------------------------
OBrowserPage* OPropertyEditor::getPage( const ::rtl::OUString& _rPropertyName )
{
OBrowserPage* pPage = NULL;
MapStringToPageId::const_iterator aPropertyPageIdPos = m_aPropertyPageIds.find( _rPropertyName );
if ( aPropertyPageIdPos != m_aPropertyPageIds.end() )
pPage = static_cast< OBrowserPage* >( m_aTabControl.GetTabPage( aPropertyPageIdPos->second ) );
return pPage;
}
//------------------------------------------------------------------
const OBrowserPage* OPropertyEditor::getPage( const ::rtl::OUString& _rPropertyName ) const
{
return const_cast< OPropertyEditor* >( this )->getPage( _rPropertyName );
}
//------------------------------------------------------------------
OBrowserPage* OPropertyEditor::getPage( sal_uInt16& _rPageId )
{
return static_cast< OBrowserPage* >( m_aTabControl.GetTabPage( _rPageId ) );
}
//------------------------------------------------------------------
const OBrowserPage* OPropertyEditor::getPage( sal_uInt16& _rPageId ) const
{
return const_cast< OPropertyEditor* >( this )->getPage( _rPageId );
}
//------------------------------------------------------------------
void OPropertyEditor::Resize()
{
Size aSize( GetOutputSizePixel() );
aSize.Width() -= 6;
aSize.Height() -= 6;
m_aTabControl.SetPosSizePixel( Point( 3, 3 ), aSize );
}
//------------------------------------------------------------------
sal_uInt16 OPropertyEditor::AppendPage(const String & _rText,sal_uInt32 _nHelpId)
{
// obtain a new id
sal_uInt16 nId = m_nNextId++;
// insert the id
m_aTabControl.InsertPage(nId, _rText);
// create a new page
OBrowserPage* pPage = new OBrowserPage(&m_aTabControl);
pPage->SetText( _rText );
// some knittings
pPage->SetSizePixel(m_aTabControl.GetTabPageSizePixel());
pPage->getListBox()->setListener(m_pListener);
pPage->SetHelpId(_nHelpId);
// immediately activate the page
m_aTabControl.SetTabPage(nId, pPage);
m_aTabControl.SetCurPageId(nId);
return nId;
}
//------------------------------------------------------------------
void OPropertyEditor::SetHelpId( sal_uInt32 nHelpId )
{
Control::SetHelpId(0);
m_aTabControl.SetHelpId(nHelpId);
}
//------------------------------------------------------------------
void OPropertyEditor::RemovePage(sal_uInt16 nID)
{
OBrowserPage* pPage = static_cast<OBrowserPage*>(m_aTabControl.GetTabPage(nID));
if (pPage)
pPage->EnableInput(sal_False);
m_aTabControl.RemovePage(nID);
if (pPage)
delete pPage;
}
//------------------------------------------------------------------
void OPropertyEditor::SetPage(sal_uInt16 nId)
{
m_aTabControl.SetCurPageId(nId);
}
//------------------------------------------------------------------
sal_uInt16 OPropertyEditor::GetCurPage()
{
if(m_aTabControl.GetPageCount()>0)
return m_aTabControl.GetCurPageId();
else
return 0;
}
//------------------------------------------------------------------
sal_uInt16 OPropertyEditor::CalcVisibleLines()
{
OBrowserPage* pPage = static_cast<OBrowserPage*>(m_aTabControl.GetTabPage(m_aTabControl.GetCurPageId()));
if (pPage)
return pPage->getListBox()->CalcVisibleLines();
else return 0;
}
//------------------------------------------------------------------
void OPropertyEditor::EnableUpdate()
{
// forward this to all our pages
sal_uInt16 nCount = m_aTabControl.GetPageCount();
for (sal_uInt16 i=0;i<nCount;++i)
{
sal_uInt16 nID = m_aTabControl.GetPageId(i);
OBrowserPage* pPage = static_cast<OBrowserPage*>(m_aTabControl.GetTabPage(nID));
if (pPage)
pPage->getListBox()->EnableUpdate();
}
}
//------------------------------------------------------------------
void OPropertyEditor::DisableUpdate()
{
// forward this to all our pages
sal_uInt16 nCount = m_aTabControl.GetPageCount();
for (sal_uInt16 i=0;i<nCount;++i)
{
sal_uInt16 nID = m_aTabControl.GetPageId(i);
OBrowserPage* pPage = static_cast<OBrowserPage*>(m_aTabControl.GetTabPage(nID));
if (pPage)
pPage->getListBox()->DisableUpdate();
}
}
//------------------------------------------------------------------
void OPropertyEditor::SetLineListener(IPropertyLineListener* _pListener)
{
m_pListener = _pListener;
// forward the new listener to our pages
sal_uInt16 nCount = m_aTabControl.GetPageCount();
for (sal_uInt16 i=0;i<nCount;++i)
{
sal_uInt16 nID = m_aTabControl.GetPageId(i);
OBrowserPage* pPage = static_cast<OBrowserPage*>(m_aTabControl.GetTabPage(nID));
if (pPage)
pPage->getListBox()->setListener(m_pListener);
}
}
//------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
sal_uInt16 OPropertyEditor::InsertEntry( const OLineDescriptor& rData, sal_uInt16 _nPageId, sal_uInt16 nPos )
{
// let the current page handle this
OBrowserPage* pPage = getPage( _nPageId );
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
DBG_ASSERT( pPage, "OPropertyEditor::InsertEntry: don't have such a page!" );
if ( !pPage )
return LISTBOX_ENTRY_NOTFOUND;
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
sal_uInt16 nEntry = pPage->getListBox()->InsertEntry( rData, nPos );
OSL_ENSURE( m_aPropertyPageIds.find( rData.sName ) == m_aPropertyPageIds.end(),
"OPropertyEditor::InsertEntry: property already present in the map!" );
m_aPropertyPageIds.insert( MapStringToPageId::value_type( rData.sName, _nPageId ) );
return nEntry;
}
//------------------------------------------------------------------
void OPropertyEditor::RemoveEntry( const ::rtl::OUString& _rName )
{
OBrowserPage* pPage = getPage( _rName );
if ( pPage )
{
OSL_VERIFY( pPage->getListBox()->RemoveEntry( _rName ) );
OSL_ENSURE( m_aPropertyPageIds.find( _rName ) != m_aPropertyPageIds.end(),
"OPropertyEditor::RemoveEntry: property not present in the map!" );
m_aPropertyPageIds.erase( _rName );
}
}
//------------------------------------------------------------------
void OPropertyEditor::ChangeEntry( const OLineDescriptor& rData )
{
OBrowserPage* pPage = getPage( rData.sName );
if ( pPage )
pPage->getListBox()->ChangeEntry( rData, EDITOR_LIST_REPLACE_EXISTING );
}
//------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
void OPropertyEditor::SetPropertyValue( const ::rtl::OUString& rEntryName, const Any& _rValue )
{
OBrowserPage* pPage = getPage( rEntryName );
if ( pPage )
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
pPage->getListBox()->SetPropertyValue( rEntryName, _rValue );
}
//------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
Any OPropertyEditor::GetPropertyValue( const ::rtl::OUString& rEntryName ) const
{
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
Any aValue;
const OBrowserPage* pPage = getPage( rEntryName );
if ( pPage )
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
aValue = pPage->getListBox()->GetPropertyValue( rEntryName );
return aValue;
}
//------------------------------------------------------------------
sal_uInt16 OPropertyEditor::GetPropertyPos( const ::rtl::OUString& rEntryName ) const
{
sal_uInt16 nVal=LISTBOX_ENTRY_NOTFOUND;
const OBrowserPage* pPage = getPage( rEntryName );
if ( pPage )
nVal = pPage->getListBox()->GetPropertyPos( rEntryName );
return nVal;
}
//------------------------------------------------------------------
sal_Bool OPropertyEditor::IsPropertyInputEnabled( const ::rtl::OUString& _rEntryName ) const
{
// "yes" if and only if all pages say "yes" (since pages which do not know this property
// will answer "yes")
for ( USHORT i = 0; i < m_aTabControl.GetPageCount(); ++i )
{
OBrowserPage* pPage = static_cast< OBrowserPage* >( m_aTabControl.GetTabPage( m_aTabControl.GetPageId( i ) ) );
if ( pPage )
if ( !pPage->getListBox()->IsPropertyInputEnabled( _rEntryName) )
return sal_False;
}
return sal_True;
}
//------------------------------------------------------------------
void OPropertyEditor::ShowPropertyPage( sal_uInt16 _nPageId, bool _bShow )
{
if ( !_bShow )
{
sal_uInt16 nPagePos = m_aTabControl.GetPagePos( _nPageId );
if ( TAB_PAGE_NOTFOUND == nPagePos )
return;
DBG_ASSERT( m_aHiddenPages.find( _nPageId ) == m_aHiddenPages.end(), "OPropertyEditor::ShowPropertyPage: page already hidden!" );
m_aHiddenPages[ _nPageId ] = HiddenPage( nPagePos, m_aTabControl.GetTabPage( _nPageId ) );
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
m_aTabControl.RemovePage( _nPageId );
}
else
{
::std::map< sal_uInt16, HiddenPage >::iterator aPagePos = m_aHiddenPages.find( _nPageId );
if ( aPagePos == m_aHiddenPages.end() )
return;
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
aPagePos->second.pPage->SetSizePixel( m_aTabControl.GetTabPageSizePixel() );
m_aTabControl.InsertPage( aPagePos->first, aPagePos->second.pPage->GetText(), aPagePos->second.nPos );
m_aTabControl.SetTabPage( aPagePos->first, aPagePos->second.pPage );
m_aHiddenPages.erase( aPagePos );
}
}
//------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
void OPropertyEditor::EnablePropertyControls( const ::rtl::OUString& _rEntryName, sal_Int16 _nControls, bool _bEnable )
{
for ( USHORT i = 0; i < m_aTabControl.GetPageCount(); ++i )
{
OBrowserPage* pPage = static_cast< OBrowserPage* >( m_aTabControl.GetTabPage( m_aTabControl.GetPageId( i ) ) );
if ( pPage )
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
pPage->getListBox()->EnablePropertyControls( _rEntryName, _nControls, _bEnable );
}
}
//------------------------------------------------------------------
void OPropertyEditor::EnablePropertyLine( const ::rtl::OUString& _rEntryName, bool _bEnable )
{
for ( USHORT i = 0; i < m_aTabControl.GetPageCount(); ++i )
{
OBrowserPage* pPage = static_cast< OBrowserPage* >( m_aTabControl.GetTabPage( m_aTabControl.GetPageId( i ) ) );
if ( pPage )
pPage->getListBox()->EnablePropertyLine( _rEntryName, _bEnable );
}
}
//------------------------------------------------------------------
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
Reference< XPropertyControl > OPropertyEditor::GetPropertyControl(const ::rtl::OUString& rEntryName)
{
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
Reference< XPropertyControl > xControl;
// let the current page handle this
OBrowserPage* pPage = static_cast<OBrowserPage*>(m_aTabControl.GetTabPage(m_aTabControl.GetCurPageId()));
if (pPage)
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
xControl = pPage->getListBox()->GetPropertyControl(rEntryName);
return xControl;
}
//------------------------------------------------------------------
IMPL_LINK(OPropertyEditor, OnPageActivate, TabControl*, EMPTYARG)
{
if (m_aPageActivationHandler.IsSet())
m_aPageActivationHandler.Call(NULL);
return 0L;
}
//------------------------------------------------------------------
IMPL_LINK(OPropertyEditor, OnPageDeactivate, TabControl*, EMPTYARG)
{
// commit the data on the current (to-be-decativated) tab page
// (79404)
sal_Int32 nCurrentId = m_aTabControl.GetCurPageId();
OBrowserPage* pCurrentPage = static_cast<OBrowserPage*>(m_aTabControl.GetTabPage((sal_uInt16)nCurrentId));
OBrowserListBox* pListBox = pCurrentPage ? pCurrentPage->getListBox() : NULL;
INTEGRATION: CWS pbrwuno (1.14.158); FILE MERGED 2005/12/19 12:21:59 fs 1.14.158.7: #i53095# InsertEntry: assert if the page is invalid 2005/10/31 13:45:59 fs 1.14.158.6: some cleanup 2005/10/05 07:07:14 fs 1.14.158.5: RESYNC: (1.14-1.15); FILE MERGED 2005/09/05 07:41:53 fs 1.14.158.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/18 12:44:34 fs 1.14.158.3: #i53095#, phase 2 moved (nearly) all property handling to dedicated handlers, the controller is now simply managing a set of handlers open issues for making the property browser completely generic: - target page for a property - at the moment, the pbrw uses form-specific knowledge - relative position of properties. Again, the pbrw uses the OPropertyInfoService which is not generic - isComposeable for a given property. Also OPropertyInfoService-dependent ATM - help ids of pages and the pbrw as a whole. They're hard-coded at the moment other open issues: everything in the code which is tagged with TOD/UNOize. Those are items which do not immediately hinder phase 3 (real UNOization, i.e. definition of new UNO interfaces for the handlers, the controller, and so on), but need to be addressed in phase 4 (knit lose ends) 2005/08/12 16:30:14 fs 1.14.158.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 14:00:05 fs 1.14.158.1: #i53095# phase 1: - don't use strings to transver values between controls and introspectee, but Anys - first version of a dedicated property handler for form-component-related properties (not yet completed) known regressions over previous phase: - handlers for events not yet implemented, thus some assertions - click handlers for form-component-related properties do not yet work, thus the browse buttons mostly do not work
2006-03-14 10:30:09 +00:00
if ( pListBox && pListBox->IsModified() )
pListBox->CommitModified();
return 1L;
}
//............................................................................
} // namespace pcr
//............................................................................