Files
libreoffice/extensions/source/propctrlr/commoncontrol.hxx

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

215 lines
9.0 KiB
C++
Raw Normal View History

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 .
*/
#ifndef INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_COMMONCONTROL_HXX
#define INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_COMMONCONTROL_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
#include <com/sun/star/inspection/XPropertyControl.hpp>
#include <com/sun/star/lang/DisposedException.hpp>
#include <cppuhelper/compbase.hxx>
#include <cppuhelper/basemutex.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
#include <tools/link.hxx>
#include <vcl/window.hxx>
#include <toolkit/helper/vclunohelper.hxx>
#include <type_traits>
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;
class Control;
class ListBox;
class SvxColorListBox;
class Edit;
namespace pcr
{
//= CommonBehaviourControlHelper
/** A helper class for implementing the <type scope="css::inspection">XPropertyControl</type>
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
or one of its derived interfaces.
This class is used as a base class the CommonBehaviourControl template.
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 CommonBehaviourControlHelper
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:
sal_Int16 m_nControlType;
css::uno::Reference< css::inspection::XPropertyControlContext >
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_xContext;
css::inspection::XPropertyControl&
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_rAntiImpl;
bool m_bModified;
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 _nControlType
the type of the control - one of the <type scope="css::inspection">PropertyControlType</type>
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
constants
@param _pAntiImpl
Reference to the instance as whose "impl-class" we act i.e. the CommonBehaviourControl<> template,
which is why we hold it without acquiring it/
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
*/
CommonBehaviourControlHelper(
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,
css::inspection::XPropertyControl& _rAntiImpl);
virtual ~CommonBehaviourControlHelper();
virtual void setModified() { m_bModified = 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
/// @throws css::uno::RuntimeException
::sal_Int16 getControlType() const { return m_nControlType; }
/// @throws css::uno::RuntimeException
const css::uno::Reference< css::inspection::XPropertyControlContext >& getControlContext() const { return m_xContext; }
/// @throws css::uno::RuntimeException
void setControlContext( const css::uno::Reference< css::inspection::XPropertyControlContext >& _controlcontext );
/// @throws css::uno::RuntimeException
bool isModified( ) const { return m_bModified; }
/// @throws css::uno::RuntimeException
void notifyModifiedValue( );
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
*/
void activateNextControl() const;
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();
virtual vcl::Window* getVclWindow() = 0;
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
DECL_LINK( ModifiedHdl, ListBox&, void );
DECL_LINK( ColorModifiedHdl, SvxColorListBox&, void );
DECL_LINK( EditModifiedHdl, Edit&, void );
DECL_LINK( GetFocusHdl, Control&, void );
DECL_LINK( LoseFocusHdl, Control&, void );
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
};
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
/** implements a base class for <type scope="css::inspection">XPropertyControl</type>
implementations
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
@param TControlInterface
an interface class which is derived from (or identical to) <type scope="css::inspection">XPropertyControl</type>
@param TControlWindow
a class which is derived from vcl::Window
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 TControlInterface, class TControlWindow >
class CommonBehaviourControl :public ::cppu::BaseMutex
,public ::cppu::WeakComponentImplHelper< TControlInterface >
,public CommonBehaviourControlHelper
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:
typedef ::cppu::WeakComponentImplHelper< TControlInterface > ComponentBaseClass;
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
virtual ::sal_Int16 SAL_CALL getControlType() override
{ return CommonBehaviourControlHelper::getControlType(); }
virtual css::uno::Reference< css::inspection::XPropertyControlContext > SAL_CALL getControlContext() override
{ return CommonBehaviourControlHelper::getControlContext(); }
virtual void SAL_CALL setControlContext( const css::uno::Reference< css::inspection::XPropertyControlContext >& _controlcontext ) override
{ CommonBehaviourControlHelper::setControlContext( _controlcontext ); }
virtual css::uno::Reference< css::awt::XWindow > SAL_CALL getControlWindow() override
{ return VCLUnoHelper::GetInterface( m_pControlWindow ); }
virtual sal_Bool SAL_CALL isModified( ) override
{ return CommonBehaviourControlHelper::isModified(); }
virtual void SAL_CALL notifyModifiedValue( ) override
{ CommonBehaviourControlHelper::notifyModifiedValue(); }
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
virtual void SAL_CALL disposing() override
{ m_pControlWindow.disposeAndClear(); }
// CommonBehaviourControlHelper::getVclWindow
virtual vcl::Window* getVclWindow() override
{ return m_pControlWindow.get(); }
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
TControlWindow* getTypedControlWindow()
{ return m_pControlWindow.get(); }
const TControlWindow* getTypedControlWindow() const
{ return m_pControlWindow.get(); }
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
/** checks whether the instance is already disposed
@throws DisposedException
if the instance is already disposed
*/
inline void impl_checkDisposed_throw();
private:
VclPtr<TControlWindow> m_pControlWindow;
void implSetModifyHandler(const Edit&);
void implSetModifyHandler(const ListBox&);
void implSetModifyHandler(const SvxColorListBox&);
};
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
template< class TControlInterface, class TControlWindow >
inline CommonBehaviourControl< TControlInterface, TControlWindow >::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 )
,CommonBehaviourControlHelper( _nControlType, *this )
,m_pControlWindow( VclPtr<TControlWindow>::Create( _pParentWindow, _nWindowStyle ) )
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 ( _bDoSetHandlers )
{
implSetModifyHandler(*m_pControlWindow);
m_pControlWindow->SetGetFocusHdl( LINK( this, CommonBehaviourControlHelper, GetFocusHdl ) );
m_pControlWindow->SetLoseFocusHdl( LINK( this, CommonBehaviourControlHelper, LoseFocusHdl ) );
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
}
autoSizeWindow();
}
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 TControlInterface, class TControlWindow >
inline void CommonBehaviourControl< TControlInterface, TControlWindow >::implSetModifyHandler(const Edit&)
{
m_pControlWindow->SetModifyHdl( LINK( this, CommonBehaviourControlHelper, EditModifiedHdl ) );
}
template< class TControlInterface, class TControlWindow >
inline void CommonBehaviourControl< TControlInterface, TControlWindow >::implSetModifyHandler(const ListBox&)
{
m_pControlWindow->SetModifyHdl( LINK( this, CommonBehaviourControlHelper, ModifiedHdl ) );
}
template< class TControlInterface, class TControlWindow >
inline void CommonBehaviourControl< TControlInterface, TControlWindow >::implSetModifyHandler(const SvxColorListBox&)
{
m_pControlWindow->SetModifyHdl( LINK( this, CommonBehaviourControlHelper, ColorModifiedHdl ) );
}
template< class TControlInterface, class TControlWindow >
inline void CommonBehaviourControl< TControlInterface, TControlWindow >::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 )
throw css::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
}
} // namespace pcr
#endif // INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_COMMONCONTROL_HXX
2010-10-27 12:45:03 +01:00
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */