2010-10-27 12:45:03 +01: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
|
|
|
|
2014-04-18 20:41:29 +02:00
|
|
|
#ifndef INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_COMMONCONTROL_HXX
|
|
|
|
#define INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_COMMONCONTROL_HXX
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
#include <com/sun/star/inspection/XPropertyControl.hpp>
|
|
|
|
#include <com/sun/star/lang/DisposedException.hpp>
|
|
|
|
#include <cppuhelper/compbase1.hxx>
|
|
|
|
#include <comphelper/broadcasthelper.hxx>
|
|
|
|
#include <tools/link.hxx>
|
2001-01-12 10:35:45 +00:00
|
|
|
#include <vcl/window.hxx>
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
class NotifyEvent;
|
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.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
class ControlHelper;
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
template< class WINDOW >
|
|
|
|
class ControlWindow : public WINDOW
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
|
|
|
protected:
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
typedef WINDOW WindowType;
|
|
|
|
|
|
|
|
protected:
|
|
|
|
ControlHelper* m_pHelper;
|
|
|
|
|
|
|
|
public:
|
2014-09-23 11:20:40 +02:00
|
|
|
ControlWindow( vcl::Window* _pParent, WinBits _nStyle )
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
:WindowType( _pParent, _nStyle )
|
|
|
|
,m_pHelper( NULL )
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
/// sets a ControlHelper instance which some functionality is delegated to
|
2007-05-10 09:47:04 +00:00
|
|
|
inline virtual void setControlHelper( ControlHelper& _rControlHelper );
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
|
|
|
|
protected:
|
|
|
|
// Window overridables
|
2014-01-18 00:18:52 +01:00
|
|
|
inline virtual bool PreNotify( NotifyEvent& rNEvt );
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
};
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
//= IModifyListener
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
class SAL_NO_VTABLE IModifyListener
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
virtual void modified() = 0;
|
2012-03-14 13:27:56 +01:00
|
|
|
|
|
|
|
protected:
|
|
|
|
~IModifyListener() {}
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
};
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
//= ControlHelper
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
/** A helper class for implementing the <type scope="com::sun::star::inspection">XPropertyControl</type>
|
|
|
|
or one of its derived interfaces.
|
|
|
|
|
|
|
|
This class is intended to be held as member of another class which implements the
|
|
|
|
<type scope="com::sun::star::inspection">XPropertyControl</type> interface. The pointer
|
|
|
|
to this interface is to be passed to the ctor.
|
|
|
|
*/
|
|
|
|
class ControlHelper
|
|
|
|
{
|
|
|
|
private:
|
2015-03-09 14:29:30 +02:00
|
|
|
VclPtr<vcl::Window> m_pControlWindow;
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
sal_Int16 m_nControlType;
|
|
|
|
::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControlContext >
|
|
|
|
m_xContext;
|
|
|
|
::com::sun::star::inspection::XPropertyControl&
|
|
|
|
m_rAntiImpl;
|
|
|
|
IModifyListener* m_pModifyListener;
|
2014-04-30 11:46:15 +02:00
|
|
|
bool m_bModified;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
public:
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
/** creates the instance
|
|
|
|
@param _rControlWindow
|
|
|
|
the window which is associated with the <type scope="com::sun::star::inspection">XPropertyControl</type>.
|
|
|
|
Must not be <NULL/>.<br/>
|
|
|
|
Ownership for this window is taken by the ControlHelper - it will be deleted in <member>disposing</member>.
|
|
|
|
@param _nControlType
|
|
|
|
the type of the control - one of the <type scope="com::sun::star::inspection">PropertyControlType</type>
|
|
|
|
constants
|
|
|
|
@param _pAntiImpl
|
|
|
|
Reference to the instance as whose "impl-class" we act. This reference is held during lifetime
|
|
|
|
of the <type>ControlHelper</type> class, within acquiring it. Thus, the owner of the
|
|
|
|
<type>ControlHelper</type> is responsible for assuring the lifetime of the instance
|
|
|
|
pointed to by <arg>_pAntiImpl</arg>.
|
|
|
|
@param _pModifyListener
|
|
|
|
a listener to be modfied when the user modified the control's value. the
|
|
|
|
<member>IModifyListener::modified</member> of this listener is called from within our
|
|
|
|
ModifiedHdl. A default implementation of <member>IModifyListener::modified</member>
|
|
|
|
would just call our <member>setModified</member>.
|
|
|
|
*/
|
|
|
|
ControlHelper(
|
2014-09-23 11:20:40 +02:00
|
|
|
vcl::Window* _pControlWindow,
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
sal_Int16 _nControlType,
|
|
|
|
::com::sun::star::inspection::XPropertyControl& _rAntiImpl,
|
|
|
|
IModifyListener* _pModifyListener );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2006-07-26 06:54:19 +00:00
|
|
|
virtual ~ControlHelper();
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
/** sets our "modified" flag to <TRUE/>
|
|
|
|
*/
|
2014-04-30 11:46:15 +02:00
|
|
|
inline void setModified() { m_bModified = true; }
|
2014-09-23 11:20:40 +02:00
|
|
|
inline vcl::Window* getVclControlWindow() { return m_pControlWindow; }
|
|
|
|
inline const vcl::Window* getVclControlWindow() const { return m_pControlWindow; }
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
public:
|
|
|
|
// XPropertyControl
|
2014-06-09 10:09:42 +02:00
|
|
|
::sal_Int16 SAL_CALL getControlType() throw (::com::sun::star::uno::RuntimeException) { return m_nControlType; }
|
2014-06-12 14:06:28 +02:00
|
|
|
::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControlContext > SAL_CALL getControlContext() throw (::com::sun::star::uno::RuntimeException) { return m_xContext; }
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
void SAL_CALL setControlContext( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControlContext >& _controlcontext ) throw (::com::sun::star::uno::RuntimeException);
|
|
|
|
::com::sun::star::uno::Reference< ::com::sun::star::awt::XWindow > SAL_CALL getControlWindow() throw (::com::sun::star::uno::RuntimeException);
|
2014-06-09 10:09:42 +02:00
|
|
|
bool SAL_CALL isModified( ) throw (::com::sun::star::uno::RuntimeException) { return m_bModified; }
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
void SAL_CALL notifyModifiedValue( ) throw (::com::sun::star::uno::RuntimeException);
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
// XComponent
|
2015-06-09 08:55:13 +02:00
|
|
|
void SAL_CALL dispose();
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
/** (fail-safe) wrapper around calling our context's activateNextControl
|
|
|
|
*/
|
|
|
|
inline void activateNextControl() const { impl_activateNextControl_nothrow(); }
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
public:
|
|
|
|
/// may be used to implement the default handling in PreNotify; returns sal_True if handled
|
|
|
|
bool handlePreNotify(NotifyEvent& _rNEvt);
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
/// automatically size the window given in the ctor
|
|
|
|
void autoSizeWindow();
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
/// may be used by derived classes, they forward the event to the PropCtrListener
|
2014-09-23 11:20:40 +02:00
|
|
|
DECL_LINK( ModifiedHdl, vcl::Window* );
|
|
|
|
DECL_LINK( GetFocusHdl, vcl::Window* );
|
|
|
|
DECL_LINK( LoseFocusHdl, vcl::Window* );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
private:
|
|
|
|
/** fail-safe wrapper around calling our context's activateNextControl
|
|
|
|
*/
|
|
|
|
void impl_activateNextControl_nothrow() const;
|
|
|
|
};
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
//= CommonBehaviourControl
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
/** implements a base class for <type scope="com::sun::star::inspection">XPropertyControl</type>
|
|
|
|
implementations, which delegates the generic functionality of this interface to a
|
|
|
|
<type>ControlHelper</type> member.
|
|
|
|
|
|
|
|
@param CONTROL_INTERFACE
|
|
|
|
an interface class which is derived from (or identical to) <type scope="com::sun::star::inspection">XPropertyControl</type>
|
|
|
|
@param CONTROL_WINDOW
|
|
|
|
a class which is derived from ControlWindow
|
|
|
|
*/
|
|
|
|
template < class CONTROL_INTERFACE, class CONTROL_WINDOW >
|
|
|
|
class CommonBehaviourControl :public ::comphelper::OBaseMutex
|
|
|
|
,public ::cppu::WeakComponentImplHelper1< CONTROL_INTERFACE >
|
|
|
|
,public IModifyListener
|
|
|
|
{
|
2001-01-12 10:35:45 +00:00
|
|
|
protected:
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
typedef CONTROL_INTERFACE InterfaceType;
|
|
|
|
typedef CONTROL_WINDOW WindowType;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
typedef ::comphelper::OBaseMutex MutexBaseClass;
|
|
|
|
typedef ::cppu::WeakComponentImplHelper1< CONTROL_INTERFACE > ComponentBaseClass;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
protected:
|
|
|
|
ControlHelper m_aImplControl;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
protected:
|
2014-09-23 11:20:40 +02:00
|
|
|
inline CommonBehaviourControl( sal_Int16 _nControlType, vcl::Window* _pParentWindow, WinBits _nWindowStyle, bool _bDoSetHandlers = true );
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
|
|
|
|
// XPropertyControl - delegated to ->m_aImplControl
|
2014-09-12 14:57:06 +02:00
|
|
|
virtual ::sal_Int16 SAL_CALL getControlType() throw (::com::sun::star::uno::RuntimeException) SAL_OVERRIDE;
|
|
|
|
virtual ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControlContext > SAL_CALL getControlContext() throw (::com::sun::star::uno::RuntimeException) SAL_OVERRIDE;
|
|
|
|
virtual void SAL_CALL setControlContext( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControlContext >& _controlcontext ) throw (::com::sun::star::uno::RuntimeException) SAL_OVERRIDE;
|
|
|
|
virtual ::com::sun::star::uno::Reference< ::com::sun::star::awt::XWindow > SAL_CALL getControlWindow() throw (::com::sun::star::uno::RuntimeException) SAL_OVERRIDE;
|
|
|
|
virtual sal_Bool SAL_CALL isModified( ) throw (::com::sun::star::uno::RuntimeException) SAL_OVERRIDE;
|
|
|
|
virtual void SAL_CALL notifyModifiedValue( ) throw (::com::sun::star::uno::RuntimeException) SAL_OVERRIDE;
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
|
|
|
|
// XComponent
|
2014-09-12 14:57:06 +02:00
|
|
|
virtual void SAL_CALL disposing() SAL_OVERRIDE;
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
|
|
|
|
// IModifyListener
|
2014-03-27 19:59:49 +01:00
|
|
|
virtual void modified() SAL_OVERRIDE
|
|
|
|
{ m_aImplControl.setModified(); }
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
|
|
|
|
/// returns a typed pointer to our control window
|
|
|
|
WindowType* getTypedControlWindow() { return static_cast< WindowType* > ( m_aImplControl.getVclControlWindow() ); }
|
|
|
|
const WindowType* getTypedControlWindow() const { return static_cast< const WindowType* >( m_aImplControl.getVclControlWindow() ); }
|
|
|
|
|
|
|
|
protected:
|
|
|
|
/** checks whether the instance is already disposed
|
|
|
|
@throws DisposedException
|
|
|
|
if the instance is already disposed
|
|
|
|
*/
|
2007-05-10 09:47:04 +00:00
|
|
|
inline void impl_checkDisposed_throw();
|
2001-01-12 10:35:45 +00:00
|
|
|
};
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
//= ControlWindow - implementation
|
2014-02-25 18:36:00 +01:00
|
|
|
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
template< class WINDOW >
|
2007-05-10 09:47:04 +00:00
|
|
|
inline void ControlWindow< WINDOW >::setControlHelper( ControlHelper& _rControlHelper )
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
{
|
|
|
|
m_pHelper = &_rControlHelper;
|
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
template< class WINDOW >
|
2014-01-18 00:18:52 +01:00
|
|
|
inline bool ControlWindow< WINDOW >::PreNotify( NotifyEvent& rNEvt )
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
{
|
|
|
|
if ( m_pHelper && m_pHelper->handlePreNotify( rNEvt ) )
|
2014-01-18 00:18:52 +01:00
|
|
|
return true;
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
return WindowType::PreNotify( rNEvt );
|
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
//= CommonBehaviourControl - implementation
|
2014-02-25 18:36:00 +01:00
|
|
|
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
template< class CONTROL_INTERFACE, class CONTROL_WINDOW >
|
2014-09-23 11:20:40 +02:00
|
|
|
inline CommonBehaviourControl< CONTROL_INTERFACE, CONTROL_WINDOW >::CommonBehaviourControl ( sal_Int16 _nControlType, vcl::Window* _pParentWindow, WinBits _nWindowStyle, bool _bDoSetHandlers )
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
:ComponentBaseClass( m_aMutex )
|
|
|
|
,m_aImplControl( new WindowType( _pParentWindow, _nWindowStyle ), _nControlType, *this, this )
|
|
|
|
{
|
|
|
|
WindowType* pControlWindow( getTypedControlWindow() );
|
|
|
|
pControlWindow->setControlHelper( m_aImplControl );
|
|
|
|
if ( _bDoSetHandlers )
|
|
|
|
{
|
|
|
|
pControlWindow->SetModifyHdl( LINK( &m_aImplControl, ControlHelper, ModifiedHdl ) );
|
|
|
|
pControlWindow->SetGetFocusHdl( LINK( &m_aImplControl, ControlHelper, GetFocusHdl ) );
|
|
|
|
pControlWindow->SetLoseFocusHdl( LINK( &m_aImplControl, ControlHelper, LoseFocusHdl ) );
|
|
|
|
}
|
|
|
|
m_aImplControl.autoSizeWindow();
|
2006-03-17 08:47:23 +00:00
|
|
|
}
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
template< class CONTROL_INTERFACE, class CONTROL_WINDOW >
|
2007-05-10 09:47:04 +00:00
|
|
|
inline ::sal_Int16 SAL_CALL CommonBehaviourControl< CONTROL_INTERFACE, CONTROL_WINDOW >::getControlType() throw (::com::sun::star::uno::RuntimeException)
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
{
|
|
|
|
return m_aImplControl.getControlType();
|
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
template< class CONTROL_INTERFACE, class CONTROL_WINDOW >
|
2007-05-10 09:47:04 +00:00
|
|
|
inline ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControlContext > SAL_CALL CommonBehaviourControl< CONTROL_INTERFACE, CONTROL_WINDOW >::getControlContext() throw (::com::sun::star::uno::RuntimeException)
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
{
|
|
|
|
return m_aImplControl.getControlContext();
|
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
template< class CONTROL_INTERFACE, class CONTROL_WINDOW >
|
2007-05-10 09:47:04 +00:00
|
|
|
inline void SAL_CALL CommonBehaviourControl< CONTROL_INTERFACE, CONTROL_WINDOW >::setControlContext( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControlContext >& _controlcontext ) throw (::com::sun::star::uno::RuntimeException)
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
{
|
|
|
|
m_aImplControl.setControlContext( _controlcontext );
|
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
template< class CONTROL_INTERFACE, class CONTROL_WINDOW >
|
2007-05-10 09:47:04 +00:00
|
|
|
inline ::com::sun::star::uno::Reference< ::com::sun::star::awt::XWindow > SAL_CALL CommonBehaviourControl< CONTROL_INTERFACE, CONTROL_WINDOW >::getControlWindow() throw (::com::sun::star::uno::RuntimeException)
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
{
|
|
|
|
return m_aImplControl.getControlWindow();
|
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
template< class CONTROL_INTERFACE, class CONTROL_WINDOW >
|
2014-04-03 13:52:06 +02:00
|
|
|
inline sal_Bool SAL_CALL CommonBehaviourControl< CONTROL_INTERFACE, CONTROL_WINDOW >::isModified( ) throw (::com::sun::star::uno::RuntimeException)
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
{
|
|
|
|
return m_aImplControl.isModified();
|
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
template< class CONTROL_INTERFACE, class CONTROL_WINDOW >
|
2007-05-10 09:47:04 +00:00
|
|
|
inline void SAL_CALL CommonBehaviourControl< CONTROL_INTERFACE, CONTROL_WINDOW >::notifyModifiedValue( ) throw (::com::sun::star::uno::RuntimeException)
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
{
|
|
|
|
m_aImplControl.notifyModifiedValue();
|
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
template< class CONTROL_INTERFACE, class CONTROL_WINDOW >
|
2007-05-10 09:47:04 +00:00
|
|
|
inline void SAL_CALL CommonBehaviourControl< CONTROL_INTERFACE, CONTROL_WINDOW >::disposing()
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
{
|
|
|
|
m_aImplControl.dispose();
|
|
|
|
}
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
template< class CONTROL_INTERFACE, class CONTROL_WINDOW >
|
2007-05-10 09:47:04 +00:00
|
|
|
inline void CommonBehaviourControl< CONTROL_INTERFACE, CONTROL_WINDOW >::impl_checkDisposed_throw()
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +00:00
|
|
|
{
|
|
|
|
if ( ComponentBaseClass::rBHelper.bDisposed )
|
2013-04-07 12:06:47 +02:00
|
|
|
throw ::com::sun::star::lang::DisposedException( OUString(), *this );
|
INTEGRATION: CWS pbrwuno (1.4.158); FILE MERGED
2005/10/19 07:48:05 fs 1.4.158.7: #i53095# knitting some loose ends
2005/10/14 12:43:44 fs 1.4.158.6: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/05 06:52:23 fs 1.4.158.5: RESYNC: (1.4-1.5); FILE MERGED
2005/09/26 09:06:15 fs 1.4.158.4: #i10000# some rearrangements
2005/09/05 07:41:47 fs 1.4.158.3: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:54 fs 1.4.158.2: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/09 13:59:56 fs 1.4.158.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:19:35 +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_COMMONCONTROL_HXX
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2010-10-27 12:45:03 +01:00
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|