Files
libreoffice/extensions/source/propctrlr/browserline.cxx

514 lines
15 KiB
C++
Raw Normal View History

/* -*- 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 .
*/
#include "browserline.hxx"
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
#include <com/sun/star/uno/XComponentContext.hpp>
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
#include <com/sun/star/inspection/PropertyLineElement.hpp>
#include <com/sun/star/graphic/GraphicProvider.hpp>
#include <com/sun/star/graphic/XGraphicProvider.hpp>
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
#include <comphelper/processfactory.hxx>
#include <comphelper/string.hxx>
#include <tools/debug.hxx>
#include <tools/diagnose_ex.h>
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
#include <toolkit/helper/vclunohelper.hxx>
#include <vcl/svapp.hxx>
#include <vcl/settings.hxx>
namespace pcr
{
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
using ::com::sun::star::uno::Reference;
using ::com::sun::star::uno::XComponentContext;
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
using ::com::sun::star::inspection::XPropertyControl;
using ::com::sun::star::inspection::XPropertyControlContext;
using ::com::sun::star::uno::UNO_QUERY_THROW;
using ::com::sun::star::uno::Exception;
using ::com::sun::star::graphic::GraphicProvider;
using ::com::sun::star::graphic::XGraphicProvider;
using ::com::sun::star::uno::Sequence;
using ::com::sun::star::beans::PropertyValue;
using ::com::sun::star::graphic::XGraphic;
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
namespace PropertyLineElement = ::com::sun::star::inspection::PropertyLineElement;
//= OBrowserLine
OBrowserLine::OBrowserLine( const OUString& _rEntryName, vcl::Window* pParent )
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
:m_sEntryName( _rEntryName )
,m_aFtTitle(pParent)
,m_pControlWindow( NULL )
,m_pBrowseButton(NULL)
,m_pAdditionalBrowseButton( NULL )
,m_pClickListener( NULL )
,m_pTheParent(pParent)
,m_nNameWidth(0)
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
,m_nEnableFlags( 0xFFFF )
,m_bIndentTitle( false )
,m_bReadOnly( false )
{
m_aFtTitle.Show();
}
OBrowserLine::~OBrowserLine()
{
implHideBrowseButton( true, false );
implHideBrowseButton( false, false );
}
void OBrowserLine::IndentTitle( bool _bIndent )
{
if ( m_bIndentTitle != _bIndent )
{
m_bIndentTitle = _bIndent;
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
impl_layoutComponents();
}
}
void OBrowserLine::SetComponentHelpIds( const OString& _rHelpId, const OString& _sPrimaryButtonId, const OString& _sSecondaryButtonId )
{
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
if ( m_pControlWindow )
m_pControlWindow->SetHelpId( _rHelpId );
if ( m_pBrowseButton )
{
m_pBrowseButton->SetHelpId( _rHelpId );
m_pBrowseButton->SetUniqueId( _sPrimaryButtonId );
if ( m_pAdditionalBrowseButton )
{
m_pAdditionalBrowseButton->SetHelpId( _rHelpId );
m_pAdditionalBrowseButton->SetUniqueId( _sSecondaryButtonId );
}
}
}
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
void OBrowserLine::setControl( const Reference< XPropertyControl >& _rxControl )
{
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
m_xControl = _rxControl;
m_pControlWindow = m_xControl.is() ? VCLUnoHelper::GetWindow( _rxControl->getControlWindow() ) : NULL;
DBG_ASSERT( m_pControlWindow, "OBrowserLine::setControl: setting NULL controls/windows is not allowed!" );
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
if ( m_pControlWindow )
{
m_pControlWindow->SetParent( m_pTheParent );
m_pControlWindow->Show();
}
impl_layoutComponents();
}
vcl::Window* OBrowserLine::GetRefWindow()
{
vcl::Window* pRefWindow=&m_aFtTitle;
if(m_pBrowseButton)
{
pRefWindow=(vcl::Window*)m_pBrowseButton;
}
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
else if ( m_pControlWindow )
{
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
pRefWindow = m_pControlWindow;
}
return pRefWindow;
}
void OBrowserLine::SetTabOrder(vcl::Window* pRefWindow, sal_uInt16 nFlags )
{
m_aFtTitle.SetZOrder(pRefWindow,nFlags);
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
if ( m_pControlWindow )
m_pControlWindow->SetZOrder( (vcl::Window*)&m_aFtTitle, WINDOW_ZORDER_BEHIND );
if ( m_pBrowseButton && m_pControlWindow )
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
m_pBrowseButton->SetZOrder( m_pControlWindow, WINDOW_ZORDER_BEHIND );
if ( m_pAdditionalBrowseButton && m_pBrowseButton )
m_pAdditionalBrowseButton->SetZOrder( m_pBrowseButton, WINDOW_ZORDER_BEHIND );
}
bool OBrowserLine::GrabFocus()
{
bool bRes=false;
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
if ( m_pControlWindow && m_pControlWindow->IsEnabled() )
{
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
m_pControlWindow->GrabFocus();
bRes = true;
}
else if ( m_pAdditionalBrowseButton && m_pAdditionalBrowseButton->IsEnabled() )
{
m_pAdditionalBrowseButton->GrabFocus();
bRes = true;
}
else if ( m_pBrowseButton && m_pBrowseButton->IsEnabled() )
{
m_pBrowseButton->GrabFocus();
bRes = true;
}
return bRes;
}
void OBrowserLine::SetPosSizePixel( Point _rPos, Size _rSize )
{
m_aLinePos = _rPos;
m_aOutputSize = _rSize;
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
impl_layoutComponents();
}
void OBrowserLine::Show(bool bFlag)
{
m_aFtTitle.Show(bFlag);
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
if ( m_pControlWindow )
m_pControlWindow->Show( bFlag );
if ( m_pBrowseButton )
m_pBrowseButton->Show( bFlag );
if ( m_pAdditionalBrowseButton )
m_pAdditionalBrowseButton->Show( bFlag );
}
void OBrowserLine::Hide()
{
Show(false);
}
bool OBrowserLine::IsVisible()
{
return m_aFtTitle.IsVisible();
}
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
void OBrowserLine::impl_layoutComponents()
{
{
Point aTitlePos( m_aLinePos.X(), m_aLinePos.Y() + 8 );
Size aTitleSize( m_nNameWidth - 3, m_aOutputSize.Height() );
if ( m_bIndentTitle )
{
Size aIndent( m_pTheParent->LogicToPixel( Size( 8, 0 ), MAP_APPFONT ) );
aTitlePos.X() += aIndent.Width();
aTitleSize.Width() -= aIndent.Width();
}
m_aFtTitle.SetPosSizePixel( aTitlePos, aTitleSize );
}
sal_Int32 nBrowseButtonSize = m_aOutputSize.Height() - 4;
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
if ( m_pControlWindow )
{
Point aControlPos( m_aLinePos.X() + m_nNameWidth, m_aLinePos.Y() + 2 );
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
m_pControlWindow->SetPosPixel( aControlPos );
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
Size aControlSize( m_aOutputSize.Width() - 4 - m_nNameWidth - nBrowseButtonSize - 4, m_pControlWindow->GetSizePixel().Height() );
if ( m_pAdditionalBrowseButton )
aControlSize.Width() -= nBrowseButtonSize + 4;
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
m_pControlWindow->SetSizePixel( aControlSize );
}
if ( m_pBrowseButton )
{
Point aButtonPos( m_aOutputSize.Width() - 4 - nBrowseButtonSize, m_aLinePos.Y() + 2 );
Size aButtonSize( nBrowseButtonSize, nBrowseButtonSize );
m_pBrowseButton->SetPosSizePixel( aButtonPos, aButtonSize );
if ( m_pAdditionalBrowseButton )
{
aButtonPos.X() -= nBrowseButtonSize + 4;
m_pAdditionalBrowseButton->SetPosSizePixel( aButtonPos, aButtonSize );
}
}
}
void OBrowserLine::SetTitle(const OUString& _rNewTtile )
{
if ( GetTitle() == _rNewTtile )
return;
// #99102# --------------
m_aFtTitle.SetText( _rNewTtile );
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
if ( m_pControlWindow )
m_pControlWindow->SetAccessibleName( _rNewTtile );
if ( m_pBrowseButton )
m_pBrowseButton->SetAccessibleName( _rNewTtile );
FullFillTitleString();
}
// #99102# ---------------------------------------------------------
void OBrowserLine::FullFillTitleString()
{
if( m_pTheParent )
{
OUStringBuffer aText( m_aFtTitle.GetText() );
while( m_pTheParent->GetTextWidth( aText.toString() ) < m_nNameWidth )
aText.append("...........");
// for Issue 69452
if (Application::GetSettings().GetLayoutRTL())
{
sal_Unicode cRTL_mark = 0x200F;
aText.append( OUString(cRTL_mark) );
}
m_aFtTitle.SetText( aText.makeStringAndClear() );
}
}
OUString OBrowserLine::GetTitle() const
{
OUString sDisplayName = m_aFtTitle.GetText();
// for Issue 69452
if (Application::GetSettings().GetLayoutRTL())
{
sal_Unicode cRTL_mark = 0x200F;
sDisplayName = comphelper::string::stripEnd(sDisplayName, cRTL_mark);
}
sDisplayName = comphelper::string::stripEnd(sDisplayName, '.');
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
return sDisplayName;
}
void OBrowserLine::SetReadOnly( bool _bReadOnly )
{
if ( m_bReadOnly != _bReadOnly )
{
m_bReadOnly = _bReadOnly;
implUpdateEnabledDisabled();
}
}
namespace
{
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
void implSetBitIfAffected( sal_uInt16& _nEnabledBits, sal_Int16 _nAffectedMask, sal_Int16 _nTestBit, bool _bSet )
{
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
if ( _nAffectedMask & _nTestBit )
CWS-TOOLING: integrate CWS cmcfixes51 2008-12-08 10:12:55 +0100 cmc r264975 : #i96203# protect with ifdefs to avoid unused symbol on mac 2008-12-05 12:23:47 +0100 cmc r264898 : CWS-TOOLING: rebase CWS cmcfixes51 to trunk@264807 (milestone: DEV300:m37) 2008-12-01 14:45:17 +0100 cmc r264606 : #i76655# ehlos apparently required 2008-11-28 17:49:30 +0100 cmc r264567 : #i96655# remove newly unused method 2008-11-28 10:41:28 +0100 cmc r264531 : #i96647# better ppc-bridges flushCode impl 2008-11-27 12:58:40 +0100 cmc r264478 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 12:32:49 +0100 cmc r264476 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 12:26:02 +0100 cmc r264475 : #i96655# redundant old table export helpers 2008-11-27 11:49:06 +0100 cmc r264473 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 11:38:35 +0100 cmc r264471 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 11:14:21 +0100 cmc r264467 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 11:06:22 +0100 cmc r264464 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:58:18 +0100 cmc r264462 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:41:44 +0100 cmc r264461 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:19:24 +0100 cmc r264460 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:13:39 +0100 cmc r264459 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:06:14 +0100 cmc r264458 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:59:54 +0100 cmc r264457 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:52:51 +0100 cmc r264456 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:48:26 +0100 cmc r264454 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:40:20 +0100 cmc r264452 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:35:26 +0100 cmc r264451 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:31:00 +0100 cmc r264450 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:24:08 +0100 cmc r264449 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 00:26:15 +0100 cmc r264443 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 00:21:01 +0100 cmc r264442 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 00:09:40 +0100 cmc r264441 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 23:51:56 +0100 cmc r264440 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 23:49:09 +0100 cmc r264439 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 18:09:54 +0100 cmc r264432 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 18:07:40 +0100 cmc r264431 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 17:28:02 +0100 cmc r264429 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 17:27:39 +0100 cmc r264428 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 17:18:36 +0100 cmc r264426 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 16:22:16 +0100 cmc r264415 : #i96624# make implicit braces and brackets explicit to avoid warnings 2008-11-26 16:00:23 +0100 cmc r264409 : #i90426# remove warnings from svtools 2008-11-26 15:59:17 +0100 cmc r264408 : #i90426# remove warnings 2008-11-26 15:47:32 +0100 cmc r264404 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 14:46:57 +0100 cmc r264394 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 14:19:50 +0100 cmc r264387 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 14:15:26 +0100 cmc r264386 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 14:11:26 +0100 cmc r264384 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 13:44:23 +0100 cmc r264380 : #i96084# comfirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 13:12:24 +0100 cmc r264372 : #i96604# silence new warnings 2008-11-26 12:35:02 +0100 cmc r264369 : #i96203# make qstarter work in 3-layer land 2008-11-26 12:33:04 +0100 cmc r264368 : #i96170# ensure gtypes are up and running
2008-12-11 07:05:03 +00:00
{
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
if ( _bSet )
_nEnabledBits |= _nTestBit;
else
_nEnabledBits &= ~_nTestBit;
CWS-TOOLING: integrate CWS cmcfixes51 2008-12-08 10:12:55 +0100 cmc r264975 : #i96203# protect with ifdefs to avoid unused symbol on mac 2008-12-05 12:23:47 +0100 cmc r264898 : CWS-TOOLING: rebase CWS cmcfixes51 to trunk@264807 (milestone: DEV300:m37) 2008-12-01 14:45:17 +0100 cmc r264606 : #i76655# ehlos apparently required 2008-11-28 17:49:30 +0100 cmc r264567 : #i96655# remove newly unused method 2008-11-28 10:41:28 +0100 cmc r264531 : #i96647# better ppc-bridges flushCode impl 2008-11-27 12:58:40 +0100 cmc r264478 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 12:32:49 +0100 cmc r264476 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 12:26:02 +0100 cmc r264475 : #i96655# redundant old table export helpers 2008-11-27 11:49:06 +0100 cmc r264473 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 11:38:35 +0100 cmc r264471 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 11:14:21 +0100 cmc r264467 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 11:06:22 +0100 cmc r264464 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:58:18 +0100 cmc r264462 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:41:44 +0100 cmc r264461 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:19:24 +0100 cmc r264460 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:13:39 +0100 cmc r264459 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 10:06:14 +0100 cmc r264458 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:59:54 +0100 cmc r264457 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:52:51 +0100 cmc r264456 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:48:26 +0100 cmc r264454 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:40:20 +0100 cmc r264452 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:35:26 +0100 cmc r264451 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:31:00 +0100 cmc r264450 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 09:24:08 +0100 cmc r264449 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 00:26:15 +0100 cmc r264443 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 00:21:01 +0100 cmc r264442 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-27 00:09:40 +0100 cmc r264441 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 23:51:56 +0100 cmc r264440 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 23:49:09 +0100 cmc r264439 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 18:09:54 +0100 cmc r264432 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 18:07:40 +0100 cmc r264431 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 17:28:02 +0100 cmc r264429 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 17:27:39 +0100 cmc r264428 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 17:18:36 +0100 cmc r264426 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 16:22:16 +0100 cmc r264415 : #i96624# make implicit braces and brackets explicit to avoid warnings 2008-11-26 16:00:23 +0100 cmc r264409 : #i90426# remove warnings from svtools 2008-11-26 15:59:17 +0100 cmc r264408 : #i90426# remove warnings 2008-11-26 15:47:32 +0100 cmc r264404 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 14:46:57 +0100 cmc r264394 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 14:19:50 +0100 cmc r264387 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 14:15:26 +0100 cmc r264386 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 14:11:26 +0100 cmc r264384 : #i96084# confirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 13:44:23 +0100 cmc r264380 : #i96084# comfirm existing logic with explicit brackets to remove new gcc warnings 2008-11-26 13:12:24 +0100 cmc r264372 : #i96604# silence new warnings 2008-11-26 12:35:02 +0100 cmc r264369 : #i96203# make qstarter work in 3-layer land 2008-11-26 12:33:04 +0100 cmc r264368 : #i96170# ensure gtypes are up and running
2008-12-11 07:05:03 +00:00
}
}
void implEnable( vcl::Window* _pWindow, sal_uInt16 _nEnabledBits, sal_uInt16 _nMatchBits )
{
if ( _pWindow )
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
_pWindow->Enable( ( _nEnabledBits & _nMatchBits ) == _nMatchBits );
}
void implEnable( vcl::Window* _pWindow, bool _bEnable )
{
if ( _pWindow )
_pWindow->Enable( _bEnable );
}
}
void OBrowserLine::implUpdateEnabledDisabled()
{
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
implEnable( &m_aFtTitle, m_nEnableFlags, PropertyLineElement::CompleteLine );
if ( m_pControlWindow )
implEnable( m_pControlWindow, m_nEnableFlags, PropertyLineElement::CompleteLine | PropertyLineElement::InputControl );
if ( m_bReadOnly )
{
implEnable( m_pBrowseButton, false );
implEnable( m_pAdditionalBrowseButton, false );
}
else
{
implEnable( m_pBrowseButton, m_nEnableFlags, PropertyLineElement::CompleteLine | PropertyLineElement::PrimaryButton );
implEnable( m_pAdditionalBrowseButton, m_nEnableFlags, PropertyLineElement::CompleteLine | PropertyLineElement::SecondaryButton );
}
}
void OBrowserLine::EnablePropertyLine( bool _bEnable )
{
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
implSetBitIfAffected( m_nEnableFlags, PropertyLineElement::CompleteLine, PropertyLineElement::CompleteLine, _bEnable );
implUpdateEnabledDisabled();
}
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
void OBrowserLine::EnablePropertyControls( sal_Int16 _nControls, bool _bEnable )
{
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
implSetBitIfAffected( m_nEnableFlags, _nControls, PropertyLineElement::InputControl, _bEnable );
implSetBitIfAffected( m_nEnableFlags, _nControls, PropertyLineElement::PrimaryButton, _bEnable );
implSetBitIfAffected( m_nEnableFlags, _nControls, PropertyLineElement::SecondaryButton, _bEnable );
implUpdateEnabledDisabled();
}
PushButton& OBrowserLine::impl_ensureButton( bool _bPrimary )
{
PushButton*& rpButton = _bPrimary ? m_pBrowseButton : m_pAdditionalBrowseButton;
if ( !rpButton )
{
rpButton = new PushButton( m_pTheParent, WB_NOPOINTERFOCUS );
rpButton->SetGetFocusHdl( LINK( this, OBrowserLine, OnButtonFocus ) );
rpButton->SetClickHdl( LINK( this, OBrowserLine, OnButtonClicked ) );
rpButton->SetText(OUString("..."));
}
rpButton->Show();
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
impl_layoutComponents();
return *rpButton;
}
void OBrowserLine::impl_getImagesFromURL_nothrow( const OUString& _rImageURL, Image& _out_rImage )
{
try
{
Reference< XComponentContext > xContext( ::comphelper::getProcessComponentContext() );
Reference< XGraphicProvider > xGraphicProvider( GraphicProvider::create(xContext) );
Sequence< PropertyValue > aMediaProperties(1);
aMediaProperties[0].Name = "URL";
aMediaProperties[0].Value <<= _rImageURL;
Reference< XGraphic > xGraphic( xGraphicProvider->queryGraphic( aMediaProperties ), UNO_QUERY_THROW );
_out_rImage = Image( xGraphic );
}
catch( const Exception& )
{
DBG_UNHANDLED_EXCEPTION();
}
}
void OBrowserLine::ShowBrowseButton( const OUString& _rImageURL, bool _bPrimary )
{
PushButton& rButton( impl_ensureButton( _bPrimary ) );
OSL_PRECOND( !_rImageURL.isEmpty(), "OBrowserLine::ShowBrowseButton: use the other version if you don't have an image!" );
Image aImage;
impl_getImagesFromURL_nothrow( _rImageURL, aImage );
rButton.SetModeImage( aImage );
}
void OBrowserLine::ShowBrowseButton( const Image& _rImage, bool _bPrimary )
{
PushButton& rButton( impl_ensureButton( _bPrimary ) );
if ( !!_rImage )
rButton.SetModeImage( _rImage );
}
void OBrowserLine::ShowBrowseButton( bool _bPrimary )
{
impl_ensureButton( _bPrimary );
}
void OBrowserLine::implHideBrowseButton( bool _bPrimary, bool _bReLayout )
{
PushButton*& rpButton = _bPrimary ? m_pBrowseButton : m_pAdditionalBrowseButton;
if ( rpButton )
{
rpButton->Hide();
delete rpButton;
rpButton = NULL;
}
if ( _bReLayout )
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
impl_layoutComponents();
}
void OBrowserLine::HideBrowseButton( bool _bPrimary )
{
implHideBrowseButton( _bPrimary, true );
}
void OBrowserLine::SetTitleWidth(sal_uInt16 nWidth)
{
if (m_nNameWidth != nWidth+10)
{
m_nNameWidth = nWidth+10;
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
impl_layoutComponents();
}
// #99102# ---------
FullFillTitleString();
}
void OBrowserLine::SetClickListener( IButtonClickListener* _pListener )
{
m_pClickListener = _pListener;
}
IMPL_LINK( OBrowserLine, OnButtonClicked, PushButton*, _pButton )
{
if ( m_pClickListener )
m_pClickListener->buttonClicked( this, _pButton == m_pBrowseButton );
return 0L;
}
IMPL_LINK( OBrowserLine, OnButtonFocus, PushButton*, /*pPB*/ )
{
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
if ( m_xControl.is() )
{
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
try
{
Reference< XPropertyControlContext > xContext( m_xControl->getControlContext(), UNO_QUERY_THROW );
xContext->focusGained( m_xControl );
}
catch( const Exception& )
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
{
DBG_UNHANDLED_EXCEPTION();
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED 2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3: introduced XPropertyHandler and XObjectInspectorUI same open issues as in previous phase (plus probably some more, since not everything is tested, yet :-\) 2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED 2005/09/05 07:41:46 fs 1.9.96.4: #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:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements to enable or disable - moved designing the SQL command into a dedicated handler - some more reactions on actuating properties move to dedicated handlers - *nearly* completed implementation of the "composed browser UI", which collects and combines UI change requests (IPropertyBrowserUI) (still missing: proper auto-firing) 2005/08/09 13:59:54 fs 1.9.96.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:17:00 +00:00
}
}
return 0;
}
} // namespace pcr
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */