2010-10-27 12:45:03 +01:00
|
|
|
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
|
2012-06-21 14:30:25 +01:00
|
|
|
/*
|
|
|
|
|
* This file is part of the LibreOffice project.
|
|
|
|
|
*
|
|
|
|
|
* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
|
*
|
|
|
|
|
* This file incorporates work covered by the following license notice:
|
|
|
|
|
*
|
|
|
|
|
* Licensed to the Apache Software Foundation (ASF) under one or more
|
|
|
|
|
* contributor license agreements. See the NOTICE file distributed
|
|
|
|
|
* with this work for additional information regarding copyright
|
|
|
|
|
* ownership. The ASF licenses this file to you under the Apache
|
|
|
|
|
* License, Version 2.0 (the "License"); you may not use this file
|
|
|
|
|
* except in compliance with the License. You may obtain a copy of
|
|
|
|
|
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
|
|
|
|
|
*/
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2014-04-18 20:41:29 +02:00
|
|
|
#ifndef INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_USERCONTROL_HXX
|
|
|
|
|
#define INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_USERCONTROL_HXX
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
|
#include "commoncontrol.hxx"
|
|
|
|
|
#include <svtools/fmtfield.hxx>
|
2004-03-19 11:08:20 +00:00
|
|
|
#include <svtools/fileurlbox.hxx>
|
|
|
|
|
#include "standardcontrol.hxx"
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
|
class SvNumberFormatsSupplierObj;
|
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
namespace pcr
|
|
|
|
|
{
|
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
//= NumberFormatSampleField
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
class NumberFormatSampleField : public ControlWindow< FormattedField >
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
private:
|
|
|
|
|
typedef ControlWindow< FormattedField > BaseClass;
|
|
|
|
|
|
|
|
|
|
public:
|
2014-09-23 11:20:40 +02:00
|
|
|
NumberFormatSampleField( vcl::Window* _pParent, WinBits _nStyle )
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
:BaseClass( _pParent, _nStyle )
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void SetFormatSupplier( const SvNumberFormatsSupplierObj* pSupplier );
|
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
protected:
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual bool PreNotify( NotifyEvent& rNEvt ) SAL_OVERRIDE;
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
};
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
//= OFormatSampleControl
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
typedef CommonBehaviourControl< ::com::sun::star::inspection::XPropertyControl, NumberFormatSampleField > OFormatSampleControl_Base;
|
|
|
|
|
class OFormatSampleControl : public OFormatSampleControl_Base
|
|
|
|
|
{
|
2001-01-12 10:35:45 +00:00
|
|
|
public:
|
2014-09-23 11:20:40 +02:00
|
|
|
OFormatSampleControl( vcl::Window* pParent, WinBits nWinStyle );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
// XPropertyControl
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual ::com::sun::star::uno::Any SAL_CALL getValue() throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
|
virtual void SAL_CALL setValue( const ::com::sun::star::uno::Any& _value ) throw (::com::sun::star::beans::IllegalTypeException, ::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
|
virtual ::com::sun::star::uno::Type SAL_CALL getValueType() throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
inline void SetFormatSupplier( const SvNumberFormatsSupplierObj* _pSupplier )
|
|
|
|
|
{
|
|
|
|
|
getTypedControlWindow()->SetFormatSupplier( _pSupplier );
|
|
|
|
|
}
|
2007-11-20 18:53:16 +00:00
|
|
|
|
|
|
|
|
/** returns the default preview value for the given format key
|
|
|
|
|
*
|
|
|
|
|
* \param _pNF the number formatter
|
|
|
|
|
* \param _nFormatKey the format key
|
|
|
|
|
* \return current date or time or the value 1234.56789
|
|
|
|
|
*/
|
|
|
|
|
static double getPreviewValue(SvNumberFormatter* _pNF,sal_Int32 _nFormatKey);
|
2009-12-17 11:15:02 +01:00
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
static double getPreviewValue( const SvNumberformat& i_rEntry );
|
2001-01-12 10:35:45 +00:00
|
|
|
};
|
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//= FormatDescription
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
struct FormatDescription
|
|
|
|
|
{
|
|
|
|
|
SvNumberFormatsSupplierObj* pSupplier;
|
|
|
|
|
sal_Int32 nKey;
|
|
|
|
|
};
|
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//= OFormattedNumericControl
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
typedef CommonBehaviourControl< ::com::sun::star::inspection::XPropertyControl, ControlWindow< FormattedField > > OFormattedNumericControl_Base;
|
|
|
|
|
class OFormattedNumericControl : public OFormattedNumericControl_Base
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
private:
|
|
|
|
|
sal_Int32 m_nLastDecimalDigits;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
|
public:
|
2014-09-23 11:20:40 +02:00
|
|
|
OFormattedNumericControl( vcl::Window* pParent, WinBits nWinStyle = WB_TABSTOP);
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
|
|
|
|
|
// XPropertyControl
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual ::com::sun::star::uno::Any SAL_CALL getValue() throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
|
virtual void SAL_CALL setValue( const ::com::sun::star::uno::Any& _value ) throw (::com::sun::star::beans::IllegalTypeException, ::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
|
virtual ::com::sun::star::uno::Type SAL_CALL getValueType() throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
void SetFormatDescription( const FormatDescription& rDesc );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
// make some FormattedField methods available
|
|
|
|
|
void SetDecimalDigits(sal_uInt16 nPrecision) { getTypedControlWindow()->SetDecimalDigits(nPrecision); m_nLastDecimalDigits = nPrecision; }
|
|
|
|
|
void SetDefaultValue(double dDef) { getTypedControlWindow()->SetDefaultValue(dDef); }
|
2014-05-08 11:41:58 +02:00
|
|
|
void EnableEmptyField(bool bEnable) { getTypedControlWindow()->EnableEmptyField(bEnable); }
|
|
|
|
|
void SetThousandsSep(bool bEnable) { getTypedControlWindow()->SetThousandsSep(bEnable); }
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
protected:
|
2014-04-01 19:18:35 +02:00
|
|
|
virtual ~OFormattedNumericControl();
|
2001-01-12 10:35:45 +00:00
|
|
|
};
|
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2004-03-19 11:08:20 +00:00
|
|
|
//= OFileUrlControl
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
typedef CommonBehaviourControl< ::com::sun::star::inspection::XPropertyControl, ControlWindow< ::svt::FileURLBox > > OFileUrlControl_Base;
|
|
|
|
|
class OFileUrlControl : public OFileUrlControl_Base
|
2004-03-19 11:08:20 +00:00
|
|
|
{
|
|
|
|
|
public:
|
2014-09-23 11:20:40 +02:00
|
|
|
OFileUrlControl( vcl::Window* pParent, WinBits nWinStyle );
|
2004-03-19 11:08:20 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
// XPropertyControl
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual ::com::sun::star::uno::Any SAL_CALL getValue() throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
|
virtual void SAL_CALL setValue( const ::com::sun::star::uno::Any& _value ) throw (::com::sun::star::beans::IllegalTypeException, ::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
|
virtual ::com::sun::star::uno::Type SAL_CALL getValueType() throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
2004-03-19 11:08:20 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
protected:
|
2014-04-01 19:18:35 +02:00
|
|
|
virtual ~OFileUrlControl();
|
2004-03-19 11:08:20 +00:00
|
|
|
};
|
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
//= OTimeDurationControl
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
class OTimeDurationControl : public ONumericControl
|
2004-03-19 11:08:20 +00:00
|
|
|
{
|
|
|
|
|
public:
|
2014-09-23 11:20:40 +02:00
|
|
|
OTimeDurationControl( vcl::Window* pParent, WinBits nWinStyle );
|
2014-04-01 19:18:35 +02:00
|
|
|
virtual ~OTimeDurationControl();
|
2004-03-19 11:08:20 +00:00
|
|
|
|
2007-05-10 09:50:51 +00:00
|
|
|
// XPropertyControl
|
2014-03-27 18:12:18 +01:00
|
|
|
::sal_Int16 SAL_CALL getControlType() throw (::com::sun::star::uno::RuntimeException) SAL_OVERRIDE;
|
2007-05-10 09:50:51 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.3.294); FILE MERGED
2005/10/05 07:14:42 fs 1.3.294.3: RESYNC: (1.3-1.4); FILE MERGED
2005/09/05 07:41:56 fs 1.3.294.2: #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/09 14:00:09 fs 1.3.294.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:34:36 +00:00
|
|
|
private:
|
|
|
|
|
DECL_LINK( OnCustomConvert, MetricField* );
|
2004-03-19 11:08:20 +00:00
|
|
|
};
|
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
} // namespace pcr
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2014-04-18 20:41:29 +02:00
|
|
|
#endif // INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_USERCONTROL_HXX
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2010-10-27 12:45:03 +01:00
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|