2001-01-12 10:35:45 +00:00
|
|
|
/*************************************************************************
|
|
|
|
*
|
2005-09-08 19:02:22 +00:00
|
|
|
* OpenOffice.org - a multi-platform office productivity suite
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2005-09-08 19:02:22 +00:00
|
|
|
* $RCSfile: browserline.hxx,v $
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
* $Revision: 1.8 $
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
* last change: $Author: vg $ $Date: 2006-03-14 11:17:13 $
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2005-09-08 19:02:22 +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:02:22 +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:02:22 +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:02:22 +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:02:22 +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
|
|
|
*
|
|
|
|
************************************************************************/
|
|
|
|
|
|
|
|
#ifndef _EXTENSIONS_PROPCTRLR_BROWSERLINE_HXX_
|
|
|
|
#define _EXTENSIONS_PROPCTRLR_BROWSERLINE_HXX_
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
/** === begin UNO includes === **/
|
|
|
|
#ifndef _COM_SUN_STAR_INSPECTION_XPROPERTYCONTROL_HPP_
|
|
|
|
#include <com/sun/star/inspection/XPropertyControl.hpp>
|
2001-01-12 10:35:45 +00:00
|
|
|
#endif
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
/** === end UNO includes === **/
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
#ifndef _SV_FIXED_HXX
|
|
|
|
#include <vcl/fixed.hxx>
|
|
|
|
#endif
|
|
|
|
#ifndef _SV_BUTTON_HXX
|
|
|
|
#include <vcl/button.hxx>
|
|
|
|
#endif
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
|
|
|
|
namespace com { namespace sun { namespace star { namespace inspection { namespace PropertyLineElement
|
|
|
|
{
|
|
|
|
const sal_Int16 CompleteLine = 0x4000;
|
|
|
|
} } } } }
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
//............................................................................
|
|
|
|
namespace pcr
|
|
|
|
{
|
|
|
|
//............................................................................
|
|
|
|
|
2004-11-16 11:00:32 +00:00
|
|
|
class OBrowserLine;
|
|
|
|
|
|
|
|
//========================================================================
|
|
|
|
class IButtonClickListener
|
|
|
|
{
|
|
|
|
public:
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
virtual void buttonClicked( OBrowserLine* _pLine, sal_Bool _bPrimary ) = 0;
|
2004-11-16 11:00:32 +00:00
|
|
|
};
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//========================================================================
|
|
|
|
class OBrowserLine
|
|
|
|
{
|
|
|
|
private:
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
::rtl::OUString m_sEntryName;
|
|
|
|
FixedText m_aFtTitle;
|
|
|
|
Size m_aOutputSize;
|
|
|
|
Point m_aLinePos;
|
|
|
|
::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >
|
|
|
|
m_xControl;
|
|
|
|
Window* m_pControlWindow;
|
|
|
|
PushButton* m_pBrowseButton;
|
|
|
|
PushButton* m_pAdditionalBrowseButton;
|
|
|
|
IButtonClickListener* m_pClickListener;
|
|
|
|
Window* m_pTheParent;
|
|
|
|
sal_uInt16 m_nNameWidth;
|
|
|
|
sal_uInt16 m_nEnableFlags;
|
|
|
|
sal_Bool m_bIndentTitle : 1;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
public:
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
OBrowserLine( const ::rtl::OUString& _rEntryName, Window* pParent);
|
|
|
|
~OBrowserLine();
|
|
|
|
|
|
|
|
void setControl( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& _rxControl );
|
|
|
|
const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& getControl()
|
|
|
|
{
|
|
|
|
return m_xControl;
|
|
|
|
}
|
|
|
|
inline const Window* getControlWindow() const
|
|
|
|
{
|
|
|
|
return m_pControlWindow;
|
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
const ::rtl::OUString&
|
|
|
|
GetEntryName() const { return m_sEntryName; }
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
void SetComponentHelpIds( sal_uInt32 _nControlId, sal_uInt32 _bPrimaryButtonId, sal_uInt32 _nSecondaryButtonId );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
void SetTitle(const String& rString );
|
|
|
|
void FullFillTitleString();
|
|
|
|
String GetTitle() const;
|
|
|
|
void SetTitleWidth(sal_uInt16);
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
void SetPosPixel(Point aPos);
|
|
|
|
void SetPosSizePixel(Point aPos,Size aSize);
|
|
|
|
Size GetSizePixel();
|
|
|
|
void Show(sal_Bool bFlag=sal_True);
|
|
|
|
void Hide();
|
|
|
|
sal_Bool IsVisible();
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
Window* GetRefWindow();
|
|
|
|
void SetTabOrder(Window* pRefWindow, sal_uInt16 nFlags );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
sal_Bool GrabFocus();
|
|
|
|
void ShowBrowseButton( const Image& _rImage, sal_Bool _bPrimary );
|
|
|
|
void HideBrowseButton( sal_Bool _bPrimary );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
void EnablePropertyControls( sal_Int16 _nControls, bool _bEnable );
|
|
|
|
void EnablePropertyLine( bool _bEnable );
|
|
|
|
sal_Bool IsPropertyInputEnabled( ) const;
|
2004-11-16 11:00:32 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
void SetClickListener( IButtonClickListener* _pListener );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
void IndentTitle( sal_Bool _bIndent );
|
2004-11-16 11:00:32 +00:00
|
|
|
|
|
|
|
private:
|
|
|
|
DECL_LINK( OnButtonClicked, PushButton* );
|
|
|
|
DECL_LINK( OnButtonFocus, PushButton* );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
void implHideBrowseButton( sal_Bool _bPrimary, bool _bReLayout );
|
2004-11-16 11:00:32 +00:00
|
|
|
void implUpdateEnabledDisabled();
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.6.158); FILE MERGED
2005/10/11 13:28:42 fs 1.6.158.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:56 fs 1.6.158.5: RESYNC: (1.6-1.7); FILE MERGED
2005/09/05 07:41:46 fs 1.6.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/31 08:28:52 fs 1.6.158.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:07 fs 1.6.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 13:59:54 fs 1.6.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:17:13 +00:00
|
|
|
void impl_layoutComponents();
|
|
|
|
};
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
//............................................................................
|
|
|
|
} // namespace pcr
|
|
|
|
//............................................................................
|
|
|
|
|
|
|
|
#endif // _EXTENSIONS_PROPCTRLR_BROWSERLINE_HXX_
|
|
|
|
|