2010-10-12 15:57:08 +02:00
|
|
|
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
|
2001-01-12 10:35:45 +00:00
|
|
|
/*************************************************************************
|
|
|
|
*
|
2008-04-11 10:11:36 +00:00
|
|
|
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2010-02-12 15:01:35 +01:00
|
|
|
* Copyright 2000, 2010 Oracle and/or its affiliates.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2008-04-11 10:11:36 +00:00
|
|
|
* OpenOffice.org - a multi-platform office productivity suite
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2008-04-11 10:11:36 +00:00
|
|
|
* This file is part of OpenOffice.org.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2008-04-11 10:11:36 +00:00
|
|
|
* OpenOffice.org is free software: you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU Lesser General Public License version 3
|
|
|
|
* only, as published by the Free Software Foundation.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2008-04-11 10:11:36 +00:00
|
|
|
* OpenOffice.org is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU Lesser General Public License version 3 for more details
|
|
|
|
* (a copy is included in the LICENSE file that accompanied this code).
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
2008-04-11 10:11:36 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public License
|
|
|
|
* version 3 along with OpenOffice.org. If not, see
|
|
|
|
* <http://www.openoffice.org/license.html>
|
|
|
|
* for a copy of the LGPLv3 License.
|
2001-01-12 10:35:45 +00:00
|
|
|
*
|
|
|
|
************************************************************************/
|
|
|
|
|
|
|
|
#include "pcrcommon.hxx"
|
|
|
|
#include "modulepcr.hxx"
|
|
|
|
#include "propresid.hrc"
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.2.490); FILE MERGED
2006/03/07 09:57:08 fs 1.2.490.6: correct :getHelpId
2005/10/17 10:27:59 fs 1.2.490.5: #i53095# make numeric field exchange its values as double
2005/10/17 07:17:04 fs 1.2.490.4: replace MeasurementUnit with css.util.MeasureUnit
2005/10/14 12:43:46 fs 1.2.490.3: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 07:03:31 fs 1.2.490.2: RESYNC: (1.2-1.3); FILE MERGED
2005/09/05 07:41:52 fs 1.2.490.1: #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.
2006-03-14 10:27:28 +00:00
|
|
|
/** === begin UNO includes === **/
|
|
|
|
#include <com/sun/star/util/MeasureUnit.hpp>
|
|
|
|
/** === end UNO includes === **/
|
|
|
|
#include <rtl/ustrbuf.hxx>
|
2010-07-20 14:50:49 +02:00
|
|
|
#include <tools/urlobj.hxx>
|
INTEGRATION: CWS pbrwuno (1.2.490); FILE MERGED
2006/03/07 09:57:08 fs 1.2.490.6: correct :getHelpId
2005/10/17 10:27:59 fs 1.2.490.5: #i53095# make numeric field exchange its values as double
2005/10/17 07:17:04 fs 1.2.490.4: replace MeasurementUnit with css.util.MeasureUnit
2005/10/14 12:43:46 fs 1.2.490.3: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 07:03:31 fs 1.2.490.2: RESYNC: (1.2-1.3); FILE MERGED
2005/09/05 07:41:52 fs 1.2.490.1: #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.
2006-03-14 10:27:28 +00:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
//............................................................................
|
|
|
|
namespace pcr
|
|
|
|
{
|
|
|
|
//............................................................................
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.2.490); FILE MERGED
2006/03/07 09:57:08 fs 1.2.490.6: correct :getHelpId
2005/10/17 10:27:59 fs 1.2.490.5: #i53095# make numeric field exchange its values as double
2005/10/17 07:17:04 fs 1.2.490.4: replace MeasurementUnit with css.util.MeasureUnit
2005/10/14 12:43:46 fs 1.2.490.3: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 07:03:31 fs 1.2.490.2: RESYNC: (1.2-1.3); FILE MERGED
2005/09/05 07:41:52 fs 1.2.490.1: #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.
2006-03-14 10:27:28 +00:00
|
|
|
using namespace ::com::sun::star::util;
|
|
|
|
|
|
|
|
//========================================================================
|
|
|
|
//= HelpIdUrl
|
|
|
|
//========================================================================
|
|
|
|
//------------------------------------------------------------------------
|
2010-06-04 13:46:22 +02:00
|
|
|
rtl::OString HelpIdUrl::getHelpId( const ::rtl::OUString& _rHelpURL )
|
INTEGRATION: CWS pbrwuno (1.2.490); FILE MERGED
2006/03/07 09:57:08 fs 1.2.490.6: correct :getHelpId
2005/10/17 10:27:59 fs 1.2.490.5: #i53095# make numeric field exchange its values as double
2005/10/17 07:17:04 fs 1.2.490.4: replace MeasurementUnit with css.util.MeasureUnit
2005/10/14 12:43:46 fs 1.2.490.3: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 07:03:31 fs 1.2.490.2: RESYNC: (1.2-1.3); FILE MERGED
2005/09/05 07:41:52 fs 1.2.490.1: #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.
2006-03-14 10:27:28 +00:00
|
|
|
{
|
2010-07-20 14:50:49 +02:00
|
|
|
INetURLObject aHID( _rHelpURL );
|
|
|
|
if ( aHID.GetProtocol() == INET_PROT_HID )
|
|
|
|
return rtl::OUStringToOString( aHID.GetURLPath(), RTL_TEXTENCODING_UTF8 );
|
|
|
|
else
|
|
|
|
return rtl::OUStringToOString( _rHelpURL, RTL_TEXTENCODING_UTF8 );
|
INTEGRATION: CWS pbrwuno (1.2.490); FILE MERGED
2006/03/07 09:57:08 fs 1.2.490.6: correct :getHelpId
2005/10/17 10:27:59 fs 1.2.490.5: #i53095# make numeric field exchange its values as double
2005/10/17 07:17:04 fs 1.2.490.4: replace MeasurementUnit with css.util.MeasureUnit
2005/10/14 12:43:46 fs 1.2.490.3: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 07:03:31 fs 1.2.490.2: RESYNC: (1.2-1.3); FILE MERGED
2005/09/05 07:41:52 fs 1.2.490.1: #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.
2006-03-14 10:27:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//------------------------------------------------------------------------
|
2010-07-10 18:21:24 +02:00
|
|
|
::rtl::OUString HelpIdUrl::getHelpURL( const rtl::OString& sHelpId )
|
INTEGRATION: CWS pbrwuno (1.2.490); FILE MERGED
2006/03/07 09:57:08 fs 1.2.490.6: correct :getHelpId
2005/10/17 10:27:59 fs 1.2.490.5: #i53095# make numeric field exchange its values as double
2005/10/17 07:17:04 fs 1.2.490.4: replace MeasurementUnit with css.util.MeasureUnit
2005/10/14 12:43:46 fs 1.2.490.3: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 07:03:31 fs 1.2.490.2: RESYNC: (1.2-1.3); FILE MERGED
2005/09/05 07:41:52 fs 1.2.490.1: #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.
2006-03-14 10:27:28 +00:00
|
|
|
{
|
|
|
|
::rtl::OUStringBuffer aBuffer;
|
2011-09-27 20:21:15 +02:00
|
|
|
::rtl::OUString aTmp( rtl::OStringToOUString(sHelpId, RTL_TEXTENCODING_UTF8) );
|
2010-07-20 14:50:49 +02:00
|
|
|
INetURLObject aHID( aTmp );
|
|
|
|
if ( aHID.GetProtocol() == INET_PROT_NOT_VALID )
|
|
|
|
aBuffer.appendAscii( INET_HID_SCHEME );
|
2010-07-10 18:21:24 +02:00
|
|
|
aBuffer.append( aTmp.getStr() );
|
INTEGRATION: CWS pbrwuno (1.2.490); FILE MERGED
2006/03/07 09:57:08 fs 1.2.490.6: correct :getHelpId
2005/10/17 10:27:59 fs 1.2.490.5: #i53095# make numeric field exchange its values as double
2005/10/17 07:17:04 fs 1.2.490.4: replace MeasurementUnit with css.util.MeasureUnit
2005/10/14 12:43:46 fs 1.2.490.3: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 07:03:31 fs 1.2.490.2: RESYNC: (1.2-1.3); FILE MERGED
2005/09/05 07:41:52 fs 1.2.490.1: #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.
2006-03-14 10:27:28 +00:00
|
|
|
return aBuffer.makeStringAndClear();
|
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
//............................................................................
|
|
|
|
} // namespace pcr
|
|
|
|
//............................................................................
|
|
|
|
|
2010-10-12 15:57:08 +02:00
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|