2010-10-12 15:57:08 +02:00
|
|
|
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
|
re-base on ALv2 code. Includes (at least) relevant parts of:
linecap: Reintegrating finished LineCap feature
Patch contributed by Regina Henschel
http://svn.apache.org/viewvc?view=revision&revision=1232507
Patches contributed by Sven Jacobi
impress212: #i81610# fixed animation export
http://svn.apache.org/viewvc?view=revision&revision=1167620
impress212: drawinglayer gbuild environment changes
http://svn.apache.org/viewvc?view=revision&revision=1167627
http://svn.apache.org/viewvc?view=revision&revision=1167628
impress212: DffPropSet -> minor code improvements, removing table
http://svn.apache.org/viewvc?view=revision&revision=1167634
impress212: #158494# fixed excel import (text rotation)
http://svn.apache.org/viewvc?view=revision&revision=1167638
Patches contributed by Armin Le Grand
Svg: Reintegrated Svg replacement from /branches/alg/svgreplavement
http://svn.apache.org/viewvc?view=revision&revision=1220836
#118728# changed indentifying definitions for Svg file detection
http://svn.apache.org/viewvc?view=revision&revision=1229961
#118838# LineGeometry creation for complicated cases optimized to
create single Polygons
http://svn.apache.org/viewvc?view=revision&revision=1236232
#119176# corrected file type detection for SVG for svg files
without xml header
http://svn.apache.org/viewvc?view=revision&revision=1309445
#118728# Extended Svg file detection
http://svn.apache.org/viewvc?view=revision&revision=1230531
#118529# solve break converters and convert commands for OLEs and images
http://svn.apache.org/viewvc?view=revision&revision=1186168
svg: added WaE changes from branch svgreplacement to trunc
http://svn.apache.org/viewvc?view=revision&revision=1222974
svg: corrected missing member initialization
http://svn.apache.org/viewvc?view=revision&revision=1226134
fix for #118525#: Using primitives for chart sub-geometry visualisation
http://svn.apache.org/viewvc?view=revision&revision=1226879
#118898# Adapted ImpGraphic::ImplGetBitmap to correctly convert
metafiles to bitmapEx ...
http://svn.apache.org/viewvc?view=revision&revision=1293316
fix for #118525#: removed no longer used variable maOriginalMapMode, one
more exception eliminated
http://svn.apache.org/viewvc?view=revision&revision=1227097
#16758# Added buffering to the VDev usages of the VclProcessor2D derivates...
http://svn.apache.org/viewvc?view=revision&revision=1229521
#116758# Secured VDev buffer device to Vcl deinit
http://svn.apache.org/viewvc?view=revision&revision=1230574
#116758# added remembering allocated VDevs for VDevBuffer to be able to also
delete these when vcl goes down; it should never happen, but You never know
http://svn.apache.org/viewvc?view=revision&revision=1230927
#118730# Changed SvgClipPathNode to use MaskPrimitive2D for primitive
representation instead of TransparencePrimitive2D
http://svn.apache.org/viewvc?view=revision&revision=1231198
#118822# secured 3D geometry creation (slices) by subdividing the 2D
source polyPolygon early
http://svn.apache.org/viewvc?view=revision&revision=1234749
#118829# enhanced Svg gradient quality, obstacles avoided
http://svn.apache.org/viewvc?view=revision&revision=1235361
#118834# Unified usage of TextBreakupHelper as single tooling class
for i18n text primitive breakup
http://svn.apache.org/viewvc?view=revision&revision=1236110
#118853# added square pixel size limit to conversion of
TransparencePrimitive2D to Metafile action
http://svn.apache.org/viewvc?view=revision&revision=1237656
#118824# coreccted mirroring and boundrect when the graphicmanager
is used for bitmap output
http://svn.apache.org/viewvc?view=revision&revision=1240097
#115092# Corrected VclProcessor2D::RenderPolygonStrokePrimitive2D for
various optimization scenarios
http://svn.apache.org/viewvc?view=revision&revision=1241434
#118783# Corrected errors in ID strings, corrected Svg line/fill export,
corrected polygon close state
http://svn.apache.org/viewvc?view=revision&revision=1232006
#118796# corrected null-pointer usage in SVG text exporter
http://svn.apache.org/viewvc?view=revision&revision=1240262
#118729# Use GraphicStreamUrl and GraphicUrl to allow multi image
import with linked graphics, too
http://svn.apache.org/viewvc?view=revision&revision=1229962
#118898# corrected error in GDIMetaFile::GetBoundRect in handling
MetaFloatTransparentAction
http://svn.apache.org/viewvc?view=revision&revision=1293349
#118855# Corrected handling of possibly created empty clipRegions
after PolyPolygon clipping
http://svn.apache.org/viewvc?view=revision&revision=1237725
#115962# Better (but not yet optimal, see comments in task) handling
of MetaFloatTransparentAction in PDF export
http://svn.apache.org/viewvc?view=revision&revision=1241078
IP clearance: #118466# This patch removes librsvg, libcroco, libgsf, ...
http://svn.apache.org/viewvc?view=revision&revision=1200879
118779# Added svg content streaming in/out to ImpGraphic stream operators
http://svn.apache.org/viewvc?view=revision&revision=1231908
linecap: correctons for WaE and mac drawing
http://svn.apache.org/viewvc?view=revision&revision=1232793
svg: uses current system Dpi for Svg replacement image creation
http://svn.apache.org/viewvc?view=revision&revision=1233948
Patches contributed by Mathias Bauer (and others)
gnumake4 work variously
http://svn.apache.org/viewvc?view=revision&revision=1394326
http://svn.apache.org/viewvc?view=revision&revision=1396797
http://svn.apache.org/viewvc?view=revision&revision=1397315
http://svn.apache.org/viewvc?view=revision&revision=1394326
Remove duplicate header includes.
cws mba34issues01: #i117720#: convert assertion into warning
http://svn.apache.org/viewvc?view=revision&revision=1172352
118485 - Styles for OLEs are not saved. Submitted by Armin Le Grand.
http://svn.apache.org/viewvc?view=revision&revision=1182166
cws mba34issues01: #i117714#: remove assertion
http://svn.apache.org/viewvc?view=revision&revision=1172357
Patch contributed by Jurgen Schmidt
add some additional checks to ensure proper reading operations
http://svn.apache.org/viewvc?view=revision&revision=1209022
mostly prefer our stream / bounds checking work.
Patches contributed by Herbert Duerr
#i118816# add clarifying comment regarding Font::*Color*() methods
http://svn.apache.org/viewvc?view=revision&revision=1233833
extend macro->string handling for empty strings
http://svn.apache.org/viewvc?view=revision&revision=1175801
avoid magic constants for SALCOLOR_NONE
http://svn.apache.org/viewvc?view=revision&revision=1177543
initialize slant properly in ImplFontMetricData constructor (author=iorsh)
http://svn.apache.org/viewvc?view=revision&revision=1177551
#i118675# make check for extension updates more stable
http://svn.apache.org/viewvc?view=revision&revision=1214797
#a118617# remove VBasicEventListener.dll binary
There are no known users depending on its CLSID
http://svn.apache.org/viewvc?view=revision&revision=1203697
Patches contributed by Ariel Constenla-Haile
Fix build breaker on Linux/gcc
http://svn.apache.org/viewvc?view=revision&revision=1221104
Fix crash when trying to instantiate css.graphic.GraphicRasterizer_RSVG
http://svn.apache.org/viewvc?view=revision&revision=1215559
Patches contributed by Oliver-Rainer Wittmann
sw34bf06: #i117962# - method <SwFlyFrm::IsPaint(..)> - consider
instances of <SwFlyDrawObj>
http://svn.apache.org/viewvc?view=revision&revision=1172120
sw34bf06: #i117783# - Writer's implementation of XPagePrintable -
apply print settings to new printing routines
http://svn.apache.org/viewvc?view=revision&revision=1172115
gnumake4 work variously from Hans-Joachim Lankenau
http://svn.apache.org/viewvc?view=revision&revision=1397315
http://svn.apache.org/viewvc?view=revision&revision=1396797
http://svn.apache.org/viewvc?view=revision&revision=1396782
http://svn.apache.org/viewvc?view=revision&revision=1394707
plus some amount of re-splitting of legacy headers.
Patch contributed by Pavel Janik
WaE: Remove unused variables.
http://svn.apache.org/viewvc?view=revision&revision=1230697
Patches contributed by Takashi Ono
mingwport35: i#117795: MinGW port fix for vcl2gnumake
http://svn.apache.org/viewvc?view=revision&revision=1172091
mingwport35: i#117795: MinGW port fix for vcl2gnumake
http://svn.apache.org/viewvc?view=revision&revision=1172091
Patch contributed by Christian Lippka
impress212: #i98044# re enable Text menu for outline and title shapes
http://svn.apache.org/viewvc?view=revision&revision=1167639
Patch contributed by Andre Fischer
118674: Made category B code optional and disabled by default.
http://svn.apache.org/viewvc?view=revision&revision=1215131
118881: Ignore empty paragraphs after bullets.
http://svn.apache.org/viewvc?view=revision&revision=1296205
Patches contributed by Philipp Lohmann
ooo340fixes: #i117780# use rtl allocator
http://svn.apache.org/viewvc?view=revision&revision=1172087
ooo34gsl02: #i117807# fix an off by one error (index actually
inside the pfb section header)
http://svn.apache.org/viewvc?view=revision&revision=1167576
various cleanups, related compilation fixes, warning cleanups, re-working
of obsolete stl template pieces to use boost instead, changed string
classes, re-adapt KDE about data, about dialog, fixing warnings,
and other fixes & improvements.
Disable svg import / render for about/ branding code-paths for now.
Restore full icon theme set.
Remove OS/2 conditionals and sources.
Remove conflicting gtk/full-screen monitors support.
Retain existing svg rasterizer files - temporarily disabled.
Standardize stringificaiton and fixup dllpostfix issues.
Rename SvgGradientHelper::== to equalTo to avoid overloading issues.
Use the flat GdiPlus API for LineCaps calls.
2012-10-09 12:22:23 +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
|
|
|
|
|
|
|
#include "usercontrol.hxx"
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
#include <com/sun/star/inspection/PropertyControlType.hpp>
|
2009-10-16 00:05:16 +02:00
|
|
|
#include <svl/numuno.hxx>
|
2003-03-25 15:04:55 +00:00
|
|
|
#include <rtl/math.hxx>
|
2018-03-15 20:42:13 +09:00
|
|
|
#include <vcl/GraphicObject.hxx>
|
2019-01-30 00:10:38 +01:00
|
|
|
#include <vcl/event.hxx>
|
2001-01-12 10:35:45 +00:00
|
|
|
#include <tools/debug.hxx>
|
2009-10-16 00:05:16 +02:00
|
|
|
#include <svl/zformat.hxx>
|
2007-11-20 18:53:00 +00:00
|
|
|
#include <connectivity/dbconversion.hxx>
|
|
|
|
#include <com/sun/star/util/Time.hpp>
|
2008-12-01 12:31:27 +00:00
|
|
|
#include "modulepcr.hxx"
|
2017-10-23 22:41:56 +02:00
|
|
|
#include <strings.hrc>
|
2009-12-17 11:15:02 +01: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
|
|
|
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
using ::com::sun::star::uno::Any;
|
|
|
|
using ::com::sun::star::uno::Type;
|
2013-04-01 18:45:57 +02:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
namespace PropertyControlType = ::com::sun::star::inspection::PropertyControlType;
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
// NumberFormatSampleField
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2014-01-18 00:18:52 +01:00
|
|
|
bool NumberFormatSampleField::PreNotify( NotifyEvent& rNEvt )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
|
|
|
// want to handle two keys myself : Del/Backspace should empty the window (setting my prop to "standard" this way)
|
2014-11-26 14:53:25 +00:00
|
|
|
if (MouseNotifyEvent::KEYINPUT == rNEvt.GetType())
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
|
|
|
sal_uInt16 nKey = rNEvt.GetKeyEvent()->GetKeyCode().GetCode();
|
|
|
|
|
|
|
|
if ((KEY_DELETE == nKey) || (KEY_BACKSPACE == nKey))
|
|
|
|
{
|
2013-09-19 15:20:39 +02:00
|
|
|
SetText( "" );
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
if ( m_pHelper )
|
2015-10-16 15:09:47 +02:00
|
|
|
m_pHelper->setModified();
|
2014-01-18 00:18:52 +01:00
|
|
|
return true;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-10-09 17:40:07 +02:00
|
|
|
return FormattedField::PreNotify( rNEvt );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
void NumberFormatSampleField::SetFormatSupplier( const SvNumberFormatsSupplierObj* pSupplier )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
if ( pSupplier )
|
|
|
|
{
|
2014-03-20 11:53:43 +02:00
|
|
|
TreatAsNumber( true );
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
|
|
|
|
SvNumberFormatter* pFormatter = pSupplier->GetNumberFormatter();
|
2015-08-12 15:09:57 +02:00
|
|
|
SetFormatter( pFormatter );
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
SetValue( 1234.56789 );
|
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
else
|
|
|
|
{
|
2014-03-20 11:53:43 +02:00
|
|
|
TreatAsNumber( false );
|
2015-11-10 10:14:53 +01:00
|
|
|
SetFormatter( nullptr );
|
2013-09-19 15:20:39 +02:00
|
|
|
SetText( "" );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
// OFormatSampleControl
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2016-09-12 11:32:53 +02:00
|
|
|
OFormatSampleControl::OFormatSampleControl( vcl::Window* pParent )
|
|
|
|
:OFormatSampleControl_Base( PropertyControlType::Unknown, pParent, WB_READONLY | WB_TABSTOP | WB_BORDER )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2015-10-09 17:40:07 +02:00
|
|
|
getTypedControlWindow()->setControlHelper(*this);
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
void SAL_CALL OFormatSampleControl::setValue( const Any& _rValue )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
sal_Int32 nFormatKey = 0;
|
|
|
|
if ( _rValue >>= nFormatKey )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
// else set the new format key, the text will be reformatted
|
|
|
|
getTypedControlWindow()->SetFormatKey( nFormatKey );
|
2007-11-20 18:53:00 +00:00
|
|
|
|
|
|
|
SvNumberFormatter* pNF = getTypedControlWindow()->GetFormatter();
|
2009-12-17 11:15:02 +01:00
|
|
|
const SvNumberformat* pEntry = pNF->GetEntry( nFormatKey );
|
|
|
|
OSL_ENSURE( pEntry, "OFormatSampleControl::setValue: invalid format entry!" );
|
|
|
|
|
|
|
|
const bool bIsTextFormat = ( pEntry && pEntry->IsTextFormat() );
|
|
|
|
if ( bIsTextFormat )
|
2017-05-18 21:14:00 +01:00
|
|
|
getTypedControlWindow()->SetText( PcrRes( RID_STR_TEXT_FORMAT ) );
|
2009-12-17 11:15:02 +01:00
|
|
|
else
|
|
|
|
getTypedControlWindow()->SetValue( pEntry ? getPreviewValue( *pEntry ) : 1234.56789 );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
else
|
2013-09-19 15:20:39 +02:00
|
|
|
getTypedControlWindow()->SetText( "" );
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
}
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2009-12-17 11:15:02 +01:00
|
|
|
double OFormatSampleControl::getPreviewValue( const SvNumberformat& i_rEntry )
|
|
|
|
{
|
|
|
|
double nValue = 1234.56789;
|
2017-12-03 21:46:37 +02:00
|
|
|
switch ( i_rEntry.GetType() & ~SvNumFormatType::DEFINED )
|
2009-12-17 11:15:02 +01:00
|
|
|
{
|
2017-12-03 21:46:37 +02:00
|
|
|
case SvNumFormatType::DATE:
|
2009-12-17 11:15:02 +01:00
|
|
|
{
|
2011-12-01 21:03:42 +01:00
|
|
|
Date aCurrentDate( Date::SYSTEM );
|
2015-09-30 11:48:44 +02:00
|
|
|
static css::util::Date STANDARD_DB_DATE(30,12,1899);
|
2017-04-06 18:32:34 +02:00
|
|
|
nValue = ::dbtools::DBTypeConversion::toDouble(::dbtools::DBTypeConversion::toDate(aCurrentDate.GetDate()),STANDARD_DB_DATE);
|
2009-12-17 11:15:02 +01:00
|
|
|
}
|
|
|
|
break;
|
2017-12-03 21:46:37 +02:00
|
|
|
case SvNumFormatType::TIME:
|
|
|
|
case SvNumFormatType::DATETIME:
|
2009-12-17 11:15:02 +01:00
|
|
|
{
|
2014-09-28 15:49:26 +02:00
|
|
|
tools::Time aCurrentTime( tools::Time::SYSTEM );
|
2009-12-17 11:15:02 +01:00
|
|
|
nValue = ::dbtools::DBTypeConversion::toDouble(::dbtools::DBTypeConversion::toTime(aCurrentTime.GetTime()));
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return nValue;
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-07-31 10:36:32 +02:00
|
|
|
double OFormatSampleControl::getPreviewValue(SvNumberFormatter const * _pNF, sal_Int32 _nFormatKey)
|
2007-11-20 18:53:00 +00:00
|
|
|
{
|
|
|
|
const SvNumberformat* pEntry = _pNF->GetEntry(_nFormatKey);
|
|
|
|
DBG_ASSERT( pEntry, "OFormattedNumericControl::SetFormatDescription: invalid format key!" );
|
|
|
|
double nValue = 1234.56789;
|
|
|
|
if ( pEntry )
|
2009-12-17 11:15:02 +01:00
|
|
|
nValue = getPreviewValue( *pEntry );
|
2007-11-20 18:53:00 +00:00
|
|
|
return nValue;
|
|
|
|
}
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
Any SAL_CALL OFormatSampleControl::getValue()
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
{
|
|
|
|
Any aPropValue;
|
2013-01-21 14:32:09 +01:00
|
|
|
if ( !getTypedControlWindow()->GetText().isEmpty() )
|
2018-01-12 20:24:28 +01:00
|
|
|
aPropValue <<= static_cast<sal_Int32>(getTypedControlWindow()->GetFormatKey());
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
return aPropValue;
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
Type SAL_CALL OFormatSampleControl::getValueType()
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
{
|
2014-05-11 10:09:04 +02:00
|
|
|
return ::cppu::UnoType<sal_Int32>::get();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
// class OFormattedNumericControl
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2014-09-23 11:20:40 +02:00
|
|
|
OFormattedNumericControl::OFormattedNumericControl( vcl::Window* pParent, WinBits nWinStyle )
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
:OFormattedNumericControl_Base( PropertyControlType::Unknown, pParent, nWinStyle )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2014-03-20 11:53:43 +02:00
|
|
|
getTypedControlWindow()->TreatAsNumber(true);
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
OFormattedNumericControl::~OFormattedNumericControl()
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
void SAL_CALL OFormattedNumericControl::setValue( const Any& _rValue )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
double nValue( 0 );
|
|
|
|
if ( _rValue >>= nValue )
|
|
|
|
getTypedControlWindow()->SetValue( nValue );
|
|
|
|
else
|
2013-09-19 15:20:39 +02:00
|
|
|
getTypedControlWindow()->SetText("");
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
Any SAL_CALL OFormattedNumericControl::getValue()
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
Any aPropValue;
|
2013-01-21 14:32:09 +01:00
|
|
|
if ( !getTypedControlWindow()->GetText().isEmpty() )
|
2017-04-06 08:59:07 +02:00
|
|
|
aPropValue <<= getTypedControlWindow()->GetValue();
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
return aPropValue;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
Type SAL_CALL OFormattedNumericControl::getValueType()
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2014-05-11 10:09:04 +02:00
|
|
|
return ::cppu::UnoType<double>::get();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
void OFormattedNumericControl::SetFormatDescription(const FormatDescription& rDesc)
|
|
|
|
{
|
2014-05-08 11:41:58 +02:00
|
|
|
bool bFallback = true;
|
2002-10-18 14:14:13 +00:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
if (rDesc.pSupplier)
|
|
|
|
{
|
2014-03-20 11:53:43 +02:00
|
|
|
getTypedControlWindow()->TreatAsNumber(true);
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
SvNumberFormatter* pFormatter = rDesc.pSupplier->GetNumberFormatter();
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
if (pFormatter != getTypedControlWindow()->GetFormatter())
|
2015-08-12 15:09:57 +02:00
|
|
|
getTypedControlWindow()->SetFormatter(pFormatter);
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
getTypedControlWindow()->SetFormatKey(rDesc.nKey);
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
const SvNumberformat* pEntry = getTypedControlWindow()->GetFormatter()->GetEntry(getTypedControlWindow()->GetFormatKey());
|
2002-10-18 14:14:13 +00:00
|
|
|
DBG_ASSERT( pEntry, "OFormattedNumericControl::SetFormatDescription: invalid format key!" );
|
|
|
|
if ( pEntry )
|
2001-02-13 14:36:13 +00:00
|
|
|
{
|
2014-05-08 11:41:58 +02:00
|
|
|
bFallback = false;
|
2001-02-13 14:36:13 +00:00
|
|
|
}
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
2002-10-18 14:14:13 +00:00
|
|
|
|
|
|
|
if ( bFallback )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2014-03-20 11:53:43 +02:00
|
|
|
getTypedControlWindow()->TreatAsNumber(false);
|
2015-11-10 10:14:53 +01:00
|
|
|
getTypedControlWindow()->SetFormatter(nullptr);
|
2013-09-19 15:20:39 +02:00
|
|
|
getTypedControlWindow()->SetText("");
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2004-03-19 11:08:07 +00:00
|
|
|
//= OFileUrlControl
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2016-09-12 11:32:53 +02:00
|
|
|
OFileUrlControl::OFileUrlControl( vcl::Window* pParent )
|
|
|
|
:OFileUrlControl_Base( PropertyControlType::Unknown, pParent, WB_TABSTOP | WB_BORDER | WB_DROPDOWN )
|
2004-03-19 11:08:07 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
getTypedControlWindow()->SetDropDownLineCount( 10 );
|
2017-05-18 21:14:00 +01:00
|
|
|
getTypedControlWindow()->SetPlaceHolder( PcrRes( RID_EMBED_IMAGE_PLACEHOLDER ) ) ;
|
2004-03-19 11:08:07 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2004-03-19 11:08:07 +00:00
|
|
|
OFileUrlControl::~OFileUrlControl()
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
void SAL_CALL OFileUrlControl::setValue( const Any& _rValue )
|
2004-03-19 11:08:07 +00:00
|
|
|
{
|
2013-04-07 12:06:47 +02:00
|
|
|
OUString sURL;
|
2017-07-05 08:32:57 +02:00
|
|
|
if ( _rValue >>= sURL )
|
2008-12-01 12:31:27 +00:00
|
|
|
{
|
2018-03-15 20:42:13 +09:00
|
|
|
if (GraphicObject::isGraphicObjectUniqueIdURL(sURL))
|
2008-12-01 12:31:27 +00:00
|
|
|
getTypedControlWindow()->DisplayURL( getTypedControlWindow()->GetPlaceHolder() );
|
|
|
|
else
|
|
|
|
getTypedControlWindow()->DisplayURL( sURL );
|
|
|
|
}
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
else
|
2013-09-19 15:20:39 +02:00
|
|
|
getTypedControlWindow()->SetText( "" );
|
2004-03-19 11:08:07 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
Any SAL_CALL OFileUrlControl::getValue()
|
2004-03-19 11:08:07 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
Any aPropValue;
|
2013-01-21 14:32:09 +01:00
|
|
|
if ( !getTypedControlWindow()->GetText().isEmpty() )
|
2014-10-01 11:11:44 +02:00
|
|
|
aPropValue <<= getTypedControlWindow()->GetURL();
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
return aPropValue;
|
2004-03-19 11:08:07 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
Type SAL_CALL OFileUrlControl::getValueType()
|
2004-03-19 11:08:07 +00:00
|
|
|
{
|
2014-05-11 10:09:04 +02:00
|
|
|
return ::cppu::UnoType<OUString>::get();
|
2004-03-19 11:08:07 +00:00
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
//= OTimeDurationControl
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2016-09-12 11:32:53 +02:00
|
|
|
OTimeDurationControl::OTimeDurationControl( vcl::Window* pParent )
|
|
|
|
:ONumericControl( pParent, WB_BORDER | WB_TABSTOP )
|
2004-03-19 11:08:07 +00:00
|
|
|
{
|
2018-11-06 14:37:23 +03:00
|
|
|
getTypedControlWindow()->SetUnit( FieldUnit::CUSTOM );
|
2015-11-06 09:35:47 +01:00
|
|
|
getTypedControlWindow()->SetCustomUnitText(" ms");
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
getTypedControlWindow()->SetCustomConvertHdl( LINK( this, OTimeDurationControl, OnCustomConvert ) );
|
2004-03-19 11:08:07 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
OTimeDurationControl::~OTimeDurationControl()
|
2004-03-19 11:08:07 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
::sal_Int16 SAL_CALL OTimeDurationControl::getControlType()
|
2007-05-10 09:50:39 +00:00
|
|
|
{
|
|
|
|
// don't use the base class'es method, it would claim we're a standard control, which
|
|
|
|
// we in fact aren't
|
|
|
|
return PropertyControlType::Unknown;
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2016-10-05 07:56:12 +02:00
|
|
|
IMPL_LINK_NOARG( OTimeDurationControl, OnCustomConvert, MetricFormatter&, void )
|
2004-03-19 11:08:07 +00:00
|
|
|
{
|
|
|
|
long nMultiplier = 1;
|
2013-02-06 16:19:18 +01:00
|
|
|
if ( getTypedControlWindow()->GetCurUnitText().equalsIgnoreAsciiCase( "ms" ) )
|
2004-03-19 11:08:07 +00:00
|
|
|
nMultiplier = 1;
|
2013-02-06 16:19:18 +01:00
|
|
|
if ( getTypedControlWindow()->GetCurUnitText().equalsIgnoreAsciiCase( "s" ) )
|
2004-03-19 11:08:07 +00:00
|
|
|
nMultiplier = 1000;
|
2013-02-06 16:19:18 +01:00
|
|
|
else if ( getTypedControlWindow()->GetCurUnitText().equalsIgnoreAsciiCase( "m" ) )
|
2007-05-10 09:50:39 +00:00
|
|
|
nMultiplier = 1000 * 60;
|
2013-02-06 16:19:18 +01:00
|
|
|
else if ( getTypedControlWindow()->GetCurUnitText().equalsIgnoreAsciiCase( "h" ) )
|
2004-03-19 11:08:07 +00:00
|
|
|
nMultiplier = 1000 * 60 * 60;
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.5.294); FILE MERGED
2005/10/05 07:14:31 fs 1.5.294.3: RESYNC: (1.5-1.6); FILE MERGED
2005/09/05 07:41:55 fs 1.5.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.5.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:25 +00:00
|
|
|
getTypedControlWindow()->SetValue( getTypedControlWindow()->GetLastValue() * nMultiplier );
|
2004-03-19 11:08:07 +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
|
|
|
|
2010-10-12 15:57:08 +02:00
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|