2001-01-12 10:35:45 +00:00
|
|
|
/*************************************************************************
|
|
|
|
*
|
2005-09-08 19:24:21 +00:00
|
|
|
* OpenOffice.org - a multi-platform office productivity suite
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2005-09-08 19:24:21 +00:00
|
|
|
* $RCSfile: propertyeditor.cxx,v $
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2006-09-16 12:22:08 +00:00
|
|
|
* $Revision: 1.17 $
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2006-09-16 12:22:08 +00:00
|
|
|
* last change: $Author: obo $ $Date: 2006-09-16 13:22:08 $
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2005-09-08 19:24:21 +00:00
|
|
|
* The Contents of this file are made available subject to
|
|
|
|
* the terms of GNU Lesser General Public License Version 2.1.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
|
|
|
*
|
2005-09-08 19:24:21 +00:00
|
|
|
* GNU Lesser General Public License Version 2.1
|
|
|
|
* =============================================
|
|
|
|
* Copyright 2005 by Sun Microsystems, Inc.
|
|
|
|
* 901 San Antonio Road, Palo Alto, CA 94303, USA
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2005-09-08 19:24:21 +00:00
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License version 2.1, as published by the Free Software Foundation.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2005-09-08 19:24:21 +00:00
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2005-09-08 19:24:21 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with this library; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
|
|
|
|
* MA 02111-1307 USA
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
|
|
|
************************************************************************/
|
|
|
|
|
2006-09-16 12:22:08 +00:00
|
|
|
// MARKER(update_precomp.py): autogen include statement, do not remove
|
|
|
|
#include "precompiled_extensions.hxx"
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
#ifndef _EXTENSIONS_PROPCTRLR_PROPERTYEDITOR_HXX_
|
|
|
|
#include "propertyeditor.hxx"
|
|
|
|
#endif
|
|
|
|
#ifndef _EXTENSIONS_PROPCTRLR_BROWSERPAGE_HXX_
|
|
|
|
#include "browserpage.hxx"
|
|
|
|
#endif
|
2004-11-16 11:11:04 +00:00
|
|
|
#ifndef _EXTENSIONS_PROPCTRLR_LINEDESCRIPTOR_HXX_
|
|
|
|
#include "linedescriptor.hxx"
|
|
|
|
#endif
|
2001-01-12 10:35:45 +00:00
|
|
|
|
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
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//............................................................................
|
|
|
|
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 === **/
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//==================================================================
|
|
|
|
// class OPropertyEditor
|
|
|
|
//==================================================================
|
2001-01-18 13:45:10 +00:00
|
|
|
DBG_NAME(OPropertyEditor)
|
2001-01-12 10:35:45 +00:00
|
|
|
//------------------------------------------------------------------
|
|
|
|
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));
|
2001-02-19 13:08:31 +00:00
|
|
|
m_aTabControl.SetActivatePageHdl(LINK(this, OPropertyEditor, OnPageActivate));
|
2001-01-12 10:35:45 +00:00
|
|
|
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();
|
2004-05-07 15:05:15 +00:00
|
|
|
|
2004-11-16 11:11:04 +00:00
|
|
|
{
|
|
|
|
MapStringToPageId aEmpty;
|
|
|
|
m_aPropertyPageIds.swap( aEmpty );
|
|
|
|
}
|
|
|
|
|
2004-05-07 15:05:15 +00:00
|
|
|
while ( !m_aHiddenPages.empty() )
|
|
|
|
{
|
|
|
|
delete m_aHiddenPages.begin()->second.pPage;
|
|
|
|
m_aHiddenPages.erase( m_aHiddenPages.begin() );
|
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2002-11-06 08:20:07 +00:00
|
|
|
// #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;
|
|
|
|
}
|
|
|
|
|
2003-03-25 15:04:55 +00:00
|
|
|
//------------------------------------------------------------------
|
|
|
|
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();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2001-05-30 12:43:32 +00:00
|
|
|
//------------------------------------------------------------------
|
|
|
|
void OPropertyEditor::GetFocus()
|
|
|
|
{
|
|
|
|
m_aTabControl.GrabFocus();
|
|
|
|
}
|
|
|
|
|
2004-11-16 11:11:04 +00:00
|
|
|
//------------------------------------------------------------------
|
|
|
|
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 );
|
|
|
|
}
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//------------------------------------------------------------------
|
|
|
|
void OPropertyEditor::Resize()
|
|
|
|
{
|
2003-03-25 15:04:55 +00:00
|
|
|
Size aSize( GetOutputSizePixel() );
|
|
|
|
aSize.Width() -= 6;
|
|
|
|
aSize.Height() -= 6;
|
|
|
|
m_aTabControl.SetPosSizePixel( Point( 3, 3 ), aSize );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
|
|
|
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);
|
2004-05-07 15:05:15 +00:00
|
|
|
pPage->SetText( _rText );
|
2001-01-12 10:35:45 +00:00
|
|
|
// some knittings
|
2004-02-04 10:21:27 +00:00
|
|
|
pPage->SetSizePixel(m_aTabControl.GetTabPageSizePixel());
|
2001-01-12 10:35:45 +00:00
|
|
|
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 )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
|
|
|
// let the current page handle this
|
2004-11-16 11:11:04 +00:00
|
|
|
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;
|
2004-11-16 11:11:04 +00:00
|
|
|
|
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 ) );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
return nEntry;
|
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
2004-11-16 11:11:04 +00:00
|
|
|
void OPropertyEditor::RemoveEntry( const ::rtl::OUString& _rName )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:11:04 +00:00
|
|
|
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 );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
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 )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:11:04 +00:00
|
|
|
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 );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
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
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
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;
|
2004-11-16 11:11:04 +00:00
|
|
|
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;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------
|
|
|
|
sal_uInt16 OPropertyEditor::GetPropertyPos( const ::rtl::OUString& rEntryName ) const
|
|
|
|
{
|
|
|
|
sal_uInt16 nVal=LISTBOX_ENTRY_NOTFOUND;
|
2004-11-16 11:11:04 +00:00
|
|
|
const OBrowserPage* pPage = getPage( rEntryName );
|
|
|
|
if ( pPage )
|
|
|
|
nVal = pPage->getListBox()->GetPropertyPos( rEntryName );
|
2001-01-12 10:35:45 +00:00
|
|
|
return nVal;
|
|
|
|
}
|
|
|
|
|
2004-11-16 11:11:04 +00:00
|
|
|
//------------------------------------------------------------------
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2004-05-07 15:05:15 +00:00
|
|
|
//------------------------------------------------------------------
|
|
|
|
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 );
|
2004-05-07 15:05:15 +00:00
|
|
|
}
|
|
|
|
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 );
|
2004-05-07 15:05:15 +00:00
|
|
|
m_aTabControl.SetTabPage( aPagePos->first, aPagePos->second.pPage );
|
|
|
|
|
|
|
|
m_aHiddenPages.erase( aPagePos );
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2004-03-19 11:06:00 +00:00
|
|
|
//------------------------------------------------------------------
|
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 )
|
2004-03-19 11:06:00 +00:00
|
|
|
{
|
|
|
|
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 );
|
2004-03-19 11:06:00 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-10-21 08:06:54 +00:00
|
|
|
//------------------------------------------------------------------
|
|
|
|
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 );
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//------------------------------------------------------------------
|
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)
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
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;
|
2001-01-12 10:35:45 +00:00
|
|
|
// 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;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2001-02-19 13:08:31 +00:00
|
|
|
//------------------------------------------------------------------
|
|
|
|
IMPL_LINK(OPropertyEditor, OnPageActivate, TabControl*, EMPTYARG)
|
|
|
|
{
|
|
|
|
if (m_aPageActivationHandler.IsSet())
|
|
|
|
m_aPageActivationHandler.Call(NULL);
|
|
|
|
return 0L;
|
|
|
|
}
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//------------------------------------------------------------------
|
|
|
|
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();
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
return 1L;
|
|
|
|
}
|
|
|
|
|
|
|
|
//............................................................................
|
|
|
|
} // namespace pcr
|
|
|
|
//............................................................................
|
|
|
|
|
|
|
|
|